In this interview, Elliotte Rusty Harold discusses the true meaning of PUT and DELETE:

http://www.artima.com/lejava/articles/why_put_and_delete.html

What is your opinion? Is the idempotency justification for PUT and DELETE reasonable? Where have you found PUT and DELETE adds value over POST?

I'm a bit confused here, why would I not be able to POST to a non existing resource URL http://www.example.com/foo.html? Can't foo.html simply be the pathinfo of the URL with a service responding on / that processes the request?

Hi Geert,

> I'm a bit confused here, why would I not be able to POST
> to a non existing resource URL
> http://www.example.com/foo.html? Can't foo.html simply be
> the pathinfo of the URL with a service responding on /
> that processes the request?

Yes you can. I didn't point that out in the interview, but there's no reason you can't POST to a non-existing URL and have that mean PUT. A bit wierd, but POST is general enough to do that.

I'm still yet to be convinced that PUT and DELETE add much. The main justification Rusty gives is idempotency, and I don't see how in practice agents can retry PUTs and DELETEs if there is no built in locking/versioning mechanism. I do agree that with HTTP's stateless approach, a locking/versioning mechanism should NOT exist in the protocol for PUT and DELETE. I just think that since it doesn't, it is not practical for PUTs and DELETEs to be simply retried, and if that's true, what's the point of using PUT and DELETE other than syntactic sugar over POST?

All of your objections to PUT and DELETE can be said about either POST or GET. Why use different "verbs" at all?

Imagine if browsers only supported POST. Guess what, you could still do everything you can do now.... just have POST with an empty body act as a GET does now.

If you don't think that's a good idea, then you don't really have an objection to PUT and DELETE anymore.

IMVHO

Obviously you can do everything you need with POST, but if you're going to do it that way you will be required to add more code on the server to handle the operations yourself. The point is that if we could use PUT and DELETE, we could remove that code from your POST processing controller which leads to a simpler design which leads to more flexible and maintainable code which makes us all happy.

It reminds me of a sys admin I used to work with, he used to think it was cool to accomplish tasks with the most obscure and twisted applications of technology that he could imagine. I'm sure he thought he was demonstrating his admin prowess. I could never figure out why he didn't just use the right tool for the job and get it done.

> All of your objections to PUT and DELETE can be said about
> either POST or GET. Why use different "verbs" at all?
>
> Imagine if browsers only supported POST. Guess what, you
> could still do everything you can do now.... just have
> POST with an empty body act as a GET does now.
>
Actually, GET and POST are quite different in that GET operations should be "safe." Without GET, you couldn't safely and effectively pre-fetch, bookmark, cache, etc. Rusty talks about this in the interview, which I'd recommend as good reading material.

> If you don't think that's a good idea, then you don't
> really have an objection to PUT and DELETE anymore.
>
I don't have an objection to PUT and DELETE. I just don't see much added value. I interviewed Rusty Harold to see if I could glean some insights, and I'm still not very convinced. They exist, and aren't going away, but I don't see much need to use them in anything I'm designing.

> > If you don't think that's a good idea, then you don't
> > really have an objection to PUT and DELETE anymore.
> >
> I don't have an objection to PUT and DELETE. I just don't
> see much added value. I interviewed Rusty Harold to see if
> I could glean some insights, and I'm still not very
> convinced. They exist, and aren't going away, but I don't
> see much need to use them in anything I'm designing.

I beg to differ, it's rather that they don't exist anymore because they have already gone away -- or can you tell a HTML form to PUT something? Can you mark a link such that it does a DELETE?

ERH merely tries to resurrect some of the HTTP protocol which is out there as a spec, somewhat dominated by WWW use and browser implementors.

Of course, one can provide a service interface that "puts" and "deletes" without using anything from the protocol level -- but there is a fair share of people that simply don't know that they have the option of using the protocol. If you have something REST style that really ties resources to URIs, why not use PUT and DELETE (other than the fact that you have to roll your own JavaScript networking code?)

> > > If you don't think that's a good idea, then you don't
> > > really have an objection to PUT and DELETE anymore.
> > >
> > I don't have an objection to PUT and DELETE. I just
> don't
> > see much added value. I interviewed Rusty Harold to see
> if
> > I could glean some insights, and I'm still not very
> > convinced. They exist, and aren't going away, but I
> don't
> > see much need to use them in anything I'm designing.
>
> I beg to differ, it's rather that they don't exist anymore
> because they have already gone away -- or can you tell a
> HTML form to PUT something? Can you mark a link such that
> it does a DELETE?
>
They were not included in browsers, and I think support was poor at times in some web servers too. But my impression is that in practice I could use PUT and DELETE by merely handling them in my servlet. HttpServlet has doPut and doDelete methods, and I imagine Tomcat and Jetty and such will call them.

> ERH merely tries to resurrect some of the HTTP protocol
> which is out there as a spec, somewhat dominated by WWW
> use and browser implementors.
>
Well it is a common complaint among REST-enthusiasts, that browsers should support PUT and DELETE, that this would make the world a better place, but I still can't figure out how I'd use them if they did. I just updated the article based on some edit suggestions from Rusty, and one of the sentences I updated was:


The key difference between PUT and POST for update is that POST merely adds to an existing resource while PUT replaces it entirely.


Well, I'd never have a client completely replace a web page of Artima. Because then you'd rely on them decorating it with site wide look and feel, headers, footers, ads, etc. I'm using a form right now that will POST to this forum, and that updates a part of the page. So in a CMS kind of system like Artima, you'd never submit pages whole cloth, just content that gets wrapped and presented as web page resources. One thing Rusty told me to check out was Atom, and I haven't yet had time to understand how Atom would use PUT and DELETE. Pointers would be welcome. But even in the case of RSS or Atom feeds that we provide to the world, they would basically be made up of content that was POSTed to Artima, and later wrapped and presented in XML.

> Of course, one can provide a service interface that "puts"
> and "deletes" without using anything from the protocol
> level -- but there is a fair share of people that simply
> don't know that they have the option of using the
> protocol. If you have something REST style that really
> ties resources to URIs, why not use PUT and DELETE (other
> than the fact that you have to roll your own JavaScript
> networking code?)
>
That's actually kind of what my point is. I can see I may come up with a use for PUT and DELETE if I design a web service, i.e., if the client is autonomous software (as opposed to user-facing browser software). But I still don't see how adding PUT and DELETE support to browsers would buy us much for the human-facing web. In the case of a non-browser software client, I think GET, PUT, DELETE kind of makes a web server act like a file system. When you write a file to a file system, you (the client or writer) pick the file name. The files have permissions associated with them. File systems are certainly useful. But even then, I could also design a web-based file system service that just operates using GET and POST.

> I'm still yet to be convinced that PUT and DELETE add
> much. The main justification Rusty gives is idempotency,
> and I don't see how in practice agents can retry PUTs and
> DELETEs if there is no built in locking/versioning
> mechanism. I do agree that with HTTP's stateless approach,
> a locking/versioning mechanism should NOT exist in the
> protocol for PUT and DELETE. I just think that since it
> doesn't, it is not practical for PUTs and DELETEs to be
> simply retried, and if that's true, what's the point of
> using PUT and DELETE other than syntactic sugar over POST?
>
Someone posted to the REST-discuss mailing list an answer to this question. They said you can simply include an If-Match header with the last ETag you received for the resource when you send (or resend) the PUT or DELETE.

http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.24

The spec says that if the current version doesn't have the same ETag, the server should reject the request. That's an optimistic locking approach that I think solves the problem, which means idempotency is a difference between PUT/DELETE and POST.

> In this interview, Elliotte Rusty Harold discusses the
> true meaning of PUT and DELETE:
>
> http://www.artima.com/lejava/articles/why_put_and_delete.ht
> ml
>
> What is your opinion? Is the idempotency justification for
> PUT and DELETE reasonable? Where have you found PUT and
> DELETE adds value over POST?

The whole logic behind GET/POST/PUT/DELETE is flawed. A protocol should not have semantics. An HTTP request should simply be an invocation of a remote function with some input data and some output data. The exact semantics of each function should be domain-specific.

> The whole logic behind GET/POST/PUT/DELETE is flawed. A
> protocol should not have semantics. An HTTP request should
> simply be an invocation of a remote function with some
> input data and some output data. The exact semantics of
> each function should be domain-specific.

How would you implement request caching at either the browser or proxy server level if HTTP had no semantics?

What does caching have to do with semantics?

The browser can simply ask for the data it wants along with a timestamp of the data it has and if there is an update, the server sends the new data and the browser gets a new timestamp, otherwise the server sends a reply that 'the data you have are valid' and the browser uses those data.

For static data, the server could reply with the same timestamp; for dynamic data, the server could update the timestamp for each request.