18

I am building RESTful API and I have come across a situation. During user sign up, if the email already exists then between 422 and 409 which http response code makes sense?

I have browsed through similar one and the accepted answer is from the year 2012. Does the answer still hold good? Examples would be of great help.

curious_coder
  • 2,392
  • 4
  • 25
  • 44
  • Does this answer your question? [HTTP response code for POST when resource already exists](https://stackoverflow.com/questions/3825990/http-response-code-for-post-when-resource-already-exists) – Michael Freidgeim Jul 15 '21 at 05:16

2 Answers2

20

You may not find a very definitive answer to this question, once both 409 and 422 would be suitable for this situation (I would go for 409 though).

For any of them, you must ensure that a payload describing the problem is sent back to the client.

6.5.8. 409 Conflict

The 409 (Conflict) status code indicates that the request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server SHOULD generate a payload that includes enough information for a user to recognize the source of the conflict. [...]

11.2. 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.

Community
  • 1
  • 1
cassiomolin
  • 124,154
  • 35
  • 280
  • 359
  • 2
    `409` is for `PUT`/`POST` when you use `ETag`. It is not designed to be an indicator of a business error. – gavenkoa Mar 22 '20 at 10:05
  • @gavenkoa I think `ETag` usage is more connected to `412 Precondition Failed` and `304 Not Modified` – Connell Oct 20 '20 at 10:35
  • 2
    `409` is a `Conflict` for `PUT`, like 2 requests concurrently update same entity, one succeeds, another `409` because ETag has been updated. Some frameworks/libs/server might emit 409 automatically, for that reason I'd prefer `422` - there is a guaranty no one except my code emit it, so monitoring tool reports won't be false positive (because `409` is shared with some predefined HTTP/RFC semantic). – gavenkoa Oct 20 '20 at 11:03
  • Had the same choice between 409 & 422, and also went with 409 at the end. Put the rationale in what I hope can be named as a definitive answer: https://stackoverflow.com/a/70371989 – wombatonfire Dec 16 '21 at 00:54
  • @gavenkoa `409` is not just for a `PUT` request. It can be for any request. The RFC just says it's most likely to occur with a `PUT`. It's about state. – Jack B Jul 21 '23 at 10:41
5

I think 409 is most appropriate in this described example as the request is conflicting with an already existing registration.

For example, if the service couldn't accept a .de domain based email address; 422 seems preferable. This example would also not qualify for a 400 as a .de domain would be valid syntax.

David G
  • 161
  • 2
  • 6