Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Journal of johanvdb (1872)

Sunday October 13, 2002
02:27 PM

REST when tired of SOAP and XML-RPC

[ #8357 ]

Webservices ... who needs them anyway? I just received my copy of The New Architect and it had an article about webservices and if they can work economically. Microsoft has put a big bet on web services, elaborating on Dave Winers XML-RPC protocol. A protocol that, nota-bene, has been developed for weblog interoperability. Now, for one thing XML-RPC is easy to understand, not bloated and usefull. SOAP on the other hand is bloated has a Signal To Npoise ratio of almost 0 (S/N = [payload bytes]/[markup bytes] = ratio of payload to markup), but has one big advantage. It has caught on by the big public, and I guess this has something to do with the ease to be able to make use of SOAP.
As a user of a SOAP API, you just have to fire up your IDE and point it to the WSDL file, describing the SOAP API for the web service you are going to use. After that, you can automagically call the API, like:
And all this has been tauted in popular IT magazines ...

Anyway, SOAP has a lot of problems and one of them being that it is just not a standard protocol. It is an application protocol layered on top of another application protocol (HTTP).

In the past I've written up web scrapers for a multitude of services, and I was doing a primitive form of web services. Tim O'Reilly looks at this as using the URL as a sort of command line. He coined up the term 'URLline interface' at Emerging technologies keynote speech.

I always have had a guts feeling that SOAP is too bloated. I love XML-RPC, because it is lean and mean and the most important feature for me was the fact that on the server a method was called with the correct parameters filled in and on the client I just invoked a method call that would automagically be resolved on the server side.

Last week I came across a new concept - REST - that stands for REpresentational State Transfer. It describes the standard HTTP protocol as good enough - and even better - to implement web services. It compares HTTP and the URL as something that mimics the openess of the UNIX platform. On UNIX you can pipe output from one app to the input of the other. Building complex stuff with simple application that each perform an atomic unit of work.

Anyway, I'm going to spend some time this week to read up on the ideas of REST. Maybe it will give me a clearer idea if investing time in SOAP is worthwile ...


The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.