5
When a method in a web API detects that there has been a failure to validate the data of an entity to be added or updated, is there any HTTP code that is standard to be sent? For now I’m using code 400 (bad request), but I do not know if there is another more recommended for this type of failure.
5
Your question is good, but yet I believe it is based on opinions. The choice of the appropriate code should be made on the basis of the RFC in force. However, like any other standard, RFC is not always clear, and it is possible to interpret it in various ways.
Follow my considerations on the answers already given and my opinion.
First, the RFC that concerns this and is currently in vogue is the 7231. If you are familiar with English, I suggest you read it to create your own opinions as well.
Although in some web frameworks return 200 in the case of requests with invalid data, I do not believe that this should be the appropriate code.
According to item 6.3 of 7231, codes 2xx indicate that the client’s request has been received, understood and accepted.
So, if the purpose of a POST request is, for example, to create a new object on the server and this is not done based on invalid data, I do not consider that code 200 should be returned saying that the request was a success, but a code indicating that an error occurred in the processing of the data sent.
If we think that the data sent is also part of the request, if they are invalid and therefore wrong, nothing fairer than to return a code 400, which indicates a bad request.
Looking at the definition of the POST method in RFC strengthens this idea. According to item 4.3.3, a POST request is asking for a particular resource (or Resource) process the data present in the request according to the resource semantics. Therefore, if you submit data that has no meaning for the server, the request will not be understood and should not be processed.
Another argument to strengthen the use of code 400 is the definition of class 4xx and its own definition:
Class 4xx has codes for when the client makes a mistake. If you understand that the client is responsible for sending valid data (and that the server validation is done by security measure) 4xx seems to be the appropriate class. It is important to note that class 4xx, according to RFC, should always return an explanation of the error to the client.
400 code, in turn, indicates that the server cannot, is not able to, or simply will not process the request due to client error (the error of sending data that has no meaning according to the requested resource).
It is important to remember that RFC does not list errors that a client can make, listing only a few examples (syntax error is one of them).
In conclusion, the client is responsible for sending data that makes sense to the server, and if it does not, this should be considered a client error. So I suggest that use code 400 and, as provided in RFC, send a message explaining the error, saying that the data is not valid.
Bonus: Methods that you should definitely not use
418: is not a code in the current RFC and has no semantic value for data validation.
405: should be used only when the method the request is not accepted by the server and not the data itself.
2
This answer expresses my opinion and in no way represents an official or more correct interpretation.
RFC 7321
The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to Something that is Perceived to be a client error (e.g., malformed request syntax, invalid request message Framing, or deceptive request routing).
Error 400 means that the server refuses to process the request due to an error on the part of client-side and there is no problem in using it. I personally prefer to keep it for errors in the request itself, and not for your data. Some libraries can send bug Reports automatic by default due to this response.
You can send the reply as 200, stating that the request was successful, which is true. And then in the content of the answer write whether the API has validated or not and what the errors were. This is the option I use and recommend, since I like to separate the request itself from her data.
I believe to be the second best option, here’s the official translated description:
A request for a resource was made using an order method that is not compatible with that request.
Example: using GET in a form, which requires data to be presented via POST.
This status was created as an April Fool’s prank and is useless, so I think since it has no use, you could assign a "special" use to it.
The RFC 7231 says nothing about low-level and does not list the mistakes a customer can make, just cite examples. So there is no problem in using the 400 as you suggest. In addition, the client should ensure that the data sent to the server is valid. This way the system to report automatic bugs would still be useful in telling you that the client is not validating correctly. Otherwise, the server must provide an appropriate message for the processing error that occurred, with no doubt for the client developer.
@Pablopalaces Thanks for the information I just reread the RFC and I will edit the answer.
1
You can use the same 400.
The definition in http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html says:
The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
translating...
Request could not be understood by server due to syntax wrong form. The client should not repeat the request without modifications.
Lucas, beware of your source as RFC 2616 is obsolete and has been broken into several others. The RFC 7231 is the one in vogue and concerns the subject of this issue.
Reinforcement also should be careful with this. See that the question is clear regarding errors in parameters and not errors in the protocol. The use of error 400 is for syntax errors, for example, a header with a typo such as "contnt-type".. the correct one would be "content-type".. Get it? This causes a 400 error by bad formatting. It has no relation to parameters provided by GET, POST, PUT, DELETE..
@Danielomine the new RFC does not make explicit which type of error should be returned, giving as example syntax errors.
Browser other questions tagged http http-status
You are not signed in. Login or sign up in order to post.
This is a good question, but I believe it is based on opinions due to the fact that Rfcs are not clear at this point, and it is possible to have several interpretations, and therefore opinions about what is the appropriate code.
– ppalacios
Pablo is right, but I think there might be a specific answer based on general consensus.
– Daniel Omine