CODEWITHSUNDEEP
restdjango-rest-frameworkhttp-error
Crazy Frog
Crazy Frog

Reputation: 525

Backend exception handling for REST app - should we return 4XX error or 200 with error mark

I am working on large-scale web app, and within the project I am developing a REST app for outside clients. I think that this question has not very much to do with the specific technology that I am using, but just in case - it's Django.

We have a convention with the development team that REST resources always return a standard JSON object of type

{'success': <value>,
 'object': <value> 
 'error_msg': <value>,
}

along with the status (200, 201, 403, etc....)

Examples of Django implementation:

return Response({'success': true,
                 'object': ...,
                 'error_msg': ...},
                 status=status.HTTP_200_OK)

The success parameter is assigned true for successful deployment of the resource, and false otherwise.

Now, the entire question here lies in what should be passed in status parameter in those cases when something bad happens - appropriate 4XX code or 200 ?. The development team suggests to ALWAYS use HTTP_200_OK, simply if something bad happened, just assign false to success. The error_msg will contain detailed error message in case of exception.

So the two alternatives among which I can't choose the right one look like this

 return Response({'success': false,
                  'object': ...,
                  'error_msg': 'Details regarding the error'},
                   status=status.HTTP_400_BAD_REQUEST)

vs:

return Response({'success': false,
                 'object': ...,
                 'error_msg': 'Details regarding the error'},
                 status=status.HTTP_200_OK)

(in both cases success will equal to false. So in both cases the developer will know that something went wrong by looking at success without having to check status)
However, the very existence of different error codes leaves me with unpleasant doubt that I'm missing something about WHY people have come up with different error codes. And IN WHAT SITUATIONS my project can face trouble if it always returns the same 200 status code.After reading tons of materials, I have no material explanation why specifying appropriate error status codes could outperform the approach of returning 200 status.

Upvotes: 3

Views: 445

Answers (1)

martinarroyo
martinarroyo

Reputation: 9701

HTTP codes are in my opinion a great way to get information on the result of an operation for the following reasons:

  • They are both machine- and human-readable (at least by developers).
  • They are integrated in every HTTP transaction, so every library implements mechanisms to deal with them.
  • The repertoire of error codes is 'standardized' and everyone knows how to deal with it, and it covers a lot of common cases (the DRF framework automatically uses some of those, such as 400, 403 or 405).
  • By ignoring them, you are increasing the amount of work that you have to implement on your own.

Of course, they might not be enough for particular cases. Suppose you receive a 400 code when you are submitting multiple fields to your API. If you want to know which ones are invalid and why, you still need the value of your error_msg, but the 400 code still simplifies a lot of your logic, since you can filter out a lot of other reasons why the request did not succeed (403, 405...).

Regarding your question:

And IN WHAT SITUATIONS my project can face trouble if it always returns the same 200

Well, if you implement things properly, leaving all error handling to the response date, it should never cause any trouble, but as argued earlier, I feel like this increases the complexity of the task at hand.

Please note that this are just my two cents, and there might be other opinions with better arguments for the opposite case.

Upvotes: 1

Related Questions