1 of 1 people found this helpful
I would not suggest taking an approach like this, with any action you perform on the PI Web API, there is a wide array of possible responses you may get. Some examples include:
A 404 if the resource does not exist
A 400 if the request you made was malformed
A 500 for any range of server side errors, including lack of permission on the back-end resource
401 or 403 if your authentication to the Web API is invalid
Plus any of the specified failure codes in the documentation listed for a particular action
An exhaustive list of possible statuses would only be available by accessing the source code of PI Web API directly and then tediously extracting each code for each action defined in the PI Web API.
So what I am saying its not practical (or typically possible) to write an application where every known error has some bespoke handling, rather you should devise a way to catch any status code returned by the Web API and then take some action depending on the type of status it is which is indicative by its leading number (1,2,3,4,5).
I had another thought, the swagger specification will enumerate possible statuses for particular actions, but parsing through all of that will also be tedious.
2 of 2 people found this helpful
The PI Web API adheres to the standard semantics of HTTP codes as closely as possible. From the Status Code section in the documentation.
200-level status codes indicate success
400-level status codes indicate user error
500-level status codes indicate server error.
400- and 500-level codes are generally accompanied by a response body providing a friendly error message to assist with debugging and is useful when you want more information on the return status.
One special case worth noting is that the 201 status code is returned in response to a POST, when a resource has been created. In this case, the response will contain a Location header with the WebID-based URL, which the client may use to access the newly-created resource.