Pete Lacey’s Weblog

It’s time to reawaken this blog, and the current POX/REST/SOAP thing is as good a reason as any. Everyone has something good to say, and I have comments for everybody.

Leonard Richardson kicked it off while ruminating about the forthcoming book on REST that he’s writing in collaboration with Sam Ruby. In it he notes that the HTTP+POX services made evident by Web APIs such as those from Flickr and del.icio.us are not completely without architecture, but lean towards the RPC style of SOAP. I contend that this is not true. That these services have an accidental RPC-like architecture that comes from trying to avoid SOAP while still being muddled in traditional RMI/CORBA style networked application development. While this may be the simplest thing that possibly works, they do themselves no favors by avoiding both REST and SOAP. This is what Duncan Cragg calls Service-Trampled REST (STREST). Leonard makes the great point that most browser-oriented web apps are not RESTful either.

Leonard goes on to note that the PUT and DELETE HTTP verbs are absolutely required by REST, because without them one is tempted to overload POST and put actions in the URL. In practice, this is somewhat true. However, you can’t make the argument that REST is all about the HTTP verbs without conflating the two. REST is informed by HTTP and vice-versa, but they are not synonyms. Tim Bray is correct, REST requires a means of safely retrieving a resource’s representation (Get) and a means of changing the state of that resource (Post), PUT and Delete are nice to haves. Just PUT really, as no one really deletes anything. I would argue that if all of WEBDAV’s methods (COPY, MOVE, LOCK, etc.) were part of the original HTTP specification, Leonard’s line of reasoning would mandate them too. That said, it is extremely convenient to be able to distinguish POST from PUT.

The ensuing discussion addressed most of the rest of Leonard’s post, and I’ll get to them in a second. I’ll answer one more question that Leonard raised, however. For all intents and purposes, the term “web services” has been lost to anything but SOAP and the rest of the WS stack. SOA is an architecture that (tends to) leverage web services. Contrary to what some claim, a SOA cannot be using REST, simply because not all resources are services.

Sam picks up the ball by implying that the line between SOAP and POX (not REST, POX) is finer than one would think. I’m fine with that, but that’s likely because both POX and SOAP are a mistake. SOAP for all the reasons that Steve Loughran pointed out (and them some; links anyone) and HTTP+POX because it is just a simpler RPC mechanism.

Things really get ugly when Sanjiva Weerawarana (of WS02 and Axis2) weighs in. Sanjiva gets it all wrong, but not necessarily entirely from a technical point of view. From my vantage point as a Burton Group consultant, I know is being peddled to enterprise customers, and it’s not some idealized notion of “SOAP is whatever you want it to be.” It’s the whole butt-ugly, can-never-be-restful, WSDL 1.1, WS-HairBall stack.

But on to the details. Mark Baker correctly brings Sanjiva to task for the bulk of his argument. Summary: SOAP is not whatever you want it to be; there are expectations that both communicating parties interpret a message identically. To think otherwise is ludicrous. To believe that a developer coding to Microsoft’s WSE expects BEA’s SOAP stack to freely interpret the intent of his message is just wrong. In Stefan Tilkov’s otherwise excellent response, this is where he gets things just a bit mixed up. Yes, the SOAP envelope all by itself can be a good thing, but SOAP is more than an envelope. You can’t ignore how SOAP is packaged and sold, how it is specified, and how it is implemented. SOAP, despite everyone’s best efforts, is still a remote object protocol, and somewhere in the message, whether it be in the SOAP Body, in a WS-Addressing header, the outer element of a wrapped doc/lit message, or in the SOAPAction HTTP Header, is the method to invoke on the remote object. And, remember, to the business developer, SOAP is also WSDL, and a mish-mash of encoding styles and serializations, and impenetrable XML Schema, and tModels, and vendor wars, and ESBs, and shoddy specifications, and on, and on, and on.

Sanjiva then goes on to make the increasingly common claim that SOAP is only useful when you want to solve enterprisey problems like reliable messaging and end-to-end security. This is interesting in a number of respects.

1. The number of people using WS-ReliableMessaging in production today totals zero.
2. The number of people using all of WS-Security (and not just username tokens) approaches zero
3. These numbers hold true for WS-this-that-and-the-other-thing too.

Zeroing in on WS-Security we can note a few other things. To argue that securing the message (admittedly handy, but handled by XML Digital Signatures and XML Encryption, and only complicated by WSS) and not the protocol is of absolute importance, ignores the fact that we’ve been building secure applications without this ability since time immemorial. It further ignores that a sound architecture does not ask the endpoint to do the decryption, but that the decryption is done upstream in a web service intermediary of some sort, possibly one that precedes other intermediaries, thus negating this argument entirely.

In short, if SOAP is only useful when used in conjunction with the advanced WS framework, then, for the time being at least, SOAP isn’t useful at all. With the exception of WSS, no other specification has been fully ratified. And to repeat, this is not what’s being sold to the Global 2000 customer. They are being sold SOAP and WS-* from top to bottom. Not, REST when you can and SOAP when you need to.

And, so it doesn’t look like I’m copping out, I’ll answer the next question, “So how then do we meet these enterprise goals of reliability, security, pub/sub, etc.?” The answer varies depending on the need. I suspect that we don’t need anything new to cover what WSS covers, though having it may open up some new opportunities. For the relatively small number of apps that need or desire reliable messaging, pub/sub, etc., then I would say use the technologies that exist to fit that need: MQ-Series, TIBCO Rendezvous, etc. Not everything has to be an HTTP/REST app. (Note, pub/sub is already RESTful in its own way: write a message, read message - nice. Also note, that three of the four main HTTP verbs are reliable enough; GET, PUT, & DELETE.)

And for the record, I do not believe that REST services are currently defined well enough. I think having a standard envelope would be kinda useful, HTML has one. I think it would useful to put a stake in the ground and say XML is the standard for representation. I think that REST needs a better name.

It’s good to be back.