REST HTTP DELETE and parameters

Question

Is there anything non-RESTful about providing parameters to a HTTP DELETE request     My scenario is that I m modelling the  Are you sure you want to delete that   scenario  In some cases  the state of the resource suggests that the requested delete may be invalid  You can probably imagine some scenarios yourself where confirmation of a delete is required  The solution we have adopted is to pass a parameter to the delete request to indicate that it s ok to proceed with the delete    force delete true    e g   DELETE http   server resource id force delete true   I believe that it s still restful since    a  The semantics of DELETE are not being changed - the user can still send a normal DELETE request but this may fail with 409 and the body of the response will explain why  I say may fail because  for reasons not worth explaining  on some occasions there is no reason to prompt the user    b  There s nothing in Roy s dissertation to suggest that it s against the spirit of REST - why would there be since HTTP is only one implementation of REST so why would passing HTTP parameters matter   Can someone point me at a definitive statement that nails the reason why this isn t RESTful   On a related question  if the user does not specify force delete then I m returning 409 Conflict - is that the most appropriate response code     Follow up  After some further research  I think that adding parameters to the DELETE may violate several principles   The first is that the implementation possibly violates the  Uniform Interface   see section 5 1 5 of Roy s dissertation  By adding  force delete  we re adding an additional constraint onto the already well defined DELETE method  This constraint is meaningful only to us    You could also argue that it violate the  5 1 2 Client-Server  since the confirmation dialogue is really a UI concern and again not all clients will want to confirm deletion   Suggestions anyone

User · Answer

In addition to Alex s answer  Note that http   server resource id force delete true identifies a different resource than http   server resource id  For example  it is a huge difference whether you delete  customers  status old or  customers

User · Answer

It s an old question  but here are some comments      In SQL  the DELETE command accepts a parameter  CASCADE   which allows you to specify that dependent objects should also be deleted  This is an example of a DELETE parameter that makes sense  but  man rm  could provide others  How would these cases possibly be implemented in REST HTTP without a parameter   Jan  it seems to be a well-established convention that the path part of the URL identifies a resource  whereas the querystring does not  at least not necessarily   Examples abound  getting the same resource but in a different format  getting specific fields of a resource  etc  If we consider the querystring as part of the resource identifier  it is impossible to have a concept of  different views of the same resource  without turning to non-RESTful mechanisms such as HTTP content negotiation  which can be undesirable for many reasons

User · Answer

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

User · Answer

I think this is non-restful  I do not think the restful service should handle the requirement of forcing the user to confirm a delete  I would handle this in the UI   Does specifying force delete true make sense if this were a program s API  If someone was writing a script to delete this resource  would you want to force them to specify force delete true to actually delete the resource

[http] REST, HTTP DELETE and parameters

Examples related to http

Examples related to rest