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

On Jan 23, 2004, at 6:45 AM, Bill de hÓra wrote:

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

SOAP does not "rock" for everything any more than REST does. They can 
be used, sometimes together, when either are the best tool for the job. 
  SOAP *especially* does not rock for simple, Web-based, 
document-oriented services such as Google or Amazon provide.  I pretty 
much completely agree with Paul Prescod's famous dissection of Google's 
SOAP API.  I just don't think that implies much about the suitability 
of SOAP for information integration in enterprise transaction 
processing environments, which is what pays my salary.

Ummm think about it .... am I "attacking REST" by asserting that it 
hits the 80/20 point for many web-based services but has no well-known 
success stories for more complex integration situations?  I understand 
from Sean (McGrath, the CTO) that Propylon has some real success 
stories, but you're not telling them to the world for whatever reason.  
If this is your secret weapon, great :-)  But don't expect us to take 
that on faith.  We don't have to take the simple case on faith because 
Amazon has provided both interfaces for its lookup/query services, and 
developers choose the REST ones 4:1 or whatever.

We (the industry, but including my employer)  have lots and lots of 
real success stories using SOAP/WSDL in integration scenarios, and lots 
of real money invested in this story.  The best way I know to reconcile 
the facts available to me is that REST seems to be a best practice for 
simple services over the Web; SOAP increasingly adds value as the 
diversity of "transports" [down Mark, down!] increases, the need to 
maintain transaction context increases, etc.  Again, the WSA document 
doesn't have to reflect my opinion, but obviously it has more value to 
me in the Day Job (and probably to a number of others in my situation) 
if it does.


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

SOAP provides a framework upon which many specs build to provide 
services such as reliable messaging, orchestration, identity 
management, encryption, digital signatures, transactions, 
notifications, etc, etc, etc, that requires little awareness or 
expertise by the application developer in these technologies.  That's 
what I mean by "infrastructure."  Of course, this can be done at the 
application level in XML without SOAP, but there are (AFAIK) few 
standards, tools, and best practices to make this easy.

SOAP itself is no better at handling complexity, but it provides a 
framework or "infrastructure" upon which many vendors are building 
tools that handle the 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.
>
>
That's pretty much the opinion I've come to over the last 2 years.  I 
came in with pretty strong feelings about the "schema gorp" and the RPC 
abuse by tools such as VisualStudio.NET.  I've seen a lot of evolution 
within the Web services community towards asych, document oriented, 
appropriately coupled uses of SOAP, so I don't think these are legal 
weapons against SOAP anymore.

Received on Friday, 23 January 2004 10:22:36 UTC