Menu
Assume that I have a resource (e.g: /api/shipments/100) which supports HTTP DELETE method. As you can understand from the URI itself, if a DELETE request is made against this URI, this resource will be removed.
In my current scenario, the DELETE request can only be performed successfully if a certain condition is met as below:
If there is a DELETE request against that URI and the above condition is not met, which HTTP status code would be more proper to return in that case? I have thought about the below ones but couldn't decide which one is more semantic:
383
A 204 ( No Content ) status code if the action has been enacted and no further information is to be supplied. A 200 ( OK ) status code if the action has been enacted and the response message includes a representation describing the status.
DELETE API Response Codes. A successful response of DELETE requests SHOULD be an HTTP response code 200 (OK) if the response includes an entity describing the status. The status should be 202 (Accepted) if the action has been queued.
Rationale: DELETE should be idempotent. If you return 404 on a second DELETE, your response is changing from a success code to an error code. The client program may take incorrect actions based on the assumption the DELETE failed.
The HTTP DELETE method is used to delete a resource from the server. Unlike GET and HEAD requests, the DELETE requests may change the server state. Sending a message body on a DELETE request might cause some servers to reject the request. But you still can send data to the server using URL parameters.
I would go with 409: Conflict, because what you have is a violation of resource state.
405: Method Not Allowed would also work. If you'd want to use a 405, you'd have to send an Allow header to indicate the supported methods, and the supported methods would vary depeding on the resource's state. In my opinion, this response code fits well for read-only resources, resources that can't be deleted etc. but Darrel's comments to this post are valid. The spec is ambiguous:
The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource.
In either case, you should provide information in the response body for the client to understand the source of the error.
Regarding the other two methods mentioned:
403: Forbidden should be used when you don't have the appropriate privileges to modify the resource, i.e. if you have to be an admin to delete that resource and you're not.
412: Precondition Failed is mostly used for conditional requests where the preconditions are specified explicitly in the request headers. For example, you can have conditional PUT requests that should be carried out only when the If-Match header is valid. If you don't specify anything in the request headers, I'd still choose 409 over 412. Here's the spec for 412:
The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This response code allows the client to place preconditions on the current resource metainformation (header field data) and thus prevent the requested method from being applied to a resource other than the one intended.
107
I would use 412: Precondition Failed.
Please see this for HTTP status codes
Web Status Codes
20
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
