REST and the Web

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