What would be the best HTTP response to inform the client that it cannot delete a single record?

Question

I have an application where I established the following business rule related to user registration:

The user may have multiple addresses linked to him, but it is mandatory that he has at least one address. If he has more than one address he has the option to delete the extra addresses, but if he has only one, he will be prevented from deleting it.

If it has only one address and persists in deleting it, the system will release an exception stating that it is not allowed to delete the unique address.

Now comes the doubt, or rather, I want to know the opinion of you on 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 more applied to the issue of login and access to places not allowed, ie 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, ie there is no authorization for anyone, besides it is an illegal operation, there can be no user without address in the database)

403 Forbidden - I understand that this status informs that the request is valid but the user is not allowed to execute it (As it is a business rule this type of request is invalid, and not valid as the status suggests, so I do not see it as the best option)

I need help to identify what would be the best status for this scenario taking into account the most appropriate semantics.

Att.

Answer 1

I understand two plausible answers: 200 or 409. Why?

Today, the HTTP protocol provides for five response groups:

1. Group 1xx: informative answers;
2. Group 2xx: successful responses;
3. Group 3xx: redirect responses;
4. Group 4xx: customer error answers;
5. Group 5xx: server error replies;

Depending on the application, we may have personalized answers, but I will not address them in the answer.

The situation we find ourselves in is: a user will delete an address.

The group 1 We’ve ruled it out without having to think long. We will not give any provisional informative response to the customer; so no response 100, 101 or 102.

The group 2 It already seems to us a little interesting and I even put as a possible answer. Here will depend on application design questions, as the returns of the 2xx group represent responses to requests which were successfully received, understood by the server and accepted. Depending on the design specifications of your application, the server does not allow the client to delete an address means that it has successfully received the request, understood what it should do and accepted the request (client has permission to do so)but the non-exclusion of the address could be signalled 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 client to receive the answer and treat the body of the same to verify the success of the operation. Other answers from the same group I don’t think would fit as possible answers

The group 3 we can also eliminate effortlessly as we will not make any kind of customer redirect.

The group 4 also looks promising, but let’s look at each case.

• 400 Bad Request: is not valid. The client 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: client is deleting the X address and returns 400; if he registers the Y address and re-deletes X, he will succeed. How could the same request generate 400 and 200?

• 401 Unauthorized: As stated in the question, the customer is authorized to delete the address and falls into the same situation as the previous one. If there is a second address and you make the same request, you will be successful. Confusing!

• 402 Payment Required: Yeah, nothing to do with our situation.

• 403 Forbidden: this response indicates that there is present accreditation data in the request, but that the server judged to be insufficient to allow the client to access such 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 he will receive the same response. We are not working with authentication problems here.

• 404 Not Found: found, so forget this.

• 405 Method Not Allowed: method is allowed yes, are forgetting that too.

• 406 Not Acceptable: response related to content negotiation, which also has no relation to the case.

• 407 Proxy Authentication Required: yeah, nothing to do with.

• 408 Request Timeout: Hm, no.

• 409 Conflict: um, conflict is always legal. get your popcorn. Joking aside, let’s see what the description of this answer: the request cannot be completed due to conflicts with the current status of the resource; the client must resolve the conflicts and forward the request; the body of the response must contain sufficient information for the client to identify conflicts. Trivial! Just answer with 409 and put in the body of the reply that the user must register another address to delete the current one; if you do, he can repeat the same request and get success.

• 410 Gone: Let it go?

• 411 Length Required: Nah, nothing to do with it.

• 412 Precondition Failed: name has potential, but is related to condition headers, not current resource status conditions; so no!

• 413 Request Entity Too Large: I guess not, right?

• 414 Request-URI Too Long: Man, how did you get on this?

• 415 Unsupported Media Type: what media type? I just want to delete the address, young man.

• 416 Requested Range Not Satisfiable: but I don’t even define the range...

• 417 Expectation Failed: sorry it doesn’t meet your expectations... but it also has to do with the header of the request, not with the expectation of the user.

And finally, group 5. Well, server is healthy, right? We hope so, so no 5xx error for today.

More information on RFC 7231, Chapter 6.