REST, HTTP DELETE and parameters

by

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 (I don’t know who downvoted him, he is correct), 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).

More Related Contents:

  1. What is the difference between POST and PUT in HTTP?
  2. Is an entity body allowed for an HTTP DELETE request?
  3. REST HTTP status codes for failed validation or invalid duplicate
  4. URL matrix parameters vs. query parameters
  5. Which status code should I use for failed validations or invalid duplicates?
  6. Detecting the character encoding of an HTTP POST request
  7. Why does my web server software disallow PUT and DELETE requests?
  8. Proper REST response for empty table?
  9. Content-Length header with HEAD requests?
  10. Which HTTP methods match up to which CRUD methods?
  11. HTTP status code for a partial successful request
  12. What is the difference between HTTP and REST?
  13. Doing a HTTP PUT from a browser
  14. REST response code for invalid data
  15. Custom HTTP Authorization Header
  16. RESTful Alternatives to DELETE Request Body
  17. Payloads of HTTP Request Methods
  18. Can I stream a file upload to S3 without a content-length header?
  19. Should I use PATCH or PUT in my REST API?
  20. Is REST DELETE really idempotent?
  21. How can I deal with HTTP GET query string length limitations and still want to be RESTful?
  22. What is the proper HTTP response to send for requests that require SSL/TLS
  23. Correct way to pass multiple values for same parameter name in GET request
  24. HTTP 1.0 vs 1.1
  25. Angular2 http.get() ,map(), subscribe() and observable pattern – basic understanding
  26. What should a Multipart HTTP request with multiple files look like? [duplicate]
  27. Cookie handling in Google Apps Script – How to send cookies in header?
  28. Why is my Hello World go server getting crushed by ApacheBench?
  29. How do I create a persistent vs a non-persistent cookie?
  30. Multiple HTTP Authorization headers?

Leave a Comment