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

Re: What Does SOAP/WS Do that A REST System Can't?

• To: Michael Champion <michaelc.champion@g...>
• Subject: Re: What Does SOAP/WS Do that A REST System Can't?
• From: Bill de hÓra <bill.dehora@p...>
• Date: Thu, 31 Mar 2005 21:09:03 +0100
• Cc: xml-dev@l...
• In-reply-to: <e3a5cb2c050331100651a9b187@m...>
• References: <15725CF6AFE2F34DB8A5B4770B7334EE07206D57@h...> <20050330230147.GB9251@m...> <e3a5cb2c0503301900428ee68d@m...> <20050331153418.GD9251@m...> <e3a5cb2c050331100651a9b187@m...>
• User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

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

• References:
  • What Does SOAP/WS Do that A REST System Can't?
    • From: "Bullard, Claude L (Len)" <len.bullard@i...>
  • Re: What Does SOAP/WS Do that A REST System Can't?
    • From: Mark Baker <distobj@a...>
  • Re: What Does SOAP/WS Do that A REST System Can't?
    • From: Michael Champion <michaelc.champion@g...>
  • Re: What Does SOAP/WS Do that A REST System Can't?
    • From: Mark Baker <distobj@a...>
  • Re: What Does SOAP/WS Do that A REST System Can't?
    • From: Michael Champion <michaelc.champion@g...>

• Prev by Date: Re: SOAP for non-RPC messaging application
• Next by Date: Re: What Does SOAP/WS Do that A REST System Can't?
• Previous by thread: Re: What Does SOAP/WS Do that A REST System Can't?
• Next by thread: Re: What Does SOAP/WS Do that A REST System Can't?
• Index(es):
  • Date
  • Thread