400 BAD request HTTP error code meaning?
Clash Royale CLAN TAG#URR8PPP
400 BAD request HTTP error code meaning?
I have a JSON request which I'm posting to a HTTP URL.
Should this be treated as 400 where requestedResource field exists but "Roman" is an invalid value for this field?
400
requestedResource
"Roman"
[requestedResource:"Roman"]
Should this be treated as 400 where "blah" field doesn't exist at all?
400
"blah"
[blah:"Roman"]
Roman
A real scenario where I saw this - I did a PUT call to add some data. I did a put call again using the same request body and got a 400 which told me that a previous request is being already processed. Its normal for our system to take some time to add that data.
– testerjoe2
Jul 13 '17 at 21:58
7 Answers
7
A 400 means that the request was malformed. In other words, the data stream sent by the client to the server didn't follow the rules.
In the case of a REST API with a JSON payload, 400's are typically, and correctly I would say, used to indicate that the JSON is invalid in some way according to the API specification for the service.
By that logic, both the scenarios you provided should be 400's.
Imagine instead this were XML rather than JSON. In both cases, the XML would never pass schema validation--either because of an undefined element or an improper element value. That would be a bad request. Same deal here.
I agree with you up to "By that logic, both the scenarios you provided should be 400's." I don't think content of the JSON should matter here. When you say malformed I would like to believe that addresses the issues in the format of the data you send, for example if you skip a field in the JSON you should get 400.
– Geethanga
Aug 7 '14 at 3:24
There is a decent set of REST response codes at restapitutorial.com/httpstatuscodes.html. It may also depend on how you want to handle a valid request such as a 406 (Not Acceptable) or 405 method not allowed. However, 400 is appropriate because "The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications."
– Andrew Scott Evans
Oct 30 '15 at 19:12
I agree with you
– koogua
Jun 6 '16 at 2:57
So "The request could not be understood by the server due to malformed syntax" can be either of the request (for example, one of the HTTP headers being malformed) or the data carried by the request (for example, a JSON value missing)?
– MC Emperor
Jan 3 '17 at 15:12
Vidya says "the XML would never pass schema validation". Point being that XML parsers distinguish between a document being well-formed (i.e. syntactically sound) and valid (i.e. semantically sound, e.g. according to a schema). The description of the 400 code is "the request could not be understood by the server due to malformed syntax" - so it shouldn't be used for validation errors, imho.
– Martin Lie
Mar 6 '17 at 4:28
From w3.org
10.4.1 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.
The correctness of returning an error 400 isn't based on a field vs a value but the request as a whole. I think HTTP 400 is a good way to go
– Jason Sperske
Oct 29 '13 at 23:56
Do you mean that a 400 response be used to tell clients that anything, i.e. url, headers, body etc., in the request could be wrong and not just the body ?
– testerjoe2
Nov 1 '17 at 19:03
well for url the correct code is 404, for headers, I guess it's a toss up, 403 (forbidden) seems like the right way to go if headers are rejecting identity, but what if headers are determining output format? about the only path I think feels right for 400 is in the situation where an action is being requested that does not make sense and should not be repeated. I wrote this answer 4 years ago, these days I feel like even errors should return 200, and that errors should only apply to the http transmission and not the payload.
– Jason Sperske
Nov 1 '17 at 21:33
This answer covers a lot of this, though I haven't read through all of the charts yet stackoverflow.com/a/34324179/16959
– Jason Sperske
Nov 1 '17 at 21:37
Selecting a HTTP response code is quite an easy task and can be described by simple rules. The only tricky part which is often forgotten is paragraph 6.5 from RFC 7231:
Except when responding to a HEAD request, the server SHOULD send a
representation containing an explanation of the error situation,
and whether it is a temporary or permanent condition.
Rules are as following:
So in your case I'd returned 400 error and something like this if "Roman" is obtained from user input and client must have specific reaction:
"error_type" : "unsupported_resource",
"error_description" : ""Roman" is not supported"
or a more generic error, if such situation is a bad logic error in a client and is not expected, unless developer made something wrong:
"error_type" : "malformed_json",
"error_description" : ""Roman" is not supported for "requestedResource" field"
In neither case is the "syntax malformed". It's the semantics that are wrong. Hence, IMHO a 400 is inappropriate. Instead, it would be appropriate to return a 200 along with some kind of error object such as "error": "message": "Unknown request keyword" or whatever.
"error": "message": "Unknown request keyword"
Consider the client processing path(s). An error in syntax (e.g. invalid JSON) is an error in the logic of the program, in other words a bug of some sort, and should be handled accordingly, in a way similar to a 403, say; in other words, something bad has gone wrong.
An error in a parameter value, on the other hand, is an error of semantics, perhaps due to say poorly validated user input. It is not an HTTP error (although I suppose it could be a 422). The processing path would be different.
For instance, in jQuery, I would prefer not to have to write a single error handler that deals with both things like 500 and some app-specific semantic error. Other frameworks, Ember for one, also treat HTTP errors like 400s and 500s identically as big fat failures, requiring the programmer to detect what's going on and branch depending on whether it's a "real" error or not.
+1, The P in HTTP stands for Protocol and if the response is an HTTP error, it should be a low-level problem. I’ve avoided a lot of code complexity over the years using the approach described by torazaburo. There would be less pain in REST land if we all wrote resilient code instead of so frequently blowing up with HTTP errors.
– Dem Pilafian
Aug 4 '16 at 3:55
200 means that request has been processed, so a normal success logic should be executed on a client. Here we definitely have an error, so response can't have 2xx or 3xx code. It can't be 5xx either because that's a server side error and we have an error on client side. So that must be an 4xx error. But the error description in response body is a right thing to do and is actually a way advised by HTTP specification.
– Alexey Guseynov
Sep 22 '16 at 16:38
Using 400 status codes for any other purpose than indicating that the request is malformed is just plain wrong.
400
If the request payload contains a byte-sequence that could not be parsed as application/json (if the server expects that dataformat), the appropriate status code is 415:
application/json
415
The server is refusing to service the request because the entity of
the request is in a format not supported by the requested resource for
the requested method.
If the request payload is syntactically correct but semantically incorrect, the non-standard 422 response code may be used, or the standard 403 status code:
422
403
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated.
no, 415 is for when the entity is claimed to be of the wrong type eg
image/gif instead of text/json in the Content-Type: header. - presumably this is also applicable if a component of a multipart has the wrong type specified, see tools.ietf.org/html/rfc4918 where it discusses 422 for more discussion,– Jasen
Sep 8 '17 at 0:21
image/gif
text/json
Content-Type:
Think about expectations.
As a client app, you expect to know if something goes wrong on the server side. If the server needs to throw an error when blah is missing or the requestedResource value is incorrect than a 400 error would be appropriate.
blah
requestedResource
First check the URL it might be wrong, if it is correct then check the request body which you are sending, the possible cause is request that you are sending is missing right syntax.
To elaborate , check for special characters in the request string. If it is (special char) being used this is the root cause of this error.
try copying the request and analyze each and every tags data.
I was getting http 400 error, I checked my request had some special characters. To fix that, I passed the charset=UTF-8 in the content type.
– Kislay Kishore
Aug 24 '17 at 9:53
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
Maybe 402, if they really want to be able to send the value
Roman, they just need to pay you more :)– Jason Sperske
Oct 30 '13 at 0:08