[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: xml-dev@l...
• Subject: Re: What Does SOAP/WS Do that A REST System Can't?
• From: Michael Champion <michaelc.champion@g...>
• Date: Thu, 31 Mar 2005 13:06:13 -0500
• Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=VWxN+ueWjyBXyqFuRlK0GzwNCnspF6E+eems7CU6L3LTyUp++Fj4d7u1goZ+OPUjphaa4wFs0aQLxzin1ZozCzzHAloDCblYuZHtLkXXhZaJXTeY8SZ55K7frBSRmeZyYGN5yelcJ4+bcjhnE605OIn8ZkY3nEf41ELINarzWZQ=
• In-reply-to: <20050331153418.GD9251@m...>
• References: <15725CF6AFE2F34DB8A5B4770B7334EE07206D57@h...> <20050330230147.GB9251@m...> <e3a5cb2c0503301900428ee68d@m...> <20050331153418.GD9251@m...>
• Reply-to: Michael Champion <michaelc.champion@g...>

On Thu, 31 Mar 2005 10:34:18 -0500, Mark Baker <distobj@a...> wrote:

> To keep it simple, I'll just focus on GET.  The "verify", "check", and
> "determine" actions you mention above all seem to map well to it.

I don't buy that.  GET has well defined semantics that don't map in
any obvious way to a conventional meaning of "verify".  Sure, you
could define an interface contract (or whatever the RESTifarian term
for that is) that says something like "GET the URI returned by the
POST of the order and find the VerifyOrder element and GET that URI,
if it returns a 200 your order was accepted" or whatever.  I don't
dispute that HTTP provides some very nice and universally deployed
tools for this that sensible people should use whenever practical.  I
dispute that there is a simple and direct mapping from  the actions /
services in a non-trivial distributed application to the HTTP verbs.  
It can be done, but you don't get it for free as a "uniform
interface."

> 
> Using SOA, with separate "verify", "check", and "determine" operations,
> in order to get the resulting data from those actions in the hands of a
> single client component, that component has to be developed with support
> for all three operations.  If a new "get me data"-like operation is
> added, which isn't "verify", "check", or "determine", then that
> client needs to be upgraded to support it too.

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.   Unless of course
your are just treating news items and bookmarks as text to be shown to
the user ... I completely agree that SOA is massive overkill if the
"service" being offered is getting arbitrary stuff from the web and
displaying it.

>
> Using the uniform interface, a client need only support the GET
> operation in order to retrieve data from all services, past, present,
> and future.

Retrieve data, sure.  Doing  anything useful with the data requires
the same old shared understanding about schemas and semantics that
everyone else struggles with.  Maybe the Semantic Web will make that
all work Real Soon Now.  Been hearing that for a Long Time Now. .Until
then you get no free lunch at the RESTaurant.

• Follow-Ups:
  • Re: What Does SOAP/WS Do that A REST System Can't?
    • From: Bill de hÓra <bill.dehora@p...>

• 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...>

• Prev by Date: Re: What Does SOAP/WS Do that A REST System Can't?
• Next by Date: Re: SOAP for non-RPC messaging application
• 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