[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: REST has too many verbs

verbs that start with t
Leigh, I think you are on to it.

Leigh Dodds wrote:
> So to couch this in OO/Refactoring terms REST says that you should do
> this kind of refactoring [*]:
> Start:
> class X
> {
>   String getFile();
> }
> class Y
> {
>   String getName();
> }
> End:
> interface Gettable
> {
>   String get();
> }
> class X implements Gettable {...}
> class Y implements Gettable {...}

Yes. But every resource in the universe implements class Gettable,
Settable etc., so it becomes a little redundant to keep specifying it.
;) Of course sometimes you cannot get or set a resource for access
control reasons but that doesn't mean that the resource logically
doesn't support it...even if set support hasn't been implemented yet!

> IOW, RESTful-ness is about relying on a standard interface
> to resources, which contains only four methods. The URI
> determines resource identity, i.e. the object to which the method
> is sent. The resources are polymorphic, in that the same operations may
> involve different processing once invoked.


> Does the analogy hold? Where does it break down? 

It's a good analogy. It breaks down at the edges, of course. For
instance you would have to allow content negotation into your API. Plus
HTTP headers. But here's part of the revelatory part of the analogy.
Consider how easy it would be to combine these things into new patterns
by pointing one get at the output of another get, or a set at the output
of a get etc. Not unlike stacking SAX filters. Because you know
*exactly* the set of methods available, and their semantics, you can
define reasonable combinations.

> >Now if you were taught to program in this style, you might think it odd
> >when someone told you that there was really no need to dispatch on a
> >name passed as data. In fact you could move that out to the method name
> >(or in the case of the Web, to the URI/method combination).
> Actually I doubt whether any OO programmer would think it odd.
> It's simply ReplaceConditionalWithPolymorphism [2].

My point was just that changing paradigms is hard. Obviously the code I
showed wasn't OO and I was showing how a person might have a mental
block trying to migrate from condition-based programming to OO

> I'm probably stretching the analogy way to far, but is it a case
> of applying the same pattern but in a different context?

Right. In the ReplaceConditionalWithPolymorphism you move the "action"
from the data to the method. In REST you go one step further and model
your application so that the action is implicit in the combination of
the URI and the HTTP method. In terms of your Java classes, you move
data around so that all of your objects can have those four methods so
that every object is a pluggable component, like an AV component. Just
like an AV component you sometimes use converters/translators as glue.
For XML people that will most often be XSLT (or in a funny way, RDF).

 Paul Prescod


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.