[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: Mark Baker <distobj@a...>
• Date: Thu, 31 Mar 2005 10:34:18 -0500
• In-reply-to: <e3a5cb2c0503301900428ee68d@m...>
• References: <15725CF6AFE2F34DB8A5B4770B7334EE07206D57@h...> <20050330230147.GB9251@m...> <e3a5cb2c0503301900428ee68d@m...>
• User-agent: Mutt/1.5.6+20040907i

On Wed, Mar 30, 2005 at 10:00:10PM -0500, Michael Champion wrote:
> The "identical data" is an order document, "order" as in a document
> describing a set of goods or services to be purchased.  The various
> services might be to submit an order, verify that an order was
> submitted, check the status of an order, determine when an order can
> be fufilled,  process the order to cause it to be fufilled, cancel and
> order, and so on.  So, somehow or other these different operations
> need to be part of the interface.

Ok, though I would have personally avoided the term "operation" since
that might be interpreted to be suggestive of a (form of) solution.
I'll use "action", as in "something that happens" (implementation),
distinct from "something that is requested to happen" (interface).

>  If I understand REST theory, one
> would have different URIs for these different services/operations and
> would GET/PUT/POST/DELETE order documents to the appropriate URI.

Right.

>  In
> a SOAP interface, one could have different endpoints for each, I
> suppose, but most people would probably have a single endpoint and
> have each request specify some sort of an operation code to determine
> which service to request.   How is this more complex than having
> distinct URIs to determine which service to request?   You can pay the
> complexity tax with nouns (URIs) or you can pay it with verbs
> (operations/service identifiers), but you have to pay it.

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.

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.

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

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

• Follow-Ups:
  • Re: What Does SOAP/WS Do that A REST System Can't?
    • From: Michael Champion <michaelc.champion@g...>

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

• Prev by Date: Re: all group composition
• 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