30

I have a resource like this sales/customers/{customerno}. If a client sends a PUT request to this resource I would return 400 - Bad request if the xml in the entity body is not valid xml. But what if the xml is valid, but the content of the xml is not valid. Say for instance that the client is trying to update the customers PostCode and is providing a PostCode which is not valid. Is it correct to return 400 - Bad request in this case, or is it another http code I should have used?

jamesmortensen
  • 33,636
  • 11
  • 99
  • 120
rgullhaug
  • 1,065
  • 2
  • 10
  • 19

2 Answers2

34

From Wikipedia's List of HTTP Status Codes:

400 Bad Request: The request cannot be fulfilled due to bad syntax.

In this case, your client sent you an XML payload that had an invalid zip code, which is a form of invalid syntax; therefore, sending a 400 Bad Request is an appropriate error code to return in this situation.

In addition, Wikipedia cites RFC-4918 as a resource on this topic. From this document, you'll find the following information:

Servers MAY reject questionable requests (even though they consist of well-formed XML), for instance, with a 400 (Bad Request) status code and an optional response body explaining the problem.

Since your request is well-formed (the XML isn't bad, it just contains semantically incorrect information) you may reject the content with status code 400. The word *may* suggests that there are other options.

While you might be tempted to use status code 422, this would not be correct in this situation, since the invalid zip code does not meet the criteria to be a semantic error. Read below...

From Wikipedia:

422 Unprocessable Entity (WebDAV; RFC 4918): The request was well-formed but was unable to be followed due to semantic errors.

In addition, here are some definitions to assist in the interpretation of status code 422:

  • Syntax errors occur during the parsing of input code, and are caused by grammatically incorrect statements. Typical errors might be an illegal character in the input, a missing operator, two operators in a row, two statements on the same line with no intervening semicolon, unbalanced parentheses, a misplaced reserved word, etc.

  • Semantic errors occur during the execution of the code, after it has been parsed as grammatically correct. These have to do not with how statements are constructed, but with what they mean. Such things as incorrect variable types or sizes, nonexistent variables, subscripts out of range, and the like, are semantic errors.

Your invalid zip code is neither a syntax error nor a semantic error; thus, it's reasonable to rule out status code 422 as an option.

To answer your question, status code 400 is appropriate; however, you may have other options as well.

jamesmortensen
  • 33,636
  • 11
  • 99
  • 120
  • And the other options are? – Aaron McMillin Dec 30 '13 at 21:44
  • 2
    I found this useful but I'm a little confused by the conclusion. I understand that there's a computer science definition of "semantic" that differs from its general use. Outside of computer science, an invalid zip code could indeed be called a semantic error in this context. I suspect you're correct that the RFC meant it specifically in the computer science sense, but then how useful could such an error ever be? In fact how could it be a *client* error at all, then? – Semicolon Sep 29 '14 at 20:50
  • @Semicolon - My understanding is that if the XML was well-formed but the zip code was out of range, that would meet the definition in the last bullet point. In the US, 123456 would be a bad zip code, for instance, but it wouldn't be invalid XML. An error saying "400 Bad Request - Please enter a valid zip code", could be helpful if sent back to the client. Hope this helps. – jamesmortensen Sep 30 '14 at 03:57
  • 2
    I can't understand about 422 status. If zip code 123456 is invalid, it is semantic (logical) error, isn't it? In this way we should use 422 status. – surfrider Mar 26 '16 at 20:39
  • 3
    @surfrider - What clarifies is the last sentence of the "semantic" definition. When they say semantic errors, they refer to incorrect variable size or type, nonexistent variables, out of range subscripts, etc. The invalid zip code seems like a data issue, not a data type or data size issue, array subscript out of range, etc... – jamesmortensen Apr 04 '16 at 15:45
  • 2
    Actually, there is one example I can think of. If you've sized your data type to only take 5 digits and you give it 6, then I do think you could make a case for using status code 422, but I think that's just a side effect of exceeding the data type length and not because of the actual data being invalid. I could still give an invalid 5 digit zip code that wouldn't exceed any variable limits, and in that case I don't think we could justify status code 422. Hope this helps. – jamesmortensen Apr 04 '16 at 15:46
  • @jmort253 I know I'm late, but it seems like the same reasoning used for out of range indices can be used for invalid zipcodes. In the same way that an index that's out of range is an invalid data value assigned to a variable, a wrong zipcode is an invalid data value assigned to an XML field. – code_dredd Feb 19 '19 at 19:16
  • @Code This was a long time ago, so I don't 100% remember my thought process, but one thing I see is that an invalid ZIP code doesn't render the XML invalid. A malformed XML tag would make for invalid XML. It's still possible to have valid XML that can be parsed by an XML parser, but it just happens to contain data that, from the application domain, is not valid. I suspect that is the main difference. – jamesmortensen Feb 20 '19 at 08:51
  • Is `400 Bad Request` ok when you expect to receive a request through the POST method and the client sends a GET instead? – tonix Sep 29 '19 at 17:18
  • @tonix I think that's what I would do. – Mark McKenna Oct 28 '19 at 13:04
  • 1
    @tonix In that case I think you should return 405 - Method Not Allowed – oren Aug 14 '21 at 16:05
17

The revised version of the HTTP spec found here has updated the wording to try and avoid this confusion about 400 being limited to just malformed requests.

7.4.1. 400 Bad Request

The server cannot or will not process the request, due to a client error (e.g., malformed syntax).

Community
  • 1
  • 1
Darrel Miller
  • 139,164
  • 32
  • 194
  • 243
  • Does 400 code also include id`s in the payload the user is not resource owner of? – Elisabeth Jun 29 '17 at 17:50
  • @Elisabeth Not sure I fully understand your scenario but I think the answer is yes. – Darrel Miller Jun 30 '17 at 03:55
  • The scenario is a payload with some foreign-key Id´s which belong to another user. Deleting those id`s on the server would delete resources of another user. That would be really bad. – Elisabeth Jul 01 '17 at 17:38
  • @Elisabeth Then yes, I think a 400 is suitable to tell a user that the request the submitted is not a reasonable request. In your scenario, because the related resource belongs to another owner, it is possible that 403 Forbidden might be a more precise status code. – Darrel Miller Jul 06 '17 at 03:07
  • Thanks Darrel :-) – Elisabeth Jul 12 '17 at 18:23
  • 1
    @Elisabeth I think I'd use 403 in your case, because it's more specific--it's likely a client error to ask to delete those resources, but it's an error because it's forbidden. This would be more informative. – Mark McKenna Oct 28 '19 at 13:09