Page History
Debugging an API is essentially no different than debugging any stored procedure. Therefore, a developer can simply put a debug statement in the code. However, this might not be desirable if the web APIs are being accessed by regular users. This article will provide some ideas a couple of techniques for debugging and analyzing APIs with minimal impact toward other users.
...
However, there might be times when the production database wants to avoid the Enable setting but the API developer needs to use the visual Debugger. For reasons like this, the HTTP Framework Setup form provides the same options as the Database Manager but this setting will only affect those engines handling HTTP requests:
Triggering the Debugger
As previously noted, a developer can simply embed The most direct way to debug an API is to debug the code. However, as noted above, simply embedding a debug statement in the API code but this would affect interrupt all requests. So there needs to be a way to safely trigger the debugger. In traditional OpenInsight development, developers could check for unique conditions such as the values in the @USERNAME or @STATION system variables. All Since all HTTP requests , however, will always be handled by the same username and station, this method isn't useful.
One way to introduce unique conditions is to add custom parameters to the API request. API testing tools like Postman make it very easy to add custom parameters. We recommend updating the AdditionalValues string from the OECGI4 registry key to include HTTP_DEBUG. Doing so will tell the OECGI to pass through a request header with the name Debug. You could, of course, create any name (or names) you want.
The HTTP_MCP controller routine already has code that checks for a value assigned to the Debug request header:
...
While not the same as using the Debugger in an interactive manner, the log files can provide an abundance of useful information. For instance, the entire OECGI request array is maintained in each Request log. This is structured so it is easy to review (read: delimiters are replaced with human readable formatting). The entire response (with some useful metadata) is maintained in each Response log. Furthermore, depending upon how your Debugger Setting is configured, runtime errors will appear in a Debugger, Aborted, or GetStatus log. If you already know some details about a specific request that you need to investigate (e.g., status code, date/time range, endpoint, etc.) you can quickly find the relevant logs using the HTTP Logs utility (just launch the NDW_HTTP_LOGS form):
Careful study of the logs files can often avoid the need to debug code. In the above screen shot, sample runtime errors can be seen in the Aborted log types. Unexpected conditions that are not due to runtime errors (like 4xx responses) can also be easily inspected with the relevant logs.
