Question:
I have an application where I established the following business rule related to user registration:
The user can have multiple addresses linked to him, but it is mandatory that he have at least one address. If he has more than one address he has the option to exclude more addresses, but if he has only one, he will be prevented from excluding it.
If he has only one address and persists in deleting it, the system will throw an exception informing him that he is not allowed to delete the unique address.
Now comes the question, or rather, I want to know your opinion about what would be the most viable HTTP return status for this exception, conceptually speaking?
Below are some examples and why I don't want to use them if there is a more suitable status:
401 Unauthorized – As far as I know, this status is mostly applied to login and access to disallowed places, that is, the user does not have the necessary permission. (I am reluctant to use this status because no one in the system can do this procedure, that is, there is no authorization for anyone, in addition it is an illegal operation, there cannot be a user without an address in the database)
403 Forbidden – I understand that this status informs that the request is valid but the user does not have permission to execute it (As this is a business rule, this type of request is invalid, and not valid as the status suggests, that's why I don't see it as the best option)
I need help identifying what would be the best status for this scenario taking into account the most suitable semantics.
Att.
Answer:
I see two plausible answers: 200 or 409 . Why?
Today, the HTTP protocol provides five groups of responses:
- Group 1xx : informative responses;
- 2xx group: successful responses;
- Group 3xx : Redirect responses;
- Group 4xx : client error responses;
- Group 5xx : server error responses;
Depending on the application, we may have personalized answers, but I won't cover them in the answer.
The situation we find ourselves in is: a user is going to delete an address.
Group 1 already discarded without having to think too much. We will not provide any tentative informational response to the customer; then no response 100, 101 or 102.
Group 2 already seems a little interesting to us and I even put it as a possible answer. Here it will depend on application design issues, as the 2xx group returns represent responses to requests that were successfully received, understood by the server and accepted . Depending on your application's design specifications, the server not allowing the client to delete an address means that it received the request successfully, understood what it should do and accepted the request (client has permission to do so), but not deleting the address could be signaled through the body of the response.
HTTP/1.1 200 OK
...
{
"error": "Você possui apenas um endereço e não pode excluí-lo"
}
Thus, it would be enough for the customer to receive the response and process the body of the same to verify the success of the operation. Other answers from this same group I don't think would fit as possible answers.
We can also eliminate group 3 effortlessly as we will not be doing any kind of client redirection.
Group 4 also looks promising, but let's look at each case.
-
400 Bad Request : not valid. The client's request will be in the expected format that will be understood by the server, so returning error 400 would be confusing. Just imagine the situation: customer is deleting address X and returns 400; if it registers the Y address and deletes X again, it will be successful. How could the same request generate 400 and 200?
-
401 Unauthorized : as stated in the question, the client is authorized to delete the address and falls into the same situation as the previous one. If there is a second address and make the same request, it will be successful. Confused!
-
402 Payment Require d: Yeah, nothing to do with our situation.
-
403 Forbidden : this response indicates that there is accreditation data present in the request, but that the server judged it to be insufficient to allow the client to access that resource; so much so that part of the specification of this answer says that the client should not repeat the request with the same authentication data, otherwise it will receive the same answer. We are not working on authentication issues here.
-
404 Not Found : found it, so forget about this one.
-
405 Method Not Allowed : method is allowed yes, you are forgetting this one too.
-
406 Not Acceptable : response related to content negotiation, which is also unrelated to the case.
-
407 Proxy Authentication Required : it is also nothing to do.
-
408 Request Timeout : Ohhhm, no.
-
409 Conflict : um, conflicts are always cool. Get your popcorn. All kidding aside, let's see what the description of this answer is: the request cannot be completed due to conflicts with the current state of the resource; the customer must resolve the disputes and resubmit the request; the response body must contain enough information for the client to identify conflicts. Trivial! Just respond with 409 and put in the body of the response that the user must register another address to exclude the current one; if you do, it can repeat the same request and succeed.
-
410 Gone : Let it go?
-
411 Length Required : Nah, nothing to see.
-
412 Precondition Failed : name has potential but is related to condition headers, not current resource state conditions; then no!
-
413 Request Entity Too Large : I don't think so, right?
-
414 Request-URI Too Long : man, how did you get to that?
-
415 Unsupported Media Type : what media type? I just want to delete the address, young man.
-
416 Requested Range Not Satisfiable : but I didn't even set the range…
-
417 Expectation Failed : Sorry I didn't meet your expectations… but it also has to do with the request headers, not the user's expectation.
And finally, group 5 . Well, server is healthy, right? We hope so, so no 5xx error for today.
More information in RFC 7231, chapter 6 .