When issuing an HTTP DELETE request, the request URI should completely identify the resource to delete. However, is it allowable to add extra meta-data as part of the entity body of the request?
HTTP DELETE – Is an Entity Body Allowed for an HTTP DELETE Request?
httprest
Related Solutions
No, it is not RESTful. The only reason why you should be putting a verb (force_delete) into the URI is if you would need to overload GET/POST methods in an environment where PUT/DELETE methods are not available. Judging from your use of the DELETE method, this is not the case.
HTTP error code 409/Conflict should be used for situations where there is a conflict which prevents the RESTful service to perform the operation, but there is still a chance that the user might be able to resolve the conflict himself. A pre-deletion confirmation (where there are no real conflicts which would prevent deletion) is not a conflict per se, as nothing prevents the API from performing the requested operation.
As Alex said, this should be handled in the UI, because a RESTful service as such just processes requests and should be therefore stateless (i.e. it must not rely on confirmations by holding any server-side information about of a request).
Two examples how to do this in UI would be to:
- pre-HTML5:* show a JS confirmation dialog to the user, and send the request only if the user confirms it
- HTML5:* use a form with action DELETE where the form would contain only "Confirm" and "Cancel" buttons ("Confirm" would be the submit button)
(*) Please note that HTML versions prior to 5 do not support PUT and DELETE HTTP methods natively, however most modern browsers can do these two methods via AJAX calls. See this thread for details about cross-browser support.
Update (based on additional investigation and discussions):
The scenario where the service would require the force_delete=true flag to be present violates the uniform interface as defined in Roy Fielding's dissertation. Also, as per HTTP RFC, the DELETE method may be overridden on the origin server (client), implying that this is not done on the target server (service).
So once the service receives a DELETE request, it should process it without needing any additional confirmation (regardless if the service actually performs the operation).
It is explicitly mentioned here in the RFC
The short answer is:
You should include a response body with an entity describing the deleted item/resource if you return 200.
202 is something like an asynchronous request/response return status.
204 says explicitly that you do not include a response body
Best Answer
The spec does not explicitly forbid or discourage it, so I would tend to say it is allowed.
Microsoft sees it the same way (I can hear murmuring in the audience), they state in the MSDN article about the DELETE Method of ADO.NET Data Services Framework:
Additionally here is what RFC2616 (HTTP 1.1) has to say in regard to requests:
Content-LengthorTransfer-Encodingheader (section 4.3)For responses, this has been defined:
Update
And in RFC 9110 (June 2022), The fact that request bodies on GET, HEAD, and DELETE are not interoperable has been clarified.
section 9.3.5 Delete