12

When a user submits invalid data to my API (usually via Javascript + JSON), I am wondering which HTTP response code I should reply with.

Should I return a HTTP 200 response with the errors - or should my server respond with a 400 or 500 error since the request actually failed my validation because of some bad data?

It seems like a 400 error is the way to go since "The 4xx class of status code is intended for cases in which the client seems to have erred" - wikipedia

However, one thing to keep in mind is that most people use a framework like jQuery which requires you to specify an alternate callback when AJAX requests respond with any status code other than a 200.

Xeoncross
  • 55,620
  • 80
  • 262
  • 364
  • 2
    400 is the "correct" way, 200 is the "polite" way. You choose. – Joachim Isaksson Feb 19 '12 at 00:54
  • possible duplicate of [REST HTTP status codes](http://stackoverflow.com/questions/3290182/rest-http-status-codes) – S.Lott Feb 19 '12 at 00:55
  • Very interesting question currently I return an empty json object but thats probably not right, looking at the HTTP response codes the closest would seam to be 400 (bad request), Interested to read others views on this one. – Dampsquid Feb 19 '12 at 00:56
  • @JoachimIsaksson made a good point. 400 is technically the proper way, but on the other hand it doesn't seem right to expect clients to handle every single HTTP code that we might or might not throw at them. It seems better to always return 200 and provide an "errorCode" field in the returned JSON. The exception might be 404 for API methods that don't exist. – laurent Feb 19 '12 at 04:52
  • What about if, for example, an incorrect password is submitted? Data isn't bad per se... 4XX or 200 + error? – sidonaldson May 05 '16 at 13:23

2 Answers2

8

400 Bad Request The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

use statusCode in jquery ajax calling:

<html>
<head>
<title>jquery testing</title>
<script type="text/javascript" src="jquery-1.6.2.min.js"/>"></script>
<script language="javascript">
$(document).ready(
    function(){
        $('#linkClick').click(
            function(){
                    $.ajax({
                        url: 'a.html',
                        data: {},
                        type: 'get',
                        dataType: 'json',
                        statusCode: {
                            404:function() { alert("404"); },
                            200:function() { alert("200"); },
                            201:function() { alert("201"); },
                            202:function() { alert("202"); }
                        },
                        success: function(data) {
                            alert( "Status: " + data);
                        }
                    });
                }); 
        }
        );
</script>
</head>
<body>
<a href="#" id="linkClick">click</a>
</body>
</html>
horaceman
  • 375
  • 1
  • 5
  • 2
    Seems heavy to expect the client to handle every single status code. – laurent Feb 19 '12 at 04:49
  • 1
    Very nice client answer horaceman. However, since @Laurent, seems to have a valid point. Perhaps a happy medium between correct, and realistic is to only implement a couple status codes that cover all the bases. 500, 400, 404, and 200 should do the job. The client only needs to implement 400 and 200. 404 should be noticed before the code ever makes it to production and if not, or there is an actual server error (500) being caught by the default error handler. – Xeoncross Feb 20 '12 at 00:41
  • 2
    @this.lau_ You don't need to handle every error code. A simple `code != 200` would suffice. But most of the time I'd expect the client would like to give meaningful feedback to the user. – Rhys van der Waerden Apr 09 '14 at 01:55
  • 1
    What about the other 20x codes, like 201? Shouldn't the check be `code >= 200 && code < 300`? Those are all success results, AFAIK – void.pointer Jan 23 '19 at 18:43
1

This has been a huge dilema forever. The truth is that it up to the dev team what to chose, both are valid and both will work fine if handled correctly. I wish we could have a standard way of doing things. But unluckily there are arguments on both sides of the coin, either go full 400 status code with json error explaining the "business rule error" or 200 status code with json indicating there was a business error, i.e. ok->false (Like Slack does with its API.)

Just FYI.- most of the client side libraries I've seen will treat a status code != 200-299 as an error.

WilliamX
  • 357
  • 4
  • 17
  • What's the benefit for adding the extra json field indicating ok->true/false? W the error code 400, you can split on the error code and marshal the json into a different object for each case. If you indicate this in the json, you would actually have to parse it before marshaling – bbnt Apr 04 '23 at 15:27