http - REST response code for invalid data

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

Invalid data passed while user registration like wrong email format

User name/ Email is already exists

I chose 403. I also found following that I feel can be used.

Wikipedia:

412 Precondition Failed : The server does not meet one of the preconditions that the requester put on the request

Suggest code if I should use other than 403.

I am resolving this issue also. Chapter 7.Validation of JAX-RS spec (2017) provides status code advice specifically for constraint violations. download.oracle.com/otn-pub/jcp/jaxrs-2_1-final-spec/… – burntsugar Jan 4, 2019 at 1:21

is the answer. The accepted answer below is wrong. HTTP status codes are a mess, but devs around the world have thought about this long and hard and selected

, not because it's great, but because it's the best we have. Avoid

etc. These have very specific technical meanings and should not be used for other things.

for example is for write/merge conflicts and should prompt the client to show some screen saying 'oops, someone else edited this record in the mean time` and give you a diff screen or something. – Stijn de Witt Aug 24, 2022 at 8:06 This answer by Mike Deck should have been the accepted one: stackoverflow.com/a/9132152/286685 – Stijn de Witt Aug 24, 2022 at 8:08

400 is the best choice in both cases. If you want to further clarify the error you can either change the Reason Phrase or include a body to explain the error.

412 - Precondition failed is used for conditional requests when using last-modified date and ETags.

403 - Forbidden is used when the server wishes to prevent access to a resource.

The only other choice that is possible is 422 - Unprocessable entity.

while it is often used in this context, 403 is not limited to acces control, since rfc2616-10.4.4 says: "The server understood the request, but is refusing to fulfill it. [...] if the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity." The reason can be invalid data. However, 422 is more applicable here. – Yannick Loiseau May 25, 2011 at 14:19 Let's not get caught up in textual criticism. See for example trac.tools.ietf.org/wg/httpbis/trac/ticket/294 which attempts to clarify that 403 is and was always about authorization. – fumanchu May 25, 2011 at 14:44 @fumanchu It means 403 should be return in case of user don't have permission to access requested resource. But I think 401 Unauthorized is more appropriate of accessing resource on which user doesn't have permission. – Amit Patel May 26, 2011 at 4:45 401 Unauthorized will prompt a web browser to show the user the standard HTTP username/password prompt. If you're not using that kind of authentication for your service, or if the user already has HTTP authentication, 401 is not appropriate. – Greg Ball May 9, 2012 at 3:41 This answer is wrong. 400 means that the server did not understand the request. In both cases above, the server understood the request, but is refusing to fulfill it (the definition of HTTP 403). The second case could also arguably be handled with a 409 (conflict). – Greg Brown Aug 21, 2022 at 12:21

I would recommend 422. It's not part of the main HTTP spec, but it is defined by a public standard (WebDAV) and it should be treated by browsers the same as any other 4xx status code.

From RFC 4918 :

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.

Note that the quoted text states that 422 is applicable when the request entity is syntactically well-formed, but semantically erroneous. If the request entity is garbled, 400 is the appropriate response. – Matty K Aug 20, 2012 at 1:59 This seems to have become a de-facto standard. Many API's have opted for

in this scenario and it has gotten independent of WebDAV. – Stijn de Witt Aug 24, 2022 at 7:22 @MattyK is 100% correct. This is THE distinction to make, and is why the accepted answer is wrong.


    400 Bad Request

is for when the server is unable to parse the request. And though 422 was initially defined for WebDAV, it's simply the most suitable response code in the 4xx range and has been selected by so many APIs and frameworks now for validation errors that is has become the standard. – Stijn de Witt Aug 24, 2022 at 7:43

If the request could not be correctly parsed (including the request entity/body) the appropriate response is 400 Bad Request [ 1 ].

RFC 4918 states that 422 Unprocessable Entity is applicable when the request entity is syntactically well-formed, but semantically erroneous. So if the request entity is garbled (like a bad email format) use 400; but if it just doesn't make sense (like @example.com ) use 422.

If the issue is that, as stated in the question, user name/email already exists, you could use 409 Conflict [ 2 ] with a description of the conflict, and a hint about how to fix it (in this case, "pick a different user name/email"). However in the spec as written, 403 Forbidden [ 3 ] can also be used in this case, arguments about HTTP Authorization notwithstanding.

412 Precondition Failed [ 4 ] is used when a precondition request header (e.g. If-Match ) that was supplied by the client evaluates to false. That is, the client requested something and supplied preconditions, knowing full well that those preconditions might fail. 412 should never be sprung on the client out of the blue, and shouldn't be related to the request entity per se .

I should note the updated HTTP/1.1 RFCs: 400 Bad Request, 409 Conflict, 403 Forbidden etc. live in tools.ietf.org/html/rfc7231 ; 412 Precondition Failed is in tools.ietf.org/html/rfc7232#section-4.2 – Matty K Jul 3, 2014 at 3:49 "If the issue is that, as stated in the question, user name/email already exists, you could use 409 Conflict [2] " . No, that's not what


    409 Conflict

is about. It's very specifically about write conflicts. So if your database transaction fails because the record you tried to write was modified by another user in between you reading and changing the record and you writing it, that's exactly what

is for. Think optimistic locking etc. It's not for validation errors.

is the best choice in both of the scenarios described by the OP. – Stijn de Witt Aug 24, 2022 at 7:47 "if the request entity is garbled (like a bad email format) use 400;" Unless the message body was expected to be an email address, I disagree. For scenarios where the message body is expected to be e.g. JSON or XML,


    400 Bad Request

is only for when that JSON or XML is malformed, not for when any of the data embedded in it is wrong. Basically, when you write a server, you do something like


    try {const json = JSON.parse(request.body); if (! isValid(json)) { response.status = 422 } else { response.status = 200 } } catch (e) { response.status = 400}

– Stijn de Witt Aug 24, 2022 at 7:52

It is amusing to return 418 I'm a teapot to requests that are obviously crafted or malicious and "can't happen", such as failing CSRF check or missing request properties.

2.3.2 418 I'm a teapot

Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout.

To keep it reasonably serious, I restrict usage of funny error codes to RESTful endpoints that are not directly exposed to the user.

Implement it such that your API returns


    418 I'm a teapot

for all requests coming from your boss :) – vikarjramun Apr 10, 2017 at 23:33 @vikarjramun i´ve builded a dummy REST and made pruductive one offline. (prerelease) now our students are searching trying to create valid data-requests but it´s all teapot. I´m the "boss" - but it´s working too. – LenglBoy Dec 20, 2017 at 16:06 This RFC is dumb. You can make coffee in a tea pot, so long as you pour it through a tea strainer into your cup. Just like using loose leaf tea. You can also make tea in a cafetiere with no issues. – speciesUnknown Jun 21, 2019 at 15:54 @gburton That does require intervention by a human, though. Over the network, you definitely need a coffee-capable device to make coffee. Of course, a coffee-and-teapot should not respond with a 418. – Jasper Jul 22, 2019 at 11:42 This status code would have been funny if the rest of the HTTP status code was an orderly and clean spec. But it's not, it's a mess, as this question and it's many wrong answers attests to. So humour is great, but not when you are joking around while the real work is a mess. HTTP status codes are 80% focussed inwards. They are about HTTP. When in reality, we need status codes at the application level. The fact that the world is using


    422 Unprocessable Entity

borrowed from WebDAV for a basic thing as validation errors is telling. The HTTP people just forgot... Too busy joking about teapots... – Stijn de Witt Aug 24, 2022 at 7:56

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question . Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers .