[
Lists Home |
Date Index |
Thread Index
]
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.
Exactly!
> 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
programming.
> 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
|
