7
What status should I return to my API if a user tries to register with an existing user name or email in the system?
2 answers
6
As there is no convention/standard for the use case presented here, I believe any response is "opinionated" as well as almost all responses presented here in the community regarding the use of status codes for requests HTTP ... I leave here my 2 cents on it:
400 Bad Request (why not use it)
Typically used to describe an invalid request, indicating that the nature of this error is the client’s origin.
Although the RFC 7231 extend the definition proposed by RFC 2616 to make the status code 400 wider and more comprehensive there is any situation that the server may not perceive to be an error of it upon request, believe not to be the use case for the issue presented here since we are assuming that the client has not committed any error when submitting the information intended for registration.
200 OK
I do not believe I need to enter the definition but by far this is the darling of the applications to address the question raised in the question.
Used by large and small applications, for example I cite some that are probably known to most Internet users:
Gmail - make a request
POSTasynchronous by clicking the "next" button after filling in the registration data to check the availability of the email and returns a status 200 with an object that describes the result obtained.Twitter - makes several requests
POSTasynchronous as soon as the user inserts data into the email or phone fields, returning a status 200 with an object that describes the result obtained.Stackoverflow - will "log in" if the email and password are the same already registered, if the password is different will render a page for recovery in the method
GETreturning a status 200Facebook - renders a recovery page with parameters in the method
GETreturning a status 200
I believe the use of status code 200 is appropriate depending on the approach and particularly think that Facebook does it in the best way.
PS: let’s be clear, this is not "suck-up" by the Facebook platform, I don’t even have an account on this network.
409 Conflict (why not use)
To RFC 7231 indicates that the request could not be completed due to a conflict with the current state of the destination resource.
As pointed out in the comments of the question the resource (Resource) can be anything on the server for example:
a manipulated file of any publicly available or non-public format
a reference, value or structure present only (allocated) in the application memory space
a record in the database
etc. ...
This definition really is very broad but on its basis is "implicit" the understanding that "the resource exists(a) on the target server", there is no "conflict in the state" of a resource that does not exist (I may be wrong here but I am open to a qualified definition).
The purpose of a new users registration/registration system in an application is not to modify "a record that already exists", on the contrary its objective is to create a new reference.
Usually as part of the routine it is verified if a certain index (usually the email) already exists in the bad record, this check is not intended to obtain the record to modify it and therefore, I don’t see how "coherent" return a status code 409.
A plausible scenario but outside the scope of the question would be to return 409 in a request to update information previously registered as an email for example. If a new email matches the old email it would be indicated return 409 with a payload indicating the reason/reason for the conflict.
422 Unprocessable Entity (why use it)
The status code 422 was implemented in the RFC 4918 as well as others (207, 423, 424, 507) for "extend" the standard list defined in RFC 2616 as stated in section 11 - Status Code Extensions for HTTP/1.1
As quoted in the comments of the question the code 422 this "related" to Webdav (Web-based Distributed Authoring and Versioning) created by RFC 2518 and updated on RFC 4918
A Webdav server runs on top of a server structure HTTP "common" and before RFC 4918 the status codes described in RFC 2616 were used to describe the errors in the bad request, this RFC (2616) did not have semantically descriptive codes for common errors the operations routinely found, so the need to "add" more status codes to RFC 2616
This status code describes that the server understands the request, that there is no error in the syntax but cannot process it ... this definition is described in section 11.2
One remark here: this section (11.2) "describes a semantic error as an example, not as a rule for error"
The use of status code 422 is not bound (is not obligatory) to be used exclusively by a Webdav (server) system or any versioning system as can be seen in the section 12 - Use of HTTP status codes
I leave here in free translation the substantial part of this section:
In general, many HTTP status codes can be used in response to any request, not only in the cases described in this document.
...
I cannot affirm in a full way by not finding a bad definition, status codes "should/should" be treated in an agnostic manner to the system of application targeted by the request.
I believe the status code 422 should be the most appropriate to answer the question because it fits the following points:
there is no explicit user error in the request syntax (or its contents)
the purpose of the request is not to modify the status of an existing resource
the server understands what has been sent to it but cannot complete the operation
use of this code is not "mandatory" with Webdav or any version system
Completion:
Given the features of the question (no error in the request) avoid using the code 400, although tempting it is generic too much.
Go with the code 200 would not be wrong but the approach is what would in fact define its relevance in relation to the other codes seen the circumstances of the issue.
Avoid the code 409 since the register is not intended to modify an existing record (registration is understood here as a resource).
Go of 422 because "there is no impediment to using it" and this is semantically more consistent with the process that occurs in the question.
Reference:
A complete and official list of protocol status codes HTTP which takes into account all revisions described by RFC’s is maintained by IANA
5
This response is both an opposition and a complement to previous answer. The official specifications of HTTP are succinct and little exemplified, giving room for multiple interpretations, I will contribute with my...
200 OK
I see no sense in returning a status of success to a request that was not successfully executed, despite being a very common practice. In my view, the body should complement the status and not contradict it. If the status is in the crease 2xx, the body should not contain an error message.
409 Conflict
I agree that it should not be used, but I disagree with the reason given. According to the specification, it does not require that the resource already exists, although it is the most likely use, it may be that some other action may generate a conflict, not just changes. An example that might (need a better context review) result in a 409 is the addition/deletion of a file on the server that has already been added/deleted in a previous version.
400 Bad Request and 422 Unprocessable Entity
I disagree, in my view (based on another question in the community), a single key or equivalent structure (any field that may not have repeated the same value) that generates a duplicity error is a syntax error, so a 400 would be the most appropriate, while the 422, semantically incorrect.
500 Internal Server Error
It is an interesting option if you want to report a problem with the field without specifying that it has a repeated value. If you want to protect information (such as email or username), by not disclosing this value directly or indirectly, it seems to me the ideal status. Answering some comments, the 400 might be used for this, but it is strange to answer that the "error is the customer’s" (even if it is) in an error not know the exact reason (actually it is known, but want to be exposed like this).
Completion
I would personally use code 400 or 500, but it is important to point out that there is no right or wrong, only more semantic options than others, and yet there is still the question of interpretation, as I said, that is mine, not necessarily the most semantic, I’m also open to criticism.
-
+1 I have to agree with you, the other answer has pulled quite a lot to force a certain interpretation, and even if webdav not be obligatory to use the 422, yet it is about versioning as the main point, he simply took a single sentence of the RFC and was based on it, which seemed to me to flee from many things, additionally he stated that 409 was specifically about versioning in his question commentary, which simply is not and ended up formulating an answer that looks good [...]
-
[...] but that really pulls a lot to force an interpretation that may not be quite the case. I was going to formulate a counter-response, but I think you’ve done well. If there are disagreements there yes I will unlock the RFC calmly and point out clearly the possible exaggerations of the other answer (if he really is exaggerating in some points, it may not) ... By the way, the author of the question was too hasty to choose how he accepts, I think he should analyze the points too, but there is "another 500"
-
Thank you @Guilhermenascimento, his response is good and has all the official sources, but I disagree on some aspects. I made an edition and also added another option so far not commented, the 500
-
The 500, it’s a case by case, I think it’s very interesting for cases of problems that we can’t detect, or even syntax, usually configuration failures in "third parties", it may be the environment that generates the HTTP responses, but usually refers to settings and errors not "handled", ie some kind of "unexpected" error. Repeating emails or user names seems to me already expected. But it is my personal interpretation, I just think it would complicate using 500 in this case.
-
@Guilhermenascimento as you said, "it is very interesting for cases of problems that we can not detect", the idea is to pass to the user an error that we do not know the reason and specify in the body that is related to the email, suggesting to use another. Thus it is impossible to know with certainty whether the value has already been used or not, whether such field should be private, not providing to any user except the owner of the account, seems to me more appropriate, maybe the 400, but it is strange to say that "the fault is the user" in an error that one does not know what is or wants to be exposed like this
-
@Costamilam I liked to 500, I think it’s nice if you don’t want to return the information that a given record already exists. I was confused as to the routine of an application detecting a possible duplicate and consequently treat the request as a "error of feeling"
-
1
@Lauromoraes if it is not a syntax error, what kind of error would it be? I understand it’s what fits best, but as I’ve said and repeated, it’s a matter of interpretation
-
Good answer. + 1, inclusive. : ) However, I disagree that the status 500 can be used in this case, since it indicates that there is a server related error, which is not the case, since the error is client. If I were to choose a status, I would choose the 409, which emphasizes a conflict. If the goal was to protect user names, I would opt for 400, which indicates that the error was the client’s.
Browser other questions tagged http http-status
You are not signed in. Login or sign up in order to post.
Do you have any idea? Which one would you use and why?
– Woss
I thought about the 409 because there is a conflict between the information of the system and those being sent.
– osor1o
It’s a good choice. Many applications also use the 200, indicating that the request has been successfully processed and the conflict is indicated by the response body.
– Woss
Vote on 409 - Conflict, better let HTTP explain what happens, with some detail of what error occurred in the body message
– nullptr
409 or 200 with the error message on the body
– rnd_rss
422 Unprocessable Entity (client error) - the server understands the request, the syntax is correct but the server cannot process ... I am skeptical about stating that an email is already registered bad, most of the great services do just this and with a status 200
– Lauro Moraes
@Lauromoraes personally do not agree with the 422 for this case (I’m not sure so far), the 422 is used for some problem in the content structure sent, not error itself, for example a XML sent may have the correct syntax, but not this "semantic"422 would be fine, if it’s a syntax error right there then the code could be 400 (bad request). Take into account that this code is also aimed at Webdav, so if I understood it refers to files and changes/versions of documents (but that’s what I understood, correct me if I was wrong).
– Guilherme Nascimento
@Guillhermenascimento 409 is used when there is version conflict as described in RFC 7231 ... a user register does not operate on changes and versioning, the query to the database does not aim to change/modify the existing record, then return 409 doesn’t seem right to me
– Lauro Moraes
@Lauromoraes but I didn’t say it was, I just talked about the same 422, which refers to the webdav. Now talking about 409, I read the link you sent and it doesn’t talk about versioning, Resource can be anything on the server side, the 409 can be any kind of conflict and this should be described in the body of the answer, it depends a lot on what will work, the term "source" described there does not refer to "documents" but rather to "something intended", in fact the question of versioning falls precisely in 422 (remembering that refers to webdav) [...]
– Guilherme Nascimento
[...] So to date 422 seems to me that it certainly does not serve (webdav ok?!) and 409 first seems to "serve" because it is comprehensive (Semantics and Content) and waiting for the description of the conflict to be in the body, but still have doubts about this... To bolster @Lauromoraes RFC7231 refers to Semantics and Content and RFC4918 refers to Webdav (this is yes to "versions")
– Guilherme Nascimento