I was looking at some presentation slides on REST vs SOAP and one of the major drawbacks listed for REST approach is — lack of ability to use a message body for DELETE operations. I was not sure when I read that, why that would be a drawback. (Discussion on the listed drawbacks will be a separate post by itself for another day).
A DELETE operation might look something like the following, where 123 is the ID of the customer:
DELETE /customers/123 Host: example.com
I was thinking about some use cases where a server might need more information for deletion. Thinking along the lines I tweeted this primarily to contest the presenter’s belief that it is such a huge drawback that you use that as a strike against REST-based approach.
Subbu Allamaraju responded. He says that the the question is a valid one. Subbu said that:
That is a good question. Think of any case where client has to explain why the resource needs to be DELETEd. This is not uncommon.
Assuming that’s a valid concern I was thinking of ways to do that in a RESTy manner. Only way that I could think of at that point was whether we could use POST and perform DELETE. That sounded to me like tunneling. Tunneling is hiding operations from HTTP. There is no way to know whether the operation is — safe, idempotent, both safe and idempotent, neither safe nor idempotent.
As we continue discussing this on Twitter I’ve asked how different this scenario would be from tunneling via GET, something like the following:
GET /customer?method=delete&id=123 Host: example.com
The above GET is a clear example of tunneling. Similarly, SOAP-way of POST is another good example of tunneling.
POST /CustomerService HTTP/1.1
Host: example.com
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://example.com/customer">
<m:deleteCustomer>
<m:id>123</m:id>
</m:deleteCustomer>
</soap:Body>
</soap:Envelope>
Approach
An approach that sounded reasonable: use POST with a distinct URI when in doubt. That way you would avoid tunneling by making it a distinct resource.
POST /customers/123/deleteme Host: example.com Content-type: xxx [send reasoning to the server why the resource is being deleted in the body]
This provides some visibility into the operation, via a URI that conveys the intention.
One downside of this approach is caches will not see the resource being deleted. In spite of that, this approach seems reasonable when you have a specific need to address the use case in question.
Thanks to Subbu for suggesting this approach. Provide your comments if you know of any other approaches.
P.S: Just one more reason why I like Twitter! Feel free to follow me there.
You may also like:
Follow on Twitter
#1 by Dhananjay Nene on October 22nd, 2009
Quote
For a moment think about implementing a soft-delete not a hard-delete. A soft-delete is a scenario where the resource exists but is in a state where the remainder of the system will no longer use it. Thus the resource doesn’t actually go away. A further GET (until a future purge operation) will even show the resource in a TO_BE_PURGED state. In such a situation a post seems like a completely logical way to do. By choosing to model soft deletion as a business operation which results in a modification of the underlying resource, there is no apparent inconsistency or work around ness to this solution (at least any more than for any other business operation). I am not so concerned about the cache updation since in most cases whenever one resource operation leads to another resource getting modified, caches will become stale – thats the nature of the tolerated inconsistencies and the delete use case is not making it any more acute than it already is.
Just being a little nit-picky – would explore a different URI which is noun driven rather than a verb eg. POST /customerdeletion/123
[Reply]
Pingback: Tweets that mention REST: DELETE operation and tunneling - Surya Suravarapu's Blog -- Topsy.com
#2 by Jerry Cooper on October 22nd, 2009
Quote
Would it be reasonable to approach this requirement with a two-phased approach?
A POST operation to something like customers/123/delete that accepts you reason information or other business requirements and generates a token resource(customers/123/delete-confirmed). The client could the issue the DELETE operation on this URI, given you a chance to back out, and something closer with regards to caching.
[Reply]