Comments on: REST myths http://lesscode.org/2006/03/21/rest-myths/ AAaaaaahhhhrrrrrrr! Mon, 17 Sep 2007 09:11:03 +0000 http://wordpress.org/?v=2.0.1 by: Robert Sayre http://lesscode.org/2006/03/21/rest-myths/#comment-1340 Wed, 22 Mar 2006 03:21:43 +0000 http://lesscode.org/2006/03/21/rest-myths/#comment-1340 <p>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 <a href="http://lists.w3.org/Archives/Public/www-tag/2005Mar/0075.html" rel="nofollow">asked</a> the answer to this question, and the people who should know <a href="http://www.w3.org/2005/03/22-tagmem-minutes.html#item08" rel="nofollow">refused to answer</a>!</p> 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!

]]> by: Laurent Szyster http://lesscode.org/2006/03/21/rest-myths/#comment-1339 Wed, 22 Mar 2006 03:19:29 +0000 http://lesscode.org/2006/03/21/rest-myths/#comment-1339 <p>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.</p> <p>The other popular applications of POST are XML/RPC, REST and now JSON.</p> <p>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:</p> <ol> <li><p>ask for the MIME resource located by an URL and described by request's MIME headers</p></li> <li><p>send a MIME resource to a URL and get the response in a MIME envelope</p></li> </ol> <p>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. </p> <p>Wikis <em>backed</em> 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.</p> <p>With just GET and POST.</p> <p>Like this very blog.</p> <p>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.</p> <p>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.</p> <p>Not that Web 2.0 fad.</p> <p>That's just the return of a Fat Client/Server Zombie ;-)</p> <p>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 <em>peers</em>. HTTP was not a protocol for client and servers, but for peers.</p> <p>This very blogosphere you and me are writing is the next-best read/write web. It is not new and past this POST <em>all</em> content is distributed via RSS feeds that user agents ... </p> <p>GET /rss2 HTTP/1.1 Host: lesscode.org</p> <p><!-- generator="wordpress/2.0.1" --> ...</p> <p>just GET.</p> 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:

  1. ask for the MIME resource located by an URL and described by request’s MIME headers

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

]]> by: Ryan Tomayko http://lesscode.org/2006/03/21/rest-myths/#comment-1338 Wed, 22 Mar 2006 02:53:15 +0000 http://lesscode.org/2006/03/21/rest-myths/#comment-1338 <p>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 <code>&#60;strike&#62;</code> comments is annoying, having to <code>&#60;strike&#62;</code> posts is insulting. </p> <p>Dammit if we can't just have a nice little place where people try to do something other than constantly piss each other off.</p> 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.

]]> by: Robert Sayre http://lesscode.org/2006/03/21/rest-myths/#comment-1335 Wed, 22 Mar 2006 00:28:10 +0000 http://lesscode.org/2006/03/21/rest-myths/#comment-1335 <p>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.</p> 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.

]]> by: Patrick Logan http://lesscode.org/2006/03/21/rest-myths/#comment-1334 Wed, 22 Mar 2006 00:18:49 +0000 http://lesscode.org/2006/03/21/rest-myths/#comment-1334 <p>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? <p> If we need a CalDAV then do we need a ProjectPlanDAV and a SchematicDiagramDAV, and a ShinyObjectDAV, and a... <p> If people believe that CalDAV is more pro than con, what are the general lessons to be learned from that reasoning?</p> 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?

]]>