REST, HTTP DELETE and parameters

tags:

http
rest

views:

691

answers:

+13 Q:

REST, HTTP DELETE and parameters

+3 A:

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?

Alex Rockwell 2010-03-29 19:47:09

The first paragraph of your response is your opinion and I respect that but you haven't pointed to something in the literature that forbids the use of the URI like this - it still identifies the resource and the most appropriate HTTP verb is being used.In answer to your questions; yes it would still make sense (in my opinion). I would expect a script (perhaps based on CURL) to respect the 409 response and suggest to the user how the request could be resent - all based on my response body

Chris McCauley 2010-03-30 08:26:13

+5 A:

MicE 2010-03-29 20:59:05

Could you explain which REST constraint is being violated? Considering that URIs should be opaque to the client, why do you believe that the client's expectations are not being met with the usage of an HTTP DELETE that deletes one resource but fails to delete another. I'm not sure 409 is the best status code to return but besides being a bit of a strange implementation, I cannot find any REST constraints that are being broken.

Darrel Miller 2010-03-30 00:30:45

+1 for the well-argued opinion. I think you are arguing that in the absence of PUT/DELETE one should use POST to change the state of the resource but DELETE is available. I agree with that however DELETE is available and I haven'ts seen anything to suggest that using the URI like this is actually wrong - it still identifies the underlying resource.

Chris McCauley 2010-03-30 08:22:54

There is a conflict in my scenario - the resource state suggests that it is in use and should not be deleted.

Chris McCauley 2010-03-30 08:35:30

@Darrel: (imho) it violates the uniform interface by the DELETE method not performing as as per HTTP standards. Consider a REST client which assumes a standard REST service - how will the service let the client know that it needs to add `force_delete=true`? As per HTTP RFC, the DELETE method may be overriden on the origin server (client), implying that this is not done on the target server (service). So my understanding is that the once the service receives a DELETE request, it should process it without needing any confirmation (regardless if the service actually performs the operation).

MicE 2010-03-30 21:32:53

@Chris, to your second point: yes, that is my understanding as well, i.e. that the state suggests a real conflict and not a need for confirmation. I just noticed the update which you did in your question, and I agree - while I was looking into it myself, I came to the same conclusion (that this violates the uniform interface, and that the confirmation should be done on the client/UI side). I also ran across a very interesting thread here, it might help: http://www.mail-archive.com/[email protected]/msg13578.html

MicE 2010-03-30 21:45:27

@MicE To a large extent I agree with you that it is not the ideal way to handle this scenario. I'm just being a bit picky about the "it's not RESTful" label. For a while here that phrase was thrown at everything. However, it would be possible to define rules for a media type that say if you attempt to DELETE a resource and you get an error (I would say 403 forbidden would be better than 409), then the client should attempt DELETE on a related resource by tacking on a "force_delete=true". In a way it is a bit like authorization. Do GET, get 401, add auth header and GET again.

Darrel Miller 2010-03-30 23:31:33

@MicE - if you update your answer then perhaps I can mark as the accepted one?

Chris McCauley 2010-03-31 09:54:33

@Darrel - I agree with the 'thrown at everything' that's why I was looking for pointers to the literature rather than opinions (however well argued). I think I've now convinced myself that it isn't RESTful because it violates at least one of Roy's constraints.

Chris McCauley 2010-03-31 09:57:51

@Darrel: that is a very good point, thank you. And I have seen people throw the *not RESTful* label myself. It might be the case that nowadays the barrier between services and web applications is becoming very foggy, so one set of people can see this from a pure-service point of view, while others see it from a mixed application/service point of view. That is I believe where the real question about how to do the confirmation comes into play.@Chris: updated - thank you sir for a very interesting topic and discussion!

MicE 2010-03-31 18:51:03

+1 A:

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/.

Jan

Jan Algermissen 2010-03-29 21:02:58

I disagree, I'm free to provide multiple URIs to identify the same resource.

Chris McCauley 2010-03-30 08:27:42

Yep - everyone is free to make a mess :-)

Jan Algermissen 2010-03-30 11:35:14

Indication of canonical URIs could help with this: http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html

MicE 2010-03-30 20:45:10

@Chris There should only be one URI that returns a representation of a resource. Other URI's can refer to the same concept but doing a GET should return a 303 See Other. And just to counter the obvious objection to this, /foo.xml and /foo.json are two different resources.

Darrel Miller 2010-03-30 23:41:44

@Darrell - agree but the format isn't an issue here. Also the .format is a convention in Rails and other frameworks not a part of REST - you should be using the content negotiation in HTTP with MIME or microformats to fully implement this.

Chris McCauley 2010-03-31 08:39:51

ansaurus

tags:

views:

answers:

REST, HTTP DELETE and parameters

related questions