Re: [xml-dev] What Does SOAP/WS Do that A REST System Can't?
by Michael Champion other posts by this author
Mar 30 2005 7:04PM messages near this date
Re: [xml-dev] What Does SOAP/WS Do that A REST System Can't?
|
Re: [xml-dev] What Does SOAP/WS Do that A REST System Can't?
& XSLT On Wed, 30 Mar 2005 18:01:47 -0500, Mark Baker <distobj@[...].org> wrote:
> assuming the data is identical in each case, what's
> easiest to integrate? Ten services with ten interfaces, or ten services
> with one interface?
>
> O(N) beats O(NlogN) every day of the week,
We've argued about this literallly for years now, and I just don't
accept the premise that those 10 RESTful services have a single
interface. The real complexity of one approach or the other depends on
all sorts of specific factors, not "O(N) beats O(NlogN) every day of
the week"
Let's consider a contrived example :
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. 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. 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.
I maintain that there is no deep architectural principle here --
either approach exposes essentially the same order of complexity from
the service provider to the service consumer.
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php>
Thread:
Claude L Bullard
Marc de Graauw
Joe Gregorio
Bill de hÓra
Michael Champion
Uche Ogbuji
Jan Algermissen
Uche Ogbuji
Rich Salz
Jan Algermissen
Rich Salz
Michael Champion
Bill de hÓra
Michael Champion
Uche Ogbuji
Bill de hÓra
Robert Koberg
Peter Hunsberger
Michael Champion
Leigh Dodds
Jan Algermissen
Leigh Dodds
Bill de hÓra
Michael Champion
Leigh Dodds
Michael Champion
Rick Marshall
Bill de hÓra
Robert Koberg
Rich Salz
Leigh Dodds
Rich Salz
Leigh Dodds
Rich Salz
Leigh Dodds
Andrzej Jan Taramina
Rich Salz
Bob Foster
Jan Algermissen
Mark Baker
Michael Champion
Michael Champion
Mark Baker
Mark Baker
Michael Champion
Bill de hÓra
Rich Salz
David Lyon
Rich Salz
Joe Gregorio
Rich Salz
Joe Gregorio
Saptagirisa N
Arvind Singh
Rich Salz
Joe Gregorio
Rich Salz
Joe Gregorio
Rich Salz
Dave Pawson
Mark Baker
Joe Gregorio
Mark Baker
Rich Salz
Michael Champion
Elliotte Rusty Harold
Joe Gregorio
Michael Champion
Jan Algermissen
Bill de hÓra
Joe Gregorio
Charles Woerner
Rich Salz
|