The data could not have been inputted by a typical user due to client-side validation. Is "400 Bad Request" the appropriate status code?
If you are certain the form is invalid 400 Bad Request is acceptable. However depending on why you believe a form is invalid you may also choose to use
status code 422 Unprocessable Entity.
This status code is designed to handle the use case where an submitted request is understood by the server and the request is syntactically correct, but the server was unable to process the instructions contained within the request.
Another possibly appropriate error code would be 415 Unsupported Media Type. This error code should be used when the server fails to understand the request due to an invalid type of form. For example, if a server expected a JSON value but was given XML it should in theory return a 415 Unsupported Media Type code.
Related
My application allows file upload. As a restriction I want to restrict files with only certain extension (say pdf for example)
So in case a file with pdf extension is uploaded, I return 200/201 ok status code to indicate the successful upload.
I am confused, what should I return for non-pdf files after reading multiple answers-
400 - argument to return 400 bad request is that request failed due to validation. Argument to not to use is sometime it also indicates syntactical error while making the request.
415 - argument to return 415 Unsupported Media is that file extension is not same. (Considering Media as file), but content type (multipart/form-data) matches and is supported.
422 - Argument to use 422 unprocessable entity is that server understands the content-type (multipart/form-data) but still can't process the request. But other though is, it can still process if the use case is only to upload the file.
From MDN:
415 Unsupported Media Type
The HTTP 415 Unsupported Media Type client error response code indicates that the server refuses to accept the request because the payload format is in an unsupported format.
The format problem might be due to the request's indicated Content-Type or Content-Encoding, or as a result of inspecting the data directly.
I think the last sentence specifically suggests that 415 is not strictly for unsupported Content-Type headers.
We have a REST service where the response to a request may be an error message. A simple example is the request is a formula to calculate and the formula might have a divide by zero. In that case the response is an error code and error message.
So the communication with the REST service is all good. The service itself is responding to the request. But the response is an error message instead of the expected result.
In this case what is the best response code to use? 200 to say the entire communication process is good and we look in the returned JSON to determine if it’s an error? 500 to say it’s an error, but then look to see if we have the expected JSON to determine it was an error in the calculation? Some other code which says we are getting a response from the server but the response is an error message?
A simple example is the request is a formula to calculate and the formula might have a divide by zero. [...] In this case what is the best response code to use?
I would use 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.
Don't rely only on HTTP code anyway, always add a description of the error in the body. I believe it's common practice to have all your endpoints reply with a JSON with success (true or false) and something like error (with the error message) if success if false, or data (with the result) if success is true.
For error messages we can use 4XX Bad Request
Look at this post, for various status codes.
http://www.restapitutorial.com/httpstatuscodes.html
Using a following API:
feed?url=XXX
Validations performed on the parameter url:
If missing: 400 Bad Request
If empty/invalid URL: 422 Unprocessable Entity
If URL don't point to a valid RSS/Atom feed: 422??
What status error should be returned for the 3.?
Unlike validation 2., it is not possible to check the 3. without fetching data and trying to parse it, so raw user data can't be directly validated.
I was thinking about 422 Unprocessable Entity because it is related to validation even if is not directly the data (url) but the reference of this data (content of the url).
What is your opinion?
422 is inappropriate for #2 and #3. It relates to the server understanding the Content-Type header, but the actual content in the HTTP request body could not be interpreted.
I think you could make the argument that 502 Bad Gateway is appropriate here. It's a bit weird because the problem is both user error (incoming url parameter, so a 4xx code), but also it's kind of happening on the server, and in particular an origin server (which makes sense as a 5xx and specifically 502).
But if in this context you strictly consider this an issue that the client caused (bad input in the url) and not server-side, then I would say that there's not a specific enough error code for this, and you should probably just stick to 400 for all of them.
And maybe.. perhaps you can make the argument that 409 might work here. A 409 can used in a case where:
There is nothing in particular wrong with the HTTP request perse.
But the state of another resource is causing the request to fail.
Typically that 'other resource' lives in the same system, but I don't see why the external Atom feed could also not be considered as conflicting.
Because if the Atom feed on the external server is 'fixed', then the original HTTP request that the user made will now work. So a 409 kind of is appropriate here.
I have a bunch of PUT operations which execute actions on the input resource.
Let's make an example: I have a payment operation in my API which state that a credit card must be charged by a specific Amount.
In my code I first verify if there is sufficient credit on the card and then execute the operation. If there is'nt sufficient amount I simply return 400 but I am not sure it is correct.
Which is the correct HTTP Status Code in cases like this?
I can, of course send a response with HTTP 200 and attach a payload with further details explaining the error. I can also send back an HTTP 400 Bad Request or even better an HTTP 412 Precondition Failed.
Which is the correct code to send in the response in scenario like this where the validation failed? Is there any resource that I can read to understand the rationale behind HTTP Status Codes and HTTP Verbs?
Use 422 Unprocessable Entity.
The 422 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.
Failing that, simply use 400 for any error having to do with your business domain. As of June 2004, the description for error 400 was amended to read:
The server cannot or will not process the request due to something that is perceived to be a client error
If the operation failed because of data sent by the user (it seems to be the case), you should use status codes 400 (general) or 422 (more precise but coming from the WebDAV spec). You can return back additional hints about the error within the payload (the structure is up to you) like:
{
error: {
"field": "amount",
"message": "The amount isn't correct - Sufficient credit."
}
}
I think that code 412 doesn't apply here since it must be returned when your server doesn't meet a condition specified by the client (see headers If-* like If-Match, If-Modified-Since, ...).
Hope it helps you,
Thierry
IMO: I would stick with 200 and then parse out the response and deal with that. HTTP status codes are protocol status code, not something that you should use for dealing with application logic.
{
"error": {
"field": "amount",
"message": "The amount isn't correct - Sufficient credit."
}
}
In case of the above code, the service call worked fine warranting a return code 200. However, you application logic now needs to deal with the error reported.
If we are using a HTTP status code to indicate error, we will start to get flagged in our logs etc. even though there was no technical error.
What is the most appropriate response code to return when using the PUT method to update a resource, and the request contains some data that would invalidate the domain rules?
For example, a customer resource must have a name specified. If an agent tries to issue a PUT without supplying a name I don't want to update the resource, and I want to tell the caller that they need to supply a name.
What HTTP response code?
How about 422?
"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."
RFC 4918, Section 11.2
The response code is not related to the http method in this case. You should return the same status code as if it had been a POST request. I'd say you should use 400 or 409 (Note: See further discussion of the difference between the two in the comments).
I would return a 400. Strictly, this is for "malformed syntax" (not invalid data), but in practice the YouTube, Twitter, etc. use it for more generally "bad" requests.