Marc Hedlund weighs in:
Speaking as a technologist, I think the demand for REST in this case is driven more by aesthetics than practicality. Maybe it's really just anti-Microsoft. It feels like bloat, so people are opposed to it.The longer this debate continues, the more convinced I am that SOAP isn't a hype-driven revolutionary technology, but rather a small evolutionary step. That it is hype driven and not revolutionary is no surprise; that it is even more minute of an evolutionary step than we first believed is a surprise.
There are issues with SOAP avoiding GET requests that have proven themselves to be a time bomb. However, it seems quite odd that it took four years for this bomb to detonate. It's also quite telling that this isn't a single isolated multi-megaton blast, but dozens (possibly hundreds or thousands) of little chinese firecrackers going off in fits and spurts.
SOAP got two things very right: a generic encoding for messaging using XML (that co-incidentally uses the web for transport), and an XML-based set of auxiliary standards (particularly it's IDL language, WSDL).
The pro-REST argument highlights that (1) SOAP doesn't use GET, so it breaks the intent of the web (or, is less aesthetically pleasing than simple HTTP GET), and (2) SOAP prevents certain micro-optimizations that can be beneficial, sometimes, for in some cases, on alternating thursdays.
What's the best that we can hope for? For the RESTful to stop castigating the use of SOAP for a the small set of possible SOAP messages (which just so happen to comprise the vast majority of SOAP traffic), and start learning from where SOAP actually made strides with interoperability so that they can be extended.
In an effort to help fight global warming, I've tried to avoid emitting heated gas about this fatuous and tedious argument, but alas I am only human.
The GET semantics argument is pedantic at best and diversionary at worst. I understand that HTTP GET should retreive "unchanging" content (like looking up word definitions in a dictionary). In a perfect world, HTTP POST is used to "upload" user data to a web server. The reality of the web, excluding ALL web services [that is XML over HTTP stuff], is that GET is used when web applications folk want to see CGI arguments in the URL line (very useful for creating hyperlinks) and POST is used to "hide" arguments from the URL line. Empirically, this is how many users think of GET and POST. To whine about how aesthetically unpleasing this reality is doesn't sway me much.
It is entirely proper for web services to use POST. Why?
BECAUSE WEB SERVICES HAVE NOTHING TO DO WITH THE WEB!
Huh? Don't XML-RPC and SOAP use HTTP to pass messages over the wire? Don't "web services" have the word "web" right in the title?
In the same way "LiveScript" became "JavaScript" even though the language has nothing to do with Java, "Web Services" are riding the Web's PR coattails. The same kind of addled thinking that leads some to think that the word "mailman" is doublely sexist is at working here trying to apply the unrelated rules of "The Web" to an innocuous RPC mechanism. Don't fall for it.
Can HTTP be used in more than one context? Of course! In fact, Web Services are exploring other "transport" protocols besides HTTP (Jabber being the most interesting).
The is room enough in the world for both the REST folks and the Web Services folks. The ecosystem of programmers will determine which idea was better.
If one wanted to complain about SOAP, let's talk about the need to gz these bloated XML messages as they pass across the wire. I know, let's add yet another structure to a SOAP document. Let's call it "signature," so that all you wack MC hackers can add your email's tag line to all SOAP messages. Now THAT'S innovation.
Re:GET back
ziggy on 2002-04-25T16:10:23
Actually, not quite. GET should be used for retreiving constant resources. The URI http://use.perl.org/ uses GET because it always returns the use Perl; homepage (as customized by a user, identified by cookies). Ten requests will return ten different sets of HTML output, but they will always return something conceptually considered to be "the use Perl; homepage".I understand that HTTP GET should retreive "unchanging" content (like looking up word definitions in a dictionary).Yes, it's a semantic game.
Er, not quite. Rael has written a little perl app that queries Amazon for including interesting queries on a web page. Much like a slashbox. This is one interesting, if popular and trival use of web-based RPC protocols. It's just that in the case of RSS, we don't think of it as an RPC protocol, as much as it's a document retrieval (because it mostly is).WEB SERVICES HAVE NOTHING TO DO WITH THE WEB!
--Nat
