Saturday, June 14, 2014

returning error statuses from JSON web services

Status code

201 Created

200 OK 

400 Bad Request 

And here's already the first point where things start to vary. Some people like the 400 status code for things like validation errors - others don't, since 400 really indicates malformed syntax in the request format itself.
Some prefer 422 Unprocessable Entity for validation errors, a WebDAV extension to the HTTP protocol, but still perfectly acceptable technically.
Others think you should simply take one of the error status codes unused in the HTTP protocol, e.g. 461. Twitter have done that with (among others) 420 Enhance Your Calm to notify a client that they're now being rate limited - even if there's an (on the surface) acceptable status code 429 Too Many Requests for that purpose already.
Etc. It's all a matter of philosophy.
As for 500 Internal Server Error, the same applies - some think it's perfectly fine for all kinds of error responses, others think that the 5xx errors should only be returned on exceptions (in the real sense - i.e., exceptional errors). If the error is truly exceptional, you mostly wouldn't want to take the chance and pass on any actual exception info, which may reveal too much about your server.
Response

HTTP/1.1 404 Not found
Content-Type: application/json; charset=utf-8
...

{
   'Success': false,
   'Message': 'The user Mr. Gone wasn't found.'
}
 
 
HTTP/1.1 422 Validation Error
Content-Type: application/json; charset=utf-8
...

{
   'Success': false,
   'Message': 'The request had validation errors.',
   'Errors':
   {
       'UserName': 'The user name must be provided.',
       'Email': 'The email address is already in use.'
   }
} 
 
 

No comments:

Post a Comment

Opps Part 1 : Abstraction

  Abstraction in C# is a fundamental concept of object-oriented programming (OOP) that allows developers t...