REST myths
By Robert Sayre under Talk on 21. March 2006Today’s myth: limiting the number of methods is a good idea.
From an old thread on WebDAV methods:
REST encourages the creation of new methods for obscure operations, specifically because we don’t want to burden common methods with all of the logic of trying to figure out whether or not a particular operation fits the 99.9% case or one of the others that make up 0.1%.
That doesn’t mean you want to make up a new method if you don’t have to, like getStockQuote. Use GET /stockQuote/43 for that. A small number of methods will get you pretty far, but perhaps not all the way. For authoring applications, you’re likely to hit some snags. You’re also likely to hit some religion.
Patrick Logan:
I’ll read through those earlier messages on WebDAV. What about CalDAV? Any references to good discussions on the pro/con of CalDAV or guidelines for drawing the line on new methods?
If we need a CalDAV then do we need a ProjectPlanDAV and a SchematicDiagramDAV, and a ShinyObjectDAV, and a…
If people believe that CalDAV is more pro than con, what are the general lessons to be learned from that reasoning?
comment at 21. March 2006
Robert Sayre:
My personal opinion is that MKCOL and, by extension, MKCALENDAR are overkill. Reasonable people have been known to disagree. ShinyObjectDAV can definitely be tempting, and may not be good design, but it’s definitely transparent and observable to HTTP intermediaries.
comment at 21. March 2006
Ryan Tomayko:
Your trolling, Robert. Next time, leave the last two sentences out or phrase them in a way that invites discussion instead of aggression. Having to
<strike>comments is annoying, having to<strike>posts is insulting.Dammit if we can’t just have a nice little place where people try to do something other than constantly piss each other off.
comment at 21. March 2006
Laurent Szyster:
HTTP has two methods in public use: GET and POST. Nescape implemented PUT, Microsoft developed WebDAV, but web application developers try to stick to GET and seldom handle other POSTs than URLencoded form data.
The other popular applications of POST are XML/RPC, REST and now JSON.
So, limiting the number of HTTP method is not a new myth. It’s an old truth. The good reasons why nobody needs more than GET and POST is that there is not much more to HTTP than that:
ask for the MIME resource located by an URL and described by request’s MIME headers
send a MIME resource to a URL and get the response in a MIME envelope
Save to the web is a great idea and Apache WebDAV support applied to SVN is amazing. But starting a complex dialog with the server about each URL methods makes sense only for a kind of “rich clients” that monopolies love to lock people in and which customers learned to hate.
Wikis backed by revision control tools proved good enough to author collectively and safely on the web, and large Content Management Systems are simply built that way. With or without WebDAV.
With just GET and POST.
Like this very blog.
For diverse reasons, PUT, DELETE and WebDAV have never spread out of their original applications as a public extension of HTTP, supported everywhere like GET. Possibly because WebDAV is too complex or too specialized.
But more fundamentaly because we still don’t have the basic service to apply what PUT and DELETE were designed for: a read/write web.
Not that Web 2.0 fad.
That’s just the return of a Fat Client/Server Zombie ;-)
A read/write web is a web of peers, the one originaly envisionned by Tim Berner Lee but never realized due to the absence of a public name resolution for peers. HTTP was not a protocol for client and servers, but for peers.
This very blogosphere you and me are writing is the next-best read/write web. It is not new and past this POST all content is distributed via RSS feeds that user agents …
GET /rss2 HTTP/1.1
Host: lesscode.org
…
just GET.
comment at 21. March 2006
Robert Sayre:
I agree, that was a little too hot and open-ended given the blogosphere we’ve had today, but I’ve actually seen it crop up in all sorts contexts, not just the stuff we’ve all worked on. I once asked the answer to this question, and the people who should know refused to answer!
comment at 21. March 2006