Web Things, by Mark Baker

Now don’t get me wrong, I do appreciate the bevy of pro – or at least neutral – REST commentary in the recent discussion. But I just can’t get excited about the “moderate” conclusions such as this from Dare Obasanjo;

If you know the target platform of the consumers of your service is going to be .NET or some other platform with rich WS-* support then you should use SOAP/WSDL/WS-*. On the other hand, if you can’t guarantee the target platform of your customers then you should build a Plain Old XML over HTTP (POX/HTTP) or REST web service.

I mean, that looks fine and dandy – as did Don’s conclusions – until you realize that the architectural properties of the resulting system aren’t a factor in the decision.

Oops! This is not progress. This is not principled design.

Tags: soap, soa, rest, webservices.

If you’d have asked me six or seven years ago – when this whole Web services things was kicking off – how things were likely to go with them, I would have said – and indeed, have said many times since – that they would fail to see widespread use on the Internet, as their architecture is only suitable for use under a single adminstrator, i.e. behind a firewall. But if you’d asked me if I would have thought that there’d be this much trouble with basic interoperability of foundational specifications, I would have said, no, I wouldn’t expect that. I mean, despite the architectural shortcomings, the job of developing interoperable specifications, while obviously difficult, wouldn’t be any more difficult because of these shortcomings… would it?

I’ve given this a fair bit of thought recently and concluded that yes, those differences are important. What I don’t know though, is whether they’re important enough to cause the aforementioned WS interop problems. But here’s my working theory on why Web services interop is harder; you can decide for yourself how significant they are.

What I think this boils down to is that interoperability testing of Web based services (not Web services), like any Web deployment, benefits from network effects not available with Web services, primarily due to the use of the uniform interface. So if we’re testing out Web based services, and I write a test client, then that client can be used – as-is – to test all services. You simply don’t get this with Web services, at least past the point where you get the equivalent of the “unknown operation” fault. As a result, there’s a whole lot more testing going on, which should intuitively mean better interop.

Or at least that’s the theory. What do you think?

Update; based on some comments by others, I guess I should qualify this as stating that I understand that there are concrete reasons why bugs exist today. But what I’m talking about above is the meta question of why these bugs continue to persist, despite plenty of time passing in which they could have been resolved (modulo the vendor-interest comment by Steve & Patrick, which I don’t buy because there’s so much activity in SOAP extensions that lock-in at the SOAP level is unnecessary and moreover, shrinks the market by scaring potential customers away).

Tags: soap, rest, web, soa, networkeffects, testing, interoperability, webservices.