[
Lists Home |
Date Index |
Thread Index
]
Michael Champion wrote:
> In a resource-oriented architecture, new features are handled by
> defining new URIs to manipulate,, new interpretations of HTTP return
> codes, new synatax or semantics of the documents transferred,
> whatever. How can clients nott need to understand those details in
> order to use the features? Or better yet, point me to a concrete
> example on the Web.
>
> Dare mentions than in a service-oriented aggregator, " If later on a a
> new service shows up (e.g. getRecentBookmarks() to get RSS feeds from
> del.icio.us) then the client has to be upgraded." Sure, but
> SOMETHING on the client has to change in a RESTful version as well ...
> not the method for retrieving data, which can be GET, but the logic
> for doing anything that understands the distinction between a news
> story and a bookmark has to come from somewhere.
That's the point. You get more flexibility as to where and how you apply
processing logic. That's a huge software win that one might not
appreciate from a the vantage of a whiteboard. In a getThis, getThat
protocol framework, you seem to end up playing infrastructure catchup
and trying to keep clients and servers in sync. Basically by hardcoding
This and That into the method names you're making questionable
assumptions about the range of operations you will need to support.
Abstractly speaking it's all processing, concretely speaking having
control of how processing occurs and how code is dispatched is critical.
Systems with flexible and deferred dispatching modes are almost always
cheaper and easier to maintain.
For a not completely dissonant comparison, in OO systems where not all
possible types can be ranged over at design time (because no-one knows
how many more types there will be alter on), plugin and delegation absed
architectures are almost always preferrable way to deal with that
problem.
cheers
Bill
|
