REST HTTP status code if DELETE impossible

My question is quite a generic one about HTTP status code when a DELETE is impossible on the resource (but not regarding user's rights).

We have a RESTful API on a type of resource.

The DELETE method is authorized on the resource however under some conditions a resource cannot be deleted (if there are data binded to this resource).

What is the correct HTTP status code to return to the client in this situation?

Here are some of the possibilities I gathered and why it seems inappropriate in my case :

• 403 (Forbidden) : Seems mostly related with user's rights.
• 405 (Method Not Allowed) : Seems like the API is not designed to respond to this method for this type of resource.
• 409 (Conflict) : Seems appropriate but the client should have the possibility to resolve the conflict with the API but that's not the case here.

Update : The data binding that prevents the resource to be deleted cannot be changed via the REST API. However the resource can be "freed" via other way as the database from which the data comes from is also accessed by other apps that may change the state of a resource (an SQL DELETE in the DB can always do that).

Solution 1:

I'd say 409 is the most appropriate, given it's wording in the RFC:

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.

(emphasis mine)

Based on my understanding of the description in the question, the reason for DELETE not being allowed is exactly a conflict with the current state of the target resource. As indicated in the RFC, the response payload can give an indication of the reason and, optionally, the user might be able to resolve it. I don't see anything in the spec that makes 409 inappropriate just because the API doesn't offer a conflict resolution possibility.

Solution 2:

A 409 Conflict response is definitely wrong if the client can't resolve the conflict and delete the request later. That is, unless the resource has state tracking whether it can be deleted or not, 409 Conflict is not a good fit.

A 403 Forbidden doesn't necessarily mean not authorized:

However, a request might be forbidden for reasons unrelated to the credentials.
   -- RFC 7231

The implication is usually there, though. You can use this code, but it may cause some confusion. It'll be especially tricky if the method actually requires authorization also - you'll need a code or something in the response indicating whether the failure was related to authorization or the resource being non-deletable.

I think that 405 Method Not Allowed is the correct way to go.

The 405 (Method Not Allowed) status code indicates that the method received in the request-line is known by the origin server but not supported by the target resource.
   -- RFC 7231

The method DELETE is not supported for this resource. That sounds exactly like what you're describing. The HTTP spec doesn't really have a concept of a type of resource - just a resource. It happens that people group individual resources under the same endpoint for sanity, but that's just a convenience for developers and users. As far as the HTTP spec is concerned, /widgets/12 and /widgets/15 and /widgets/3453 are three different resources. The fact that the same object represents all three of those resources on the server is completely irrelevant. I think that's the "type" you're thinking of, but to HTTP that's just an implementation detail.