Web Things, by Mark Baker

Google Fight speaks on the REST vs SOA(P) debate. We now know, unequivocally, that people prefer napping to bathing. 8-)
(link) [del.icio.us/distobj]

I’ve talked about both the pluses and minuses of Amazon‘s approach to Web Services for some time now. Recently, I’ve heard that they’re in the process of greatly expanding those services, which is great. But I think that before they go too far with that, they should really dig a little deeper to learn why it is exactly that their “RESTful” data retrieval services are getting the uptake they are.

I don’t think it’s controversial to claim that Amazon see the REST vs Web services debate as primarily about encodings; either a message is encoded as a SOAP envelope, or it’s encoded as a URI, but in both cases the abstract message – the information being conveyed – is identical. I completely disagree, of course, and believe that there’s a very large architectural difference between those two approaches; that in http URI form, the URI isn’t the message, and instead, the surrounding HTTP message which encapsulates that URI becomes the real message, while the URI itself is treated as an opaque bag-o-bits. Through this encapsulation, GET becomes the operation.

What I just described I refer to as “accidentally RESTful”, and it’s sur– prisingly common. And while, for the simple data retrieval case, it is RESTful, and a significant improvement over vanilla SOA, you’ll find that as you add support for state-changing actions and just generally evolve that application over time, you’re going to run into many of the same problems you’d run into doing SOA.

Fair warning!

Update; oh, I suppose this is, in part, a response to something Dare said a couple of weeks back; those APIs he lists ARE RESTful, at least with respect to using the uniform interface.

Another gem from Dave;

This is the main thesis of this article, that the application layer modeling is affected by the underlying protocol.

Absolutely. I think the leaks that Dave so accurately describes there, is, largely, his fault (but a Very Good Thing! 8-). He has tried to respect the architecture of the Web in his work on Web services, and as a result, created the problems he now describes, along with everybody else who ever pushed to defend a principle or constraint of Web architecture, including myself. I was very frankly surprised that it took this long for a Web services proponent to point it out, but I’ve been doing it for a while (and long before that post – it’s just the most succinct description I could recall of the layering problems with Web services, albeit slightly different ones than Dave’s describing).

He goes on…

Another possibility is to throw out anything “extra” from the underlying protocol, that is effectively dumbing HTTP down to UDP.

Yes, that’s the only way that what most Web services proponents know “protocol independence” to mean, could be realized, and the leaky abstractions Dave speaks of, avoided.

The next sentence reads;

Web services using SOAP and WSDL 1.1 has already done that by ignoring the HTTP Operation.

Right. And as I mention in the above mentioned post, there’s more than just the operation which is ignored, including the Request-URI when using wsa:To, and the response code when assuming any response with a SOAP fault element is a fault.

Unfortunately, at that point, Dave apparently reiterates his undying faith in this beast of an architecture, and attempts to resolve this fundamental problem within it. Ouch!

There is another way; embrace the Web.

Oh, and all this reminds me that Steve Vinoski and I just had a great chat where we came to agree on what was and wasn’t desirable to do in the name of “protocol independence”.

Dave writes;;

In the Web services vs REST debate, the sad part is that the communities are not coming closer together. There are things that could be done for Web services to integrate with REST but few people from either camp are jumping up and down.

Let me ask this, what’s the middle ground between a position which says “Interface constraints are required for Internet scale distributed systems”, and one which says “Service specific interfaces are required for Internet scale distributed systems”? IMO, there is none. “Support both”, which is how I’d characterize Dave’s many well intentioned efforts to bridge the divide, is not a middle ground, since supporting both requires rejecting the interface constraint. Either that, or you’re talking about supporting two distinct architectural styles, which is the aforementioned divide. Practically though – in terms of the many specs being developed, I think the only middle ground is RESTful SOAP, which isn’t so much in the middle from a REST POV (since it is REST), but is from a Web POV, in that SOAP would be used to extend the Web rather than walk all over it. FWIW, that position is what I’ve been fighting for since I joined the XMLP WG. I’m really quite a moderate. 8-) He ends;

[…]I call on technical people to engage in deeply technical debates and less on “marketing” campaigns.

Ouch! 8-O There’s certainly been some “non” and poor technical arguments made on the REST side (as I mentioned publicly, I didn’t care too much for one of Carlos’ posts on the topic), but by and large the arguments have been entirely technical! I’ve certainly primarily used technical arguments over the past five years. It is to Dave’s (enormous) credit that he made the effort to describe SOA as an architectural style, but he’s been the only Web service proponent who’s even attempted to use the language of software architecture to defend his position (even if I often disagree with him when he does). But notice how his efforts never made it into the Web Services Architecture document! What does that say about the aggregate respect for software architecture by the WG? Oodles, IMO. The truth is that there’s already been a whole lot of technical debate, some of it even fruitful. The camps have just agreed to disagree, insofar as Web services proponents argue, in effect or actuality, that either a) the architectural properties that SOA doesn’t have that REST does, aren’t important to Internet based systems, or b) that SOA does not have less of some architectural properties as REST proponents claim, digital marketing services. I’d also like to remind Dave how we got to this point. Web services were created because it was felt that Web architecture wasn’t sufficient to integrate disparate applications together over the Internet. Actually, that’s not quite right. The explanation that seems to better reflect reality is that the Web was never considered as a platform suitable for meeting the objectives of Web services, as can be demonstrated by the numerous articles talking about how Web services evolved from the likes of CORBA, DCOM, RMI, etc.., without mentioning the Web!! The Web just didn’t resemble what folks knew a distributed computing solution to look like, so it just never registered in the heads to consider it. Well, the myth of the Web being unsuitable has been largely dispelled by now. The big question then, I’d say, is why haven’t the implications of this – that Web services exist – been revised as a result?

Dare Obasanjo, RESTafarian 8-)
(link) [del.icio.us/distobj]

“Document style indicates that the SOAP body simply contains an XML document.”. Now there’s a definition I can get behind!! Too bad most contain wsa:Action nowadays.
(link) [del.icio.us/distobj]

Phil Windley summarizes a point made by John McDowall;

In other words, conveying meaning trumps protocol as a priority for interoperability

Ah, but protocols convey meaning. They therefore don’t trump it, because they are (part of) it.

Said another way, what’s the difference between a SOAP envelope and a SOAP message? Answer; a SOAP message includes the envelope of any underlying application protocol, and with it, the meaning of that envelope.

My old friend Steve chimes in with a thought that seems aimed in my general direction, and therefore seems to reflect a misunderstanding of my position;

I don’t know of many (any?) pure systems that have significantly succeeded in the real world. If you’re taking a purity approach in this “SOAP vs. REST” debate, and you’ve convinced yourself that you absolutely and for sure know the right answer, regardless of which side you’re on, then you’re either much, much smarter than the rest of us, which is pretty unlikely, or you’re just choosing to ignore important parts of the big picture that don’t fit with your vision of purity. Either way, you’re not really helping yourself or anyone else.

Yes, agreed, purity should not be one’s principle goal. But it’s not my objective in promoting REST to require that everbody must always follow it. That would be quite silly. No, my objective is to encourage it be adopted as the defacto guide that one uses when setting out to build Internet scale, document oriented, services. Then, even if some constraints need relaxing because to not do so would prevent a requirement of the project from being met, you at least know what it’s costing you in terms of properties.

It’s that emphasized bit above that is my main concern. For whatever reason, SOA/WS proponents feel that, in trying to leverage Web infrastructure, they need to disregard the (arguably) single most important constraint of REST (the uniform interface) as a matter of course, rather than with any specific justification regarding the requirements of their project, just with – apparently – the general belief that you need service specific interfaces because DCOM and CORBA used them.

Update; Steve contacted me to say that his comments weren’t directed at me, which I suspected. But because of the ambiguous targetting of his message, I just wanted to set the record straight for anybody who thought he might have been talking about me.

Who’s the wise ass? “SOAP $14.73, REST: $2.30”
(link) [del.icio.us/distobj]

Currently, REST leads SOAP $15.71 to 8.45. P.S. I bought REST, Javascript, and IE (it seemed way undervalued)
(link) [del.icio.us/distobj]