To me it’s like you’re arguing that the only methods anyone ever needs on a class are gettr and settr methods.

It is mostly true that the prettiness of the URLs is only germane to human memory, but sometimes that is quite relevant to your application.

Hmm. Maybe that’s another example of the type of stuff that is a little too trollish. If we can piss each other off with that stuff, imagine how a C# developer who worked hard some SOAP thing must feel reading this site.

I guess it depends on whether we want people to adopt REST. If we want to reserve a space to feel smug and superior, it seems like we’re doing a great job.

I also didn’t appreciate the characteriziation of my work as the “result of people who just can’t help but make architecture”, which motivated the terse (and, admittedly, unhelpful) response.

I’ve seen the same kinds of discussions (focusing on aesthetics more than function), and have similar concerns; it’s a very easy trap to fall into. Howeer, I draw a different conclusion. As I said, some of the benefits of focusing on these apparently non-productive parts of REST is that they make it more likely that you’ll trip over the productive parts (e.g., caching).

PUT and DELETE, for example, give you a cleaner design if you need those semantics. While you could stuff them inside POST, you’d need to then find a way to dispatch and differentiate them; probably in the URI. And then, you wouldn’t get the benefits of invalidation in caches.

Part of what I’m doing at Yahoo is documenting best practices for REST. Engineers there are smart, and will immediately ask what the benefit of a particular recommendation is, calling BS if there isn’t one. So, I have to justify every recommendation with tangible benefits. I’m still in-progress, but I hope to report some of the results when they’re more baked.

Ryan,

I agree with much of what you say, but how does Squid take advantage of PUT and DELETE today? I don’t think it retries them (taking advantage of idempotence). Also, there’s some debate of the idempotence of PUT, because WebDAV allows it to have side effects (creating a new revision). I believe DELETE can have side effects as well.

GET actually means something to intermediaries. POST, PUT, and DELETE only really mean something to humans.

That’s not really true. Squid, and I believe most other caching proxies have an explicit understanding of each of these verbs. The semantics for each are rigidly defined and are all very different. PUT is not POST and POST is not DELETE. The descriptions of each verb in RFC 2616 are fairly short and straight-forward for the most part.

PUT and DELETE are idempotent and POST isn’t. PUT and DELETE each say something specific about the resource they modify and clients and intermediaries can make assumptions about the resource they PUT/DELETE to once the response is complete. When an APP client PUTs an entry it can then make assumptions (more specific assumptions than POST) about that resource’s state after the request. For a client that stores 1,000 blog entries, that can be important. Sure, you could implement the same exact semantics at the application layer using POST, special parameters, maybe a custom XML response body to indicate success or failure. It would be simple, right? (cue explosion of XML-RPC based blog-publish interfaces) But now we all have to agree on these other ways of accomplishing the same exact thing as PUT, which has already been figured out. If we all agree that a PUT is a PUT is a PUT is a PUT and that you express it as such and such then we can start building things around that understanding. Just like we did with GET and POST.

The trick is in knowing when not to use PUT or DELETE (if you aren’t sure, the rules in rfc2616 are pretty clear and they make good sense too). There are a number of cases that are better suited to POST, even though it may seem like you’re putting or deleting something. I’ve spent quite a bit of time trying to shoe-horn certain types of operations into a PUT or DELETE in an attempt to be “RESTful” only to learn that I was trying too hard and that POST was really the right verb for the situation. It’s sort of like how everyone stopped using <table>’s for tabular data when CSS came around.

Anyway, the point I’m trying to come around to and probably should have come right out with, is just that I think we should be trying to use the verb that’s most appropriate for the situation. The problem is that it’s not easy to do so. From the perspective of the lazy hacker, the simplest and best choice, given the current set of popular web frameworks and libraries (on both the client and server) is to re-implement PUT and DELETE on top of POST at the application layer every single time. And the lazy hacker is always right. But I think that one day in the maybe not-too-distant future the lazy hacker will change her mind because the tooling around building and interacting with resources using PUT/DELETE will save her time and energy and bring extra advantages instead of being a big nuisance.

No one is going to do this stuff because it’s compelling from a philosophical standpoint. It will take new tools and efficiencies, browsers and client-side libraries, web frameworks that make it easier to do cooler stuff with better clients, etc. The web’s common vernacular will extend into the less explored aspects of HTTP when the practical advantages of doing so present themselves. But that’s what’s so friggin cool and weird about it: HTTP has been around forever and might be only 10% into it’s implementation phase and it’s hard to tell exactly what we should implement next to get the most bang for our buck.