All the Perl that's Practical to Extract and Report

No REST for the SOAPy?

rjray on 2002-04-26T03:30:07

There's an article over at XML.com in which the author contends that Google's recent roll-out of a SOAP-based API is a bad thing, described as "one step forward, two steps back". The basis for this contention seems to be the emerging REST (REpresentational State Transfer) approach, the basis for Amazon's web service interface. But I'm not really buying the argument, and not because of lack of familiarity with REST.

My reservations are that the arguments seem to revolve around whether the GET or POST HTTP verbs are the way to go. More specifically, the argument seems to focus on whether the same sort of functionality can be accomplished without the overhead of a full-on SOAP envelope. This is not an empty argument. Matts, in a recent journal entry, made a very valid complaint: Google had, before the much-trumpeted SOAP roll-out, already provided an XML searching interface. This interface is fully-accessible from a GET URL, so it would seem (from first glance) that moving to a SOAP envelope is excessive. Perhaps in this specific case, it is.

The problem is, I can't help feeling that to embrace this is to completely ignore the future potential that a fuller SOAP interface could offer. True, there are layers to be had in the REST specification that I have not yet read. But that isn't the problem. The problem is that arguments are being based (it seems) on the fact that current applications based on SOAP are pretty much XML-RPC-based applications with greater verbosity in the wire protocol. But that is the current crop of applications, and that crop is just the beginning. It's no more valid to judge SOAP on the merits of these applications than it is to judge Perl on the first generations of scripts written for the earlier versions of the language.

Web services are still relatively young, even in Internet-years. Google's API is more than just a new level of convenience (if even that), it's a sign of corporate-level acceptance and embracing of the concepts behind web services. Without these kinds of moves, the only thing we're likely to see are those that are directly cooked up by monopolistic entities whose intent is to corral the future direction of information exchange and route it through their narrowly-defined corridor-- .Net, anyone? The API Google shares with us today may not look like a significant accomplishment, but what sort of framework is it laying for the API that may be rolled out next month, or next year? It may be that REST has some really strong potential, and it deserves fair evaluation. But it needs more adoption, more examples. The main documents I've found on it are one link from the original XML.com article (link here, note that it is by the same author who is criticizing SOAP in the current article), and the originally Ph.D dissertation by the person who coined the acronym, Roy Fielding (dissertation available here).

I think the mistake that is being consistently made is assuming that all SOAP applications will always be based on an RPC model. There's no way to know that for certain. The WSDL specification allows for identifying a service as having a document-oriented nature as opposed to a rpc-oriented one. I haven't seen any document-oriented services yet, but I expect to. I think proclaiming SOAP as obsolete is vastly premature, just as it would be to make such a claim about RPC in general (or XML-RPC in particular). When Java was first introduced, it was scrambling for a viable niche in the field of programming languages. While some would argue with me on this, I think it's started to find its place with applications such as ArgoUML and StarOffice. And that is what I think the arguments over SOAP vs. REST and all the other RPC models boil down to: what niche is there to be filled, and how many solutions can be fit into it?

Java found a place without displacing any other languages. Maybe REST can find a place without having to displace SOAP in the process.

--rjray

The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary. -- James D. Nicoll

Bigger better SOAP apps

Matts on 2002-04-26T09:41:46

I think part of the problem is that nobody is actually building bigger SOAP apps that operate over the internet. The reason is that it's really damned hard to do that, because issues of statefulness, performance, scalability, balancing, and so on haven't been properly solved for SOAP yet. The funny thing is, if you need to build a large network application today, it's probably a hell of a lot easier and faster to use either DCOM or CORBA IIOP, and those systems have gone through a lot more debugging and development. And generally the sort of application you'd want to build with that level of interaction wouldn't need the firewall smashing that SOAP provides you with (actually that's probably quite naive of me - I guess a lot of corporations have internal as well as external firewalls - CORBA over HTTP anyone?)

There's also a huge problem in concepts here. I think the REST people may have done huge damage to their cause by way too much hand waving, and by simply calling it "REST". I mean, "Representational State Transfer" - wtf is that supposed to mean to a web hacker???

The irony is that REST has been with us since pretty much the dawn of the web. Google's original plain old HTML interface is a REST interface. It just happens to be for human consumption, not computer consumption. use.perl is a REST interface (again, for human consumption). You see REST is just the web as we know it from a browser. The REST technique is to simply allow that to work for a computer, by returning XML structures rather than HTML, that the computer can operate on.

The big problem REST faces is just that it's an uphill struggle. For SOAP/XMLRPC you already have an API, and we have modules for it in all languages. For REST you currently have to build your own API, even though it's conceptually much much more sensible on the wire. Nobody cares that much about what goes over the wire, as is evidenced by the popularity of many "inferior" technologies that just plain get the job done.

And at the end of the day, most people just want to get their job done.

Re:Bigger better SOAP apps

ziggy on 2002-04-26T20:13:51

The big problem REST faces is just that it's an uphill struggle. For SOAP/XMLRPC you already have an API, and we have modules for it in all languages. For REST you currently have to build your own API, even though it's conceptually much much more sensible on the wire.
The biggest problem with REST is that it is purely conceptual. So the problem really isn't that there is a SOAP/XML-RPC API available, but REST is fundementally API-less.

One step forward would be to develop a RESTful API to sit alongside SOAP.

Nobody cares that much about what goes over the wire, as is evidenced by the popularity of many "inferior" technologies that just plain get the job done.
There are a lot of straw men inhabiting htis discussion, and "over the wire representation" is possibly the weakest one of them all.

What's really at issue here isn't the over-the-wire representation of a message, the efficiency of a transaction, or the elegant purity of a solution. The crux of the issue is integration of the web. Non-RESTful uses lead ghettoization of information: a simple request that hides behind a POST API can't be integrated into the rest of the web proper. This is what Dan Connolly describes as the proliferation of N > 1 webs.

SOAP vs. REST

ziggy on 2002-04-26T20:28:50

Java found a place without displacing any other languages. Maybe REST can find a place without having to displace SOAP in the process.
According to the REST folks, it's not an open playing field where the two could live in harmony. What's at stake is nothing less than the web as we know it. So while Java, Perl, C++ and C# can live in harmony in an open system we call the IT sector, SOAP and REST can't live in harmony in the closed system we call the Web.

The key issue is this: there are some operations that are safe, and always return the same conceptual result: http://www.google.com/search?q=perl, http://www.news.com/, http://search.cpan.org/search?dist=perl. The way the web was designed, these resources are identified by their URLs, and should be retrievable with GET requests. They can then be referenced anywhere you can place a URL -- web pages, XPath expressions, XSLT stylesheets, RDF assertions, XLinks, etc.

The issue behind putting resources such as this behind a POST request (using SOAP, XML-RPC or any other technique you care to use) is that such uses of HTTP POST have the nasty effect of hiding information and inhibiting it's use elsewhere on the web.

OTOH, the SOAP advocates color this debate as simply a few academics crying for intellectual purity, aesthetic beauty and spilled milk because the other side "has won".