I have an app that wasn’t written by myself. If there is an error such as an invalid ID given as a parameter, I would return something like:
(200 code)
{
"success": 0,
"error": "The row could not be found in the database"
}
…but the person who wrote the application done it like so:
(404 code)
The row could not be found in the database
I’m unsure whether their use of a 40x code is correct here. I understand 40x codes are for client errors but isn’t that in the case where the file cannot be served to the user, not that the file was found and to return a error message from the script.
Anyway the 40x was causing other JavaScript to crash as it wasn’t being handled correctly anyway. What is the best procedure/practise – put error messages in the response, return as 200, and handle using a success flag (e.g. “success”) OR put errors in the response, return as a 40x, but handle errors from the server better in the script so not to crash other JS as what seems to be happening in Firefox for me.
Would greatly appreciate people opinions on this matter.
but isn’t that in the case where the file cannot be served to the user, not that the file was found and to return a error message from the script.
In principle the first part is right, but “file” is ambiguous. You’re mistaken about what “file” means here, or more generally in the context of RESTful web services.
A web service exposes a resource to the user via HTTP. If the client tries to GET a resource—via AJAX or not—and the requested resource is not there, then the server should raise a 404 error. The resource is not the actual file stored on the server (e.g. ajax.php or some CGI script), but the resource the client tries to access, be it an image, or just textual content.
Wikipedia also mentions:
A 404 error should not be confused with “server not found” or similar errors, in which a connection to the destination server could not be made at all. A 404 error indicates that the requested resource may be available again in the future; however, the fact does not guarantee the same content.
Another example from A. Rodriguez, “Restful web services: The basics.” IBM developerWorks (2008):
[This operation has the] effect of renaming the resource from
RoberttoBob, and in doing so changes its URI to/users/Bob. In a REST Web service, subsequent requests for the resource using the old URI would generate a standard404 Not Founderror.
The AJAX submitting app should handle the case where the connection to the server times out or an internal server error (5xx) is thrown, but it should also just be able to deal with the fact that the resource it tried to fetch (e.g. a user, an image record, etc.) isn’t there at this point in time.
Of course, this is all focused on RESTful approaches. You don’t have to follow this, but it would make sense to leverage the semantics of HTTP status codes as much as possible, especially in the way the developer here did it—by adding specific error messages in the response body. The other approach of delivering a quasi-standard response with a success flag and a message is also fine, but it requires stronger coupling of front- and backend applications.