ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> xml-dev
xml-dev
Re: [xml-dev] What Does SOAP/WS Do that A REST System Can't?
by Rich Salz other posts by this author
Mar 30 2005 10:22AM 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 >  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

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

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved