I am building an application with a REST-based API and have come to the point where I am specifying status codes for each requests.
What status code should i send for requests failing validation or where a request is trying to add a duplicate in my database?
I've looked through http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html but none of them seems right.
Is there a common practice when sending status codes?
For input validation failure: 400 Bad Request + your optional description. This is suggested in the book "RESTful Web Services". For double submit: 409 Conflict
Update June 2014
The relevant specification used to be RFC2616, which gave the use of 400 (Bad Request) rather narrowly as
The request could not be understood by the server due to malformed syntax
So it might have been argued that it was inappropriate for semantic errors. But not any more; since June 2014 the relevant standard RFC 7231, which supersedes the previous RFC2616, gives the use of 400 (Bad Request) more broadly as
the server cannot or will not process the request due to something that is perceived to be a client error
something perceived to be a client error, all the examples given in this paragraph are violations of HTTP protocol, not logical errors: syntax, framing, routing. Thus, I consider that HTTP spec does not allow 400 for failed validation on application level. –
Binnings I recommend status code 422, "Unprocessable Entity".
11.2. 422 Unprocessable Entity
The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.
You should definitely give a more detailed explanation in the response headers and/or body (e.g. with a custom header - X-Status-Reason: Validation failed).
HTTP/1.0 403 Form validation errors is the cleanest way to go. –
Bimbo X- prefix in custom HTTP headers is deprecated you could change your example to just Status-Reason: Validation failed. –
Durman Makes no recommendation as to whether existing "X-" parameters ought to remain in use or be migrated to a format without the "X-"; this is a matter for the creators or maintainers of those parameters. and keep it here as-is. –
Verso 403 Forbidden implies the request was comprehensible; usually invalid input means an incomprehensible request –
Zwart 200,300, 400, 500 are all very generic. If you want generic, 400 is OK.
422 is used by an increasing number of APIs, and is even used by Rails out of the box.
No matter which status code you pick for your API, someone will disagree. But I prefer 422 because I think of '400 + text status' as too generic. Also, you aren't taking advantage of a JSON-ready parser; in contrast, a 422 with a JSON response is very explicit, and a great deal of error information can be conveyed.
Speaking of JSON response, I tend to standardize on the Rails error response for this case, which is:
{
"errors" :
{
"arg1" : ["error msg 1", "error msg 2", ...]
"arg2" : ["error msg 1", "error msg 2", ...]
}
}
This format is perfect for form validation, which I consider the most complex case to support in terms of 'error reporting richness'. If your error structure is this, it will likely handle all your error reporting needs.
arg1 is valid and arg2 is valid, but the combination of the two, with the the specific values sent, is not valid. –
Brabant A duplicate in the database should be a 409 CONFLICT.
I recommend using 422 UNPROCESSABLE ENTITY for validation errors.
I give a longer explanation of 4xx codes here.
200
Ugh... (309, 400, 403, 409, 415, 422)... a lot of answers trying to guess, argue and standardize what is the best return code for a successful HTTP request but a failed REST call.
It is wrong to mix HTTP status codes and REST status codes.
However, I saw many implementations mixing them, and many developers may not agree with me.
HTTP return codes are related to the HTTP Request itself. A REST call is done using a Hypertext Transfer Protocol request and it works at a lower level than invoked REST method itself. REST is a concept/approach, and its output is a business/logical result, while HTTP result code is a transport one.
For example, returning "404 Not found" when you call /users/ is confuse, because it may mean:
"403 Forbidden/Access Denied" may mean:
And the list may continue with '500 Server error" (an Apache/Nginx HTTP thrown error or a business constraint error in REST) or other HTTP errors etc...
From the code, it's hard to understand what was the failure reason, a HTTP (transport) failure or a REST (logical) failure.
If the HTTP request physically was performed successfully it should always return 200 code, regardless is the record(s) found or not. Because URI resource is found and was handled by the HTTP server. Yes, it may return an empty set. Is it possible to receive an empty web-page with 200 as HTTP result, right?
Instead of this you may return 200 HTTP code with some options:
Also, some internet providers may intercept your requests and return you a 404 HTTP code. This does not means that your data are not found, but it's something wrong at transport level.
From Wiki:
In July 2004, the UK telecom provider BT Group deployed the Cleanfeed content blocking system, which returns a 404 error to any request for content identified as potentially illegal by the Internet Watch Foundation. Other ISPs return a HTTP 403 "forbidden" error in the same circumstances. The practice of employing fake 404 errors as a means to conceal censorship has also been reported in Thailand and Tunisia. In Tunisia, where censorship was severe before the 2011 revolution, people became aware of the nature of the fake 404 errors and created an imaginary character named "Ammar 404" who represents "the invisible censor".
Why not simply answer with something like this?
{
"result": false,
"error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}
Google always returns 200 as status code in their Geocoding API, even if the request logically fails: https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes
Facebook always return 200 for successful HTTP requests, even if REST request fails: https://developers.facebook.com/docs/graph-api/using-graph-api/error-handling
It's simple, HTTP status codes are for HTTP requests. REST API is Your, define Your status codes.
BadRequest() method has its own return model that will differ from your regular return model. That's a nightmare to parse. @KevinHooke, returning HTTP 200 for a REST validation error is like saying, "I received your message, the answer is no, and here's why." Returning HTTP 400 says, "I don't know what you're talking about." –
Edieedification {"success": false, "code": 123, "text": "Something wrong"} IS a REST status code. Up to you how you define them. Just do not mix it with HTTP status codes, as this answer argues. –
Ophir Ember-Data's ActiveRecord adapter expects 422 UNPROCESSABLE ENTITY to be returned from server. So, if you're client is written in Ember.js you should use 422. Only then DS.Errors will be populated with returned errors. You can of course change 422 to any other code in your adapter.
Status Code 304 Not Modified would also make an acceptable response to a duplicate request. This is similar to processing a header of If-None-Match using an entity tag.
In my opinion, @Piskvor's answer is the more obvious choice to what I perceive is the intent of the original question, but I have an alternative that is also relevant.
If you want to treat a duplicate request as a warning or notification rather than as an error, a response status code of 304 Not Modified and Content-Location header identifying the existing resource would be just as valid. When the intent is merely to ensure that a resource exists, a duplicate request would not be an error but a confirmation. The request is not wrong, but is simply redundant, and the client can refer to the existing resource.
In other words, the request is good, but since the resource already exists, the server does not need to perform any further processing.
I came to the conclusion to try to follow this rule: If it indicates the client developer error, go with 400 (Bad Request). Otherwise, supposing no client validation at all, if a dumb user is entering invalid data, then use 422 (Unprocessable Entity). If in doubt, prefer 422, or maybe use the one with easier implementation.
This helps the developer to know who actually made the mistake, whether himself or the user.
By a dumb user, I mean non-technical user. An attacker shouldn't matter here: If you were that worried about, you wouldn't use HTTP status codes in the first place. :)
For example, if you're validating a JSON request body against a JSON Schema, 400 is the proper choice (e.g. missing keys, keyword mismatches). However, if you're expecting user to enter a valid email, then you should use 422 (let me say again, suppose there is no client validation).
This can also be helpful in better branching logics. For instance, in the context of a REST API, suppose you have a survey response endpoint, with possible methods of POST and PATCH. In this case, if a client sends an invalid POST request, you might want to send the URI of the new resource back in the Location header for when the status code is 422, but not for 400.
Real world examples are more complicated for sure, but this should work great IMHO.
I think everyone will have different opinion on this because we all have referred to status codes in various contexts. But what is important is whatever is most widely accepted and known. 400 is known and accepted as validation error response and 409 as name suggests is a conflict. If we say 400 is not right for validation error because server has understood the request, then think of someone asking you a question which you do understand from words but you could have responded and said "oh that is an invalid question" or "that does not make sense" so just because you understood the words does not mean it makes sense. Otherwise we can keep talking about this all day
© 2022 - 2024 — McMap. All rights reserved.