- From: Paul Prescod <paul@prescod.net>
- Date: Wed, 27 Mar 2002 15:47:03 -0800
- To: www-tag@w3.org
David Orchard wrote: > > I think I got it, or pretty close at any rate. But I beg to differ with > some of your assertions. > > IMO, the web worked with REST really well because we had these browsers that > understood GET and POST. While REST specified PUT, DELETE, and other > standard well-defined interfaces, most browers, servers and web sites worked > with GET and POST. Further, authors have blatantly mixed GET/POST semantics > throughout the web. Most web authors use GET/POST depending upon what their > companies "best practices" say, and it might say something like "use GET > when you want to bookmark something" or "use GET if you don't have too much > data" or "use POST for security reasons" or some other rules. Someone who uses GET because they want to bookmark something is not missing the point. Hyperlinking (of which bookmarking is a particular form), *is exactly the point*. Therefore people tend to do it right because they want the benefits of hyperlinking which only accrue with GET. What's amazing as that these web masters pick this up intuitively but "we" web services people tend to miss the point. Without hyperlinking you don't have the Web. Without GET you don't have hyperlinking. Hyperlinking is a critical piece of any non-trivial web service because it is the Web's way of managing state. COM has Monikers. CORBA has IORs. The Web has URIs. SOAP does not have GET and it is not possible to address SOAP-fetchable information. Therefore SOAP is something other than the Web and actually quite a bit less powerful than the technologies it is supposed to replace. SOAP actually works against the Web by discouraging people from making data GET-able based on their intuitions. I've had customers say: "Oh yeah, we provide that data feed in XML. Sorry it isn't SOAP but we aren't that sophisticated yet." They don't know why they want to use SOAP and they don't understand what they are giving up. When people move information into a SOAP interface they generally move it *off of the Web*. > ... I did a quick > few searches and found some interesting best practices [1]...[5]. But I > couldn't find any messages that distinguished between the GET/POST from a > REST perspective, outside of the W3C style page and mailing lists with the > expected suspects. Every discussion of GET/POST usage was around authoring > of FORMS. That's the only place you would actually expect it to arise. FORMs are the interface you expose to the world in the HTML web. > ... I couldn't find a single reference that talked about > implementation on the server that discussed when servlets/jsps/asp/php/perl > should use GET versus POST, just the client interaction issues. You're talking about fundamentally a protocol issue. "Client interaction" is exactly what needs to be considered. the implementation will fall out fairly naturally from that. > To a certain extent, the web "got away with" having a weakly typed > interface, because it embedded the names and values in either GET parameters > or POST parameters. Very conveniently, if the form that needed the > parameters ever changed, well the user just got a new form. So the client > generally always had a way of refetching the interface. But that doesn't > work for machine to machine communication. Machines don't adjust very well > to changes in the interface, so we at least want our software to be able to > make it easier for humans to recover. I don't follow how this issue is at all related to generic interfaces (REST) versus specific interfaces (SOAP). > Further, the types of documents retrieved on the web were generally not > extensible, typically well defined document types such as HTML, GIF, JPEG. > XML changes the playing field. An HTML form is actually a VERY extensible data type. > ... I argue that the ability for clients and > servers to have arbitrary documents flow between them means that they will > rightfully want to embed more complex control. Maybe. But what does that have to do with specific interfaces versus generic ones. > I'm not sure the REST approach with clean separation of GET/POST/PUT/DELETE > was really THE deciding factor in the success of the web. Seems to me that > people mix and match GET/POST based upon various requirements that have > little to do with idempotency versus updates or REST ideals. REST ideals, no. What works, yes. REST works so people use it. Let me use the Expedia example again. I go to www.expedia.ca. Microsoft/Expedia knows to use GET for the home page because they want me to be able to reference this in emails to my friends and in search engines etc. Then I go through the process of buying a ticket. This is a sophisticated, complicated *transactional process* so Microsoft shifts to using POST. I lose bookmark-ability temporarily because the process is no longer idemponent. If I try to do a "refresh" on one of these pages my browser will warn me that I may be transacting twice. The Expedia guys know this but they may not depend on it so they make sure that they always have enough information to know where they are in the transaction. Then at the end they present me with a URI and say: "you can print or bookmark this." Obviously this URI is intended for GET. The genius of the whole system is that they *didn't have to know REST*. The Web was just set up so that this stuff works and so that doing things in a natural way leads to the right results. It's only in the Web Services rush that we've forgotten how much of this stuff is already worked out. If I go through the other parts of REST, you'll see them similarly sprinkled through the Web standards. People use the Web infrastructure as fish breath water. They just plug into it and they don't understand the principles that they building upon (or not). > ... And the choice > is derived from the way a human would interact based upon the browser/server > interaction characteristics. The human is just a piece of client software (wetware). When the web service wants to allow the "client" to keep a persistent reference it generates a GET-able URI. When the service wants to do a transaction and thus prevent persistent references it uses POST. Web designers understand this, just not in those terms. > ... The uniformity of the interface was HTTP > GET/POST with HTML and URIs. Intermediaries could deal with the information > streams precisely because they were information streams. Arguing that the > success of the web was due to REST, with GET/POST/DELETE/PUT interfaces, and > that violating these is in complete and shameless violation of the "web" is > stretching and revising history. It isn't stretching anything. It is *precisely* because every web resource (other than mailto: resources and XML namespaces) was GET-able that the Web *IS A WEB*. That's REST: its a consistent interface to every document on the Web. GET is the most fundamental part of that interface. POST is a little bit less and PUT/DELETE even less so. There is a reason that GET was invented first, POST second and the rest after (IIRC [1]). GET was defined explicitly to be idempotent as early as 1991. When SOAP and WSDL are fixed to properly deal with GET (or something like it), it is my assertion that everything else will fall into place as it did on the Original Web. Until they do, every web service will be an address space onto its own, just like hypertext systems before the Web. I am exercised about this issue because I see SOAP dragging us back into the pre-Web chaos. The Web's inventors are smart guys but as far as I can tell the early Web had roughly two innovative concepts (that I can think of right now, anyway). The single namespace[2] and the constraint that basically everthing in the namespace would support GET so that you could reliably weave the single namespace into a hypertext tapestry. That's REST baby. ;) Paul Prescod [1] http://www.w3.org/Protocols/HTTP/AsImplemented.html [2] http://www.w3.org/Addressing/
Received on Wednesday, 27 March 2002 18:50:47 UTC