I have an asp.net MVC3 application that makes Ajax calls to the server on various occassion. We have a debate in our team on how to handle error response:
Option 1: Use HTTP status code to return back an error response, and have the ajax failure handler bind to the function that needs to be called on error.
Option 2: Use a header/payload concept using JSON, with a structure similar to
response:
success: true
text: <status text>
....
payload: <actual response>
The argument for first is – why not reuse the mechanism provided by HTTP and Ajax.
The argument for second is – Let alone the onFailure ajax handler to deal with ‘genuine’ http errors (e.g caused by network failure etc..) and have a uniform contract between the client and server for application’s success and error response. Parse the response to get failure/success and status text.
Thoughts on both approaches are welcome. Thanks.
I would go with the first approach. The HTTP protocol already provides all the mechanisms, so why does each developer should reinvent error handling everytime? If you return 200 status code intermediaries such as proxy servers has no way of knowing that this response should not be cached.