[
Lists Home |
Date Index |
Thread Index
]
> After all the threads on this, I can't remember ever
> seeing this question answered. Can someone point me
> to a list of the capabilities that one gets using
> SOAP/WS* that one won't get using REST?
I don't think you'll find anything close to a comprehensive list for two
major reasons
Its almost as much political as technical
The WS-xxx stack is a long way from being done, to say nothing
of getting various standards committees working on the parts.
If we compare WS-xxx with HTTP (as the most widely deployed example of
REST), a few things come to mind, some of which will matter, and some
which won't:
SOAP supports richer message patterns, including multiple parties
processing a message along the way.
HTTP proxies might require you to put no-transform in your header to
avoid someone converting your message. (14.9.5 of HTTP1.1 spec) -- yuk.
In fact, the whole proxy stuff in HTTP plays havoc with your meta-data
Speaking of which, SOAP has a place for metadata and a rich set of
standards; HTTP has a place (the headers) with problematic standards
There is no standard way to RSA-sign a request or a response
My biggest problem with REST, the architecture, goes back to a thread
Rusty and I had months ago. REST is requires all state to live in the
messages exchanged between the two parties, and the only standard way to
sign content goes against acceptable security practices -- everything
uses your "login" key, as opposed to a session key. Yes, you could
define appropriate media types and use of HTTP 40[123] to effect a state
machine and do the right thing, but , err, yuk. :)
/r$
--
Rich Salz, Chief Security Architect
DataPower Technology http://www.datapower.com
XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
|
