Hide Forgot
403 forbidden is used today, but forbidden is very generic. WebDAV specified 507 as insufficient storage - that seems much closer to the intent of the call: 11.5. 507 Insufficient Storage The 507 (Insufficient Storage) status code means the method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request. This condition is considered to be temporary. If the request that received this status code was the result of a user action, the request MUST NOT be repeated until it is requested by a separate user action. http://tools.ietf.org/html/rfc4918#section-11
How about a 409 Conflict code instead. 507 seems to imply that there is not enough storage on the system to store the resource. Also 5xx series are generally reserved for server errors whereas 4xx series are for client/app errors.
I think we could do that, IF we can sufficiently distinguish between the various failure states for this vs other uses. The primary one I'm thinking of is optimistic locking via etag and If-Match or similar, for which 409 is explicitly called out in the spec. ------ The request could not be completed due to a conflict with the current state of the resource. 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. Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type. ^^^ last one I think I do prefer a 4xx over a 5xx. There are a few sites out there using one or the other - if you think 409 works better I'm on board.
We decided to return 422 in case of such failures.
Verified this on devenv_1827, it returns 422 if the user reaches gear limit #curl -i -k -H "Accept: application/xml" --user "xtian+t100:1" https://ec2-107-20-92-208.compute-1.amazonaws.com/broker/rest/domains/domaindev003/applications -d name=rubyapp1 -d cartridge=ruby-1.8 -d scale=true -X POST HTTP/1.1 422 Unprocessable Entity Date: Mon, 11 Jun 2012 06:07:29 GMT Server: Apache/2.2.15 (Red Hat) X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.4 X-UA-Compatible: IE=Edge X-Runtime: 15.998641 Cache-Control: no-cache Location: /broker/rest/api Status: 422 Content-Type: application/xml; charset=utf-8 Vary: Accept-Encoding,User-Agent Strict-Transport-Security: max-age=15768000, includeSubDomains ProxyTime: D=16003890 Transfer-Encoding: chunked <?xml version="1.0" encoding="UTF-8"?> <response> <type nil="true"></type> <messages> <message> <field nil="true"></field> <text>Failed to create application rubyapp1 due to:Failed: Either application limit has already reached or domain doesn't exist for 'xtian+t100'</text> <exit-code>104</exit-code> <severity>error</severity> </message> </messages> <version>1.0</version> <status>unprocessable_entity</status> <data> <datum nil="true"></datum> </data> <supported-api-versions> <supported-api-version>1.0</supported-api-version> </supported-api-versions> </response>