REST, RPC, mountains, molehills, and a retraction (sort of)
Wed, 08 Aug 2001 17:49:05 -0400
8/8/2001 2:11:05 PM, Jeff Bone <firstname.lastname@example.org> wrote:
>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
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
>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
>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.
>*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
Hopefully keeping an open mind. He's done a great job so far, putting up with me. You try him now. 8-)