291

What response code should be passed to client in case of following scenarios?

  1. Invalid data passed while user registration like wrong email format
  2. 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.

Kowser
  • 7,713
  • 6
  • 39
  • 60
Amit Patel
  • 14,288
  • 17
  • 61
  • 100
  • Possible duplicate: http://stackoverflow.com/questions/3050518/what-http-status-response-code-should-i-use-if-the-request-is-missing-a-required – Genjo Aug 29 '16 at 10:34
  • I am resolving this issue also. Chapter 7.Validation of JAX-RS spec (2017) provides status code advice specifically for constraint violations. https://download.oracle.com/otn-pub/jcp/jaxrs-2_1-final-spec/jaxrs-2_1-final-spec.pdf?AuthParam=1546559699_8a1c42b298288ed02e280d293e710306 – burntsugar Jan 04 '19 at 01:21

4 Answers4

322

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.

Darrel Miller
  • 129,370
  • 30
  • 183
  • 235
  • 10
    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 '11 at 14:19
  • 7
    Let's not get caught up in textual criticism. See for example http://trac.tools.ietf.org/wg/httpbis/trac/ticket/294 which attempts to clarify that 403 is and was always about authorization. – fumanchu May 25 '11 at 14:44
  • 2
    @fumanchu Nice catch. A link to a change request that is only 7 hours old :-) – Darrel Miller May 25 '11 at 15:31
  • 1
    @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 '11 at 04:45
  • @fumanchu It is also stated that "Authorization will not help and the request SHOULD NOT be repeated." for 403. What I understand here is is even you have special privileges/permission, you cannot access resource. – Amit Patel May 26 '11 at 04:58
  • @Amit The link that @funmanchu pointed to is a recommendation to remove the line you quoted because of the confusion that it is causing. – Darrel Miller May 26 '11 at 11:04
  • My comment was mostly in response to Yannick. Sorry for not making that clear. – fumanchu May 26 '11 at 15:30
  • 1
    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 09 '12 at 03:41
  • @DarrelMiller Please do you think you could help me with this question http://goo.gl/qiOdmT – Axel Nov 10 '14 at 03:36
  • ode to report client bug – Mawg says reinstate Monica Dec 07 '15 at 10:07
  • [this](https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm) explains 400 vs 422 well. – Amber Kulkarni Feb 27 '18 at 05:28
  • @GregBall The browser will not normally do anything with the response from an Ajax call. That's left up to the script making the call. So actually, 401 is just fine for REST apis. You are right when it comes to web pages. But for REST apis it's perfectly fine. – Stijn de Witt Oct 22 '18 at 11:02
  • On the first scenario I will choose 400, because the user could know the right format before create his "bad request". On the second scenario I prefer to use 422, because the request format is correct but some internal validation refuses his request. – Dherik Jan 15 '20 at 12:23
102

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.

Mike Deck
  • 17,069
  • 15
  • 62
  • 89
  • 20
    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 '12 at 01:59
95

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.

Matty K
  • 3,393
  • 1
  • 20
  • 19
  • 1
    I should note the updated HTTP/1.1 RFCs: 400 Bad Request, 409 Conflict, 403 Forbidden etc. live in http://tools.ietf.org/html/rfc7231 ; 412 Precondition Failed is in http://tools.ietf.org/html/rfc7232#section-4.2 – Matty K Jul 03 '14 at 03:49
42

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.

Community
  • 1
  • 1
doug65536
  • 6,014
  • 2
  • 37
  • 51
  • 12
    Implement it such that your API returns `418 I'm a teapot` for all requests coming from your boss :) – vikarjramun Apr 10 '17 at 23:33
  • 2
    @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 '17 at 16:06
  • 2
    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 '19 at 15:54
  • 2
    @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 '19 at 11:42