Re: Section 1.6 and REST - Can we make this more clear and useful?

Michael Champion wrote:

>  I'd appreciate some immediate pushback if this seems wrong and not just 
> in need of more elaboration and justification:

Mike,

Here's some pushback.

> The REST style lends itself to simple business services when a) the 
> operations of the service correspond directly to the "CRUD" operations 
> of the REST generic interface; b) when the semantics of the data being 
> represented are well-defined and widely supported by software; and c) 
> when HTTP is the only protocol of interest in the service environment.  
> [1]  More complex services that use something analogous to "hyperlinks 
> as the engine of application state" *may* be effectively developed using 
> the REST style, but there are few real-world examples and this is at 
> best a bleeding edge approach.  SOAP provides a framework for adding 
> additional features at the infrastructure level -- such as reliable 
> messaging across multiple network nodes or over different protocols, 
> business-level transaction processing, orchestration/choreography of 
> multi-part services, and security features such as identify management, 
> encryption, and authorization -- that are not specifiable using the pure 
> REST style. In SOAP and REST can be used in conjunction with one 
> another, but again there are few real-world examples and tools 
> supporting SOAP 1.2 and WSDL 2.0 that enable this in principle  have not 
> yet been deployed.

Instead of attacking REST, I would just as well be explicit - prefer 
SOAP; use SOAP; SOAP rocks.

What does infrastructure level mean there? Perhaps clearing that up 
would help someone understand the assertion that SOAP is good at 
handling complexity.


> To summarize, REST is an appropriate style for simple services deployed 
> over the Web; SOAP adds more and more value as complexity increases 

That has not been my experience but perhaps I'm not doing complex 
enough things to understand when you're coming from. My experience 
is that SOAP generates further complexity. Then again it's difficult 
to separate SOAP out from W3C XML Schema gorp and past abuses of RPC 
  so that might be unfair - guilt by association.


> because it provides a framework for technologies  built on SOAP that can 
> add reliability and security at the infrastructure rather than 
> application level.

I do not agree re security, identity control, access control, 
authorization - REST style seems to me to actively induce security 
capabilities, but I see nothing in SOAP for that. What security do 
technologies built on SOAP infrastructure provide that technologies 
built on Web infrastructure do not, or can not? Are we ready to say 
that SOAP is a proven technology in that respect?

By the way, I agree with the assessment of REST for things like 
reliability and transction support, and if you had mentioned 
eventing/notification, I would have agreed there too.

cheers
Bill de hÓra
-- 
Technical Architect
Propylon
http://www.propylon.com

Received on Friday, 23 January 2004 06:45:09 UTC