I am working with a REST API which resides on a server that handles data for a multitude of IoT devices.
My task is to query the server using the API to collect specific performance information about said devices.
In one instance, I obtain a list of available devices and their corresponding identifiers, then later query the server for more details using those identifiers (GUIDs).
The server is returning a
500 Internal Server Error for a query on one of those IDs. In my application, an exception is thrown and I don't see details about the error. If I examine the response more closely with Postman, I can see that the server returned JSON in the body which contains:
errorMessage: "This ID does not exist".
Disregard the fact the server provided the ID to begin with -- that's a separate problem for the developer.
Should a REST API return a
500 Internal Server Error to report that a query references an object that doesn't exist? To my thinking, the HTTP response codes should refer strictly to the status of the REST call, rather than to the internal mechanics of the API. I would expect a
200 OK with the response containing the error and description, which would be proprietary to the API in question.
It occurs to me that there is a potential difference in expectation depending on how the REST call is structured.
Consider these examples:
In the first case, the device ID is passed as a GET variable. A 404 or 500 would indicate that the path (
/restapi/deviceinfo) is either not found or resulted in a server error.
In the second case, the device ID is part of the URL. I would be more understanding of a
404 Not Found, but still could argue based on which parts of the path are interpreted as variables versus endpoints.