Expected HTTP status code for an action on a disabled resource

Question

What would the expected/proper HTTP status code on an action given the following:

• the request syntax is correct (eliminates 400 )
• user is authenticated (eliminates 401 )
• user is authorized to perform the action (eliminates 403 )
• location/resource exists (eliminates 404 )
• method is implemented (eliminates 501 )
• no server error (eliminates 5xx )

The resource is currently disabled thus preventing the action from completing with the expected result. The user has the ability to change the state of the resource and retry the same request. Information on the why the resource could not do what was asked would be included in the response body.

My thought is that 409 Conflict would be the best response as user could potentially change the state of the resource and resubmit the request, but maybe there's something better out there to indicate "This method is generally allowed by you, but the resource is currently in a state that prevents it from completing as expected."

Answer 1

Seems like that is the Internet's consensus, and I see nothing better here . See here for another similar question

409

This code is used in situations where the user might be able to resolve the conflict and resubmit the request. Source

This is then followed up

Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation being PUT included changes to a resource that conflict with those made by an earlier (third-party) request

That seems more like the entity shifted underneath the client while the client constructed a call, perhaps the assumption is the client asks for the allowed actions, before making the call(s). If you implemented that, I would say 409 is perfectly valid for your API since you provide the ability for clients to make only valid requests, unless someone else changes the entity.

Clearly you should be consistent, and document the response codes and their usage.

Answer 2

According to RFC 4918 ( https://tools.ietf.org/html/rfc4918#section-11.2 ), you could use code 422 (Unprocessable Entity) to handle situations like it.

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 (ie, syntactically correct), but
semantically erroneous, XML instructions.

Answer 3

The 409 seems the best fit, this is what http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html says:

This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.