REST, RPC, mountains, molehills, and a retraction (sort of)

[Mark Baker]

8/8/2001 2:11:05 PM, Jeff Bone <jbone@jump.net> wrote:

>
>So...
>
>Over the course of the FoRKBreak, I've had several good discussions
>with various folks about this whole REST vs. RPC thing, in particular
>a great and detailed exchange with Mark Baker.  (Thanks Mark!)

My pleasure Jeff.  Thanks for being open minded enough to let this sink in.

>   GET  http://localhost/StockTicker/getStockPrice?strSymbol=MSFT
>
>The REST position is, essentially, that this an RPC, breaks the Web
>and causes all sorts of nastiness, and is very RESTless.  The basic
>problem is that the method --- getStockPrice --- doesn't represent a
>resource;  it's not clear what what it means to GET, PUT, and POST to
>something called "getStockPrice".  However, a simple change of
>nomenclature from "getStockPrice" to "CurrentStockPrice" suffices!
>I.e., the first example below is entirely valid from a REST design
>perspective, and the second even better:
>
>   GET  http://localhost/StockTicker/CurrentStockPrice?strSymbol=MSFT
>   GET  http://localhost/StockTicker/MSFT/CurrentStockPrice
>
>Obviously, the differences between "good REST design" and "bad RPC
>design" can be quite subtle. 

I dunno, I don't think that's too subtle.  It may not be in-your-face obvious, granted, but most people know the 
difference between a noun and a verb. 8-) 

Not that I'm suggesting resources can't be verbs, since processes can have state too.  But a process identified by a 
URI would return the state of the process, not the result of the process.  e.g. GET on /GetStockQuote could return a 
representation saying "awaiting approval from manager of information services at AMEX to release information".

> Furthermore, as a design style, it's one that
>when pushed to its extreme *can* have significant costs for
>developers;  rather than developing object models using traditional
>OOP design techniques and then automagically exporting them to the
>Web, developers must decompose their objects in a different fashion
>and, perhaps, even go to a phenomenal amount of trouble to explicitly
>provide the marshalling / unmarshalling / parsing of things to and
>from the request and response streams.  StockTicker is much more work
>to build as a servlet, say, than as a Web-naive class that is
>automagically published to the Web via some RPC framework...

I agree that REST-friendly modelling tools would be very handy, but I'm not sure I buy the argument that implementation 
is much more complex.

>WHAT'S GREAT ABOUT REST?!
>-------------------------------------
>
>It turns out that the best argument for REST is this:  *there are no
>applications you can think of which cannot be made to fit into the GET
>/ PUT / POST / resources / representations model of the world!* 

Well, hold on there.  Didn't you get my last email?  This isn't really my position, though I've used it at times to make a 
point.  It's true that GET/PUT/POST/DELETE are extremely powerful and suitable for what most people need.  But I'm 
not saying new things won't be required later.  TAKE is a good example that you and I discussed; atomic 
GET+DELETE.

Also,  if there's a good reason to extend HTTP's method semantics that is not backwards-compatible with existing 
methods, a new method may be required, ala M-* and PEP-*.

BTW, you may want to talk about security in this section (assuming you're going to be maintaining this note in some 
permanent form).

>Coordination languages are elegant, simple, and powerful.  Viewing
>HTTP as such a coordination language --- reconsidering your app in
>terms of the provided interfaces and semantics rather than trying to
>figure out how to subvert or extend HTTP to encompass what you think
>your application semantics are --- is a useful and powerful
>perspective.

Amen.

>Furthermore, there's a real impedance mis-match between the design
>perspectives of the OOP /  IT developer communities and REST;
>RPC-over-HTTP does not have this problem.  It's a *really attractive*
>proposition to the OOP / IT guys to think of taking an existing object
>model and, with no or minimal Web-specific "glue", simply exporting
>those interfaces to the Web.  (The problems creep in down the road;
>Adam Bosworth's frequent comments on the implicit state transitions in
>using APIs are particularly pertinent.  His solution appears to be,
>rather than use generic interfaces, extend interface descriptions to
>encompass the state transition model of the API.  Ick.)

HTTP can do state transitions as a special case.

GET - find out what state I'm in
PUT - go to this state absolutely
POST - transition from current state to a subsequent state

This could be implemented as a generic container.  You could,say, specify the state model with an XML document with 
which the container would be instantiated.

> Now, doubtless, there's a lot of servlet and Web
>development knowledge out there;  but most enterprise developers, data
>modellers, etc. I know still live in UML- and OOP-land, and this is as
>significant a change as the procedural->object transition of a decade
>or so ago.

Agreed.

>*is*, how to design to it, and why it's a good thing.  On the other
>hand, the REST community should work with the Web Services community
>to ensure that things like WSDL, UDDI, etc. are sufficiently rich to
>be useful in the REST model of the world...  these are two different
>design styles, informed by different needs and values, but they should
>share a technology base to the largest extent possible.

I'm doing my part to make sure in all this RPC noise, that something REST-friendly emerges, viz a vis my bitching about 
the SOAP 1.2 HTTP binding.

>I'm sold;  I just wish there was a larger body of literature about
>REST out there already.

You and me both. 8-)

>  Would've saved some painful flaming with Roy
>and lots of interaction with Mark on my part...  ;-)  (Where's Dave in
>all this???)

Hopefully keeping an open mind.  He's done a great job so far, putting up with me.  You try him now. 8-)

MB