Currently the doHTTPRequest method that can be used in ScriptLibraries has several flaws that make it difficult to use with modern web services. The biggest issues are:
- doHTTPRequest throws a hard error when returning any non-200 OK response. This error cannot be suppressed in any way. (try, catch, etc. do not work). The default error message on failure cannot be changed. This can result in URL's being passed back to the end-user that we may not want to make easily accessible to general users.
- doHTTPRequest does not return a response body when a non-200 OK response is given. This makes it impossible to read useful information that may be returned in soft-fails caused by bad data. Most modern web services today return the data that was bad and info on how to fix the data.
- doHTTPRequest seems to ignore the timeout related fields and, still takes RTE / Tomcat timeouts into consideration. Meaning even if you set a timeout to occur after 1 second, the method will continue to wait for an additional 10 seconds (depending on how your tomcat is configured).
Anytime doHTTPRequest is called and there is a soft-fail such as bad data, which results in various return codes such as 401, 403, etc as well as anytime there is a hard failure (failure to connect, etc.)
There is no workaround that I'm aware of. We have to display default error messages to end-users with no ability to read into the error or strip REST API URL's. Timeouts are not honored regardless of what integer values we provide.
Modern web services often return a message body containing information relevant to the specific error code (401, 403, etc.) -- it's unacceptable that we cannot consume and utilize this information to provide meaningful non-technical information to our end-users. Without the ability to adjust timeouts or change the default message, when something goes wrong, errors are usually very technical, contain API URL's and, are not displayed timely enough.
doHTTPRequest returns a message body if one is provided for non-200 OK responses. Timeout parameters are honored exactly to the integer provided. Default error messages can be overridden so that non-technical and user friendly information can be provided to the end-user on what happened and what can be done to fix the issue.