Slashdot Mirror

Since you are simplifying your life by making the schema for web requests simpler, why not go all the way, ditch SOAP, and embrace REST for XML-over-HTTP communications?

Oh, and nobody cares about SOAP, anyway.

Here are some links. See esp. the REST Wiki:
Adam Bosworth's Weblog: Learning to REST
Bitworking - The Well-Formed Web - REST
Debate foams over SOAP 1.2 - REST versus SOAP
How To Convert Rpc To Rest
http://www.xfront.com/ - REST Tutorial, XML et al - Roger Costello's site
ITworld.com - XML IN PRACTICE - XML, Web Services, and the REST Architecture
Mark Baker, Tech Curmudgeon - REST - Transport, transfer and coordination in HTTP
O'Reilly Network: REST vs. SOAP at Amazon [June 24, 2003]
Paul Prescod's REST Resources
Reliable delivery in HTTP - REST
REST A Web-Centric Approach to State Transition - Paul Prescod
REST could burst SOAP's bubble - Hoobler
REST Faq - Alternative to SOAP XML
REST SlideShow: Representational State Transfer: An Architectural Style for Distributed Hypermedia Interaction
REST wiki - Representational State Transfer - alternative to SOAP XML
rest-discuss Message 2330 - ROP vs RPC vs OOP pt 1
Roots of REST - SOAP Debate - Paul Prescod Yahoo! Groups : rest-discuss Messages :Message 1314 of 1646
Roy T. Fielding - REST Architect
Sean McGrath BLOG - REST proponent
W3C mailing-list search service on REST
Why you should not use RPC for GET
xml-dev - Re: [xml-dev] SOAP-RPC and REST and security
XML.com: In a Lather About Security - SOAP security vs REST security
Yahoo! Groups : rest-discuss Messages : 2371-2428 of 2428

RESTful web services are the services primarily in place today: they utilize existing WWW security standards, are easy to implement and debug, and are available today.

• REST Wiki
  
• Building Web Services the REST Way
  
• Paul's REST Resources
  
• REST and the Real World
  
• Second-Generation Web Services
  

Do you mean alternatives like CORBA, or like REST? REST to me seems the proper way to go about web services for 99% of web services people are building. Most people are doing simple calls... the only trick that remains (and is evidenced in the interview) is a simple means of creating objects that represent web service calls and results, to make working with the calls more natural in the OO language that most corporations are using right now. I'm hoping a simple mapping layer on top of a pull parse is a good answer - I'm trying out JiBX for that although it's still rather beta.

In theory with a good mapper to and from the XML should alleviate the collection problem they talked about in the article by naturally generating good XML for Maps and Lists, and converting back just as easily.

"Care to explain how you would do it in a more "architecturally sound manner"?"

For a web site? Use REST. For anything else? Use a well designed IPC protocol.

"If there's a programming flaw that allows you access to Amex's customer database it could just as easily occur in the website."

Sigh. If a security hole is found in a webserver, the impact will likely be far, far less than if a hole is found in a SOAP implementation. The difference is what people are going to do with the technology, and how they are going to do it. What SOAP's role in a software architecture is. A web site won't let you *directly* query customer records, or *directly* make purchases. A SOAP API will.

"SOAP definitely has its place".

No it doesn't. It violates the Web and Internet architectures. It makes it easy to get around network security. It piggy-backs on application-level protocols which it shoudn't. It pretends to not be an application-level protocol when it is.

Whilst it looks nice, SOAP is quite fundamentally broken.

• Death of the Browser? (on Microsoft's site) and
  
• The Return of Client/Server -- or, at Least, Rich Clients
  

But first go see how Debate foams over SOAP 1.2 in the W3C working groups for XML, SOAP and Web Services.

It seems that Roy Fielding, one of the key architects of HTTP and a member of the W3C TAG (Technical Architecture Group), which essentially defines the principles of Web architecture inside the W3C, pointed out that the SOAP specification broke universally-accepted WWW protocols and would be unlikely to succeed. At the same time Fielding and others have pointed out that Web Services can easily be implemented today including all desired security and authentication by using current WWW protocols and by judicious use of what he calls a REST Architecture, a subset of the current WWW architecture.

Microsoft's plan is unlikely to work: the members of the involved working groups have realized that failure of SOAP to be consistent with WWW will doom it to failure because of the additional complexity and lack of scalability that would entail.

See also

• Paul Prescod's Home Page and especially the section "HTTP and REST" wherein he elucidates the subtleties of REST and how SOAP breaks the WWW. Prescod is one of the most vociferous and well-written supporters of the REST architectural style in the W3C working groups.
  
• A REST Tutorial for Roger Costello's brief but excellent introduction to Roy Fielding's REST and why it will be the basis for any viable Web Services architecture.
  
• Visit the REST Wiki to relax in an oasis of ideas that explains how Web Services can be implemented today in a manner
  
  • not as complex as the proprietary vendors and current and pending specifications of SOAP appear to require,
    
  • using the technology and tools you already know.

Finally, dive into the waters of the oasis and wash the SOAP off of your soul. Now pure of heart, make a pilgrimage to Tim Berners-Lee's Design Issues for the World Wide Web where you can

• re-examine the issues of the WWW,
  
• renew your commitment to doing things "the right way",
  
• revive your passion for excellence and
  
• remind yourself that indeed, sometimes "less is more."
  

So what is the big deal with XML Schema? XML Schema is important because it provides the widgets to define a "card catalogue" for your library of data, be it air plane parts, phone bill, hotel reservations, or porn.

Now metadata has been with us since the mud table libraries of Mesopotamia (they had indexes of stuff so they could find how many cows were traded in the Xth year of SomeRulerDude), however the printing press is what made all the difference. You see, before the printing press books were so expensive and time consuming to write, there were not that many of them. The general strategy to manage a library was an index of all the books. As long as the book population was not too big, then this works. For example, when you search on google for "McCain", you get congressman, porn sites, and damn near everything in between. Search engines today are just really, really big indexes of stuff. Still in the stone ages, aye?

The printing press changed that and forced libraries to find an EXTENSIBLE way to keep up with books. The Dewey Decimal System is a great example. So I pose to you the following question, "When was the last time the DDS was updated?" Well, how long have they been publishing books on computer science, biogenetics, or nanotechnology. The DDS is an extensible system to classify knowledge. So I leave you with the following statement...

HTML was the functional equivalent of the printing press, which is just an electronic version of fast, cheap publication. HTML forced us to follow down the path of XML, just like the printing press forced Mister Dewey to put on his thinking cap. The only difference is that the printing press took a few hundred years to do its thing where HTML only took a few years to do its thing.

Now for all the other XML specs out there (SAX & DOM, RDF, XSLT, XHTML, XPointer, etc) are just tools to work with your (library of) data. Better to have many specialized tools that can evolve independently than one big honking tool, aye? Use only the tools you need.

So does TBL's dream of a semantic web make more sense now...?

If you want some links, try...

Danny Hillis - The big picture

Roger Costello's XML Schema Tutorials

"You can drive a car by looking in the rear view mirror as long as nothing is ahead of you. Not enough software professionals are engaged in forward thinking." - Bill Joy