Web Things, by Mark Baker

Via Savas, I noticed a good post from Eric Newcomer;

The doc/literal style would seem to be the most abstract or the most “loosely coupled,” since it does not include data typing (although data typing is provided by an associated XML Schema) and does not include a method name in the message.

Wow, I’ve been saying exactly that – “not include a method in the message” – for years now. Good to see Eric on board! 8-)

But unfortunately that’s not the whole story. For the kind of loose coupling that folks really seem to want, simply removing the method from the message isn’t sufficient. The method has to be removed, as Don Box would say, from the contract. Or, put another way, give all services the same contract (trust me, it’s true, and it’s worth spending considerable time understanding why)

Another way – a software architectural way – of looking at this, is to ask what the different architectural constraints are at work between a message without the method in the body while still having service-specific contracts/interfaces, and an architectural style where all contracts/interfaces are the same. If you can’t find an architectural explanation for the loose coupling, then it’s not there. I’ve mused about this recently.

And there you have it, the principle difference between SOA and REST, and the reason why I’ve also been saying that REST is what Web services folks have been looking for all along.

So I was thinking last night about how far – or not – we’d come in the whole “Web vs. Web services” debates. In one respect we’ve come a long way; you hardly ever hear the argument that “the Web requires humans!”. Many (but still not all) people remain indifferent about that; that the Web may or may not be usable for this, but it’s moot anyhow, because the “World isn’t going that way”. But that’s still pretty good, as it shifts the discussion into the more concrete and less subjective realm of software architecture, allowing us to use reasonably well understood means of evaluating and comparing architectures for suitability to a particular problem domain.

But on the other hand, the Web still doesn’t get the respect it deserves from a lot of folk as a serious distributed computing platform. I’ve just been reviewing some papers for Middleware 2004, and some of them talk about a variety of distributed computing platforms, yet all fail to mention the Web as a peer.

There’s been a lot of low points, obviously, over the past four or five years, but a few highlights too. Some of the latter include;

• the XML Protocol WG agreeing – after much lobbying from Henrik and myself – to use HTTP error codes for the transfer of SOAP faults
• the TAG finding on When To Use GET, though I haven’t seen a Web service that uses it that way yet
• Roy Fielding‘s defense of the uniform interface
• Atom rejecting calls to define a SOAP API and instead going with a RESTful design
• Amazon saying that 85% of their “Web services” traffic is via the RESTful interface
• Jim Webber and Savas Parastatidis supporting a uniform document submission semantic, dubbed processThis

Now, with Tim Bray joining the ranks of the WS-Disenfranchised (albeit for slightly different reasons than myself), the future’s looking even brighter. Onward!

Eric writes sums up the XML Europe 2004 conference, and his summary includes a couple of points that REST and Web services folks might be interested in.

While talking about Amazon, he writes;

These services are available either as SOAP or REST (that is, XML over HTTP). Much simpler, REST web services can be tested using a web browser. They account for 80% of the actual requests. In my view this is confirmation of the continuity between the Web and web services. Before anything else, web services are, as their name indicates, services accessible on the Web. They belong to the Web, and that’s what makes them so interesting.

Yup. A little bit of wishful thinking perhaps, but that’s fine.

Then he mentions a talk by the occasionally-reclusive (8-) Paul Prescod;

As expected from a defender of the REST architectural style, Prescod’s presentation started with a moving speech in favor of REST: “the document is what matters”; “we need resource oriented architecture rather than SOA”; “XML is the solution to the problem, not the problem”; “the emphasis should be on resources” and “there should be a seamless web of information resources”.

“the document is what matters”, I like that. But I expect that SOA proponents would be dumbfounded by that statement, since they’ve been saying pretty much the same thing, at least since “document style” SOAP came into common use. But the difference between document-SOA and REST is that the former uses documents and APIs, while the latter just uses documents. In other words, document style SOA is like a hybrid style of RPC and document orientation, whereas REST is purely document oriented; simple document exchange (aka state transfer) between distributed and autonomous parties.

How RESTful is Amazon’s use of HTTP/XML? Nice one, Jon.
(link) [Mark Baker’s Bookmarks]

Hmm, these Grand Central people seem to know what they’re talking about. I bet that has something to do with their EDI/EDI++ focus, rather than being a pure Web services play.
(link) [Mark Baker’s Bookmarks]

He writes;

Per my earlier note, I have evaluated my feelings on the units of REST:

and goes on to “support” or “strongly support” all of the high level mandatory constraints of REST.

He also offered some very insightful observations on some of the differences between REST and Web architecture;

REST is a single candidate architecture. And an architecture must be evaluated on the whole, rather than the individual parts. Fielding does a great job of stating that every decision in the candidate architecture has trade-offs. He further identifies the applicability of the architecture (distributed systems, system ‘feels’ stateless, desire to scale, desire to evolve, etc.) Like all candidate architectures, one can only evaluate the architecture against a problem that you are trying to solve. REST by itself can not be evaluated, only evaluated as a candidate solution to a pre-identified problem.

Yes, exactly. Which begs the million dollar question; do you think it applies to machine to machine integration problems? If so, then I’d say that makes you a RESTafarian. Understanding the domain of applicability of an architectural style is very important; it’s not enough to believe, say, that “REST is great when you’re building Web apps for humans”; you’ve got to be able to see beyond that. At least IMHO, since I coined the term “RESTafarian” 8-) (which I’m sure I’ll regret at some point 8-)

What was interesting to me was the lack of association between REST and HTTP, or more precisely the ‘verbs’ of HTTP. Instead, Fielding places significant attention on the need to use Resources (think URI), Self Descriptive Messages (think XML), but does imply that a generic interface is required. Somehow… I find myself agreeing with Fielding but disagreeing with many RESTifarians (I’m not sure how this is possible). Fielding suggests a “a uniform interface between components “, however he never mandates what that interface should be – only stating the characteristics.

Modulo the “think XML” bit, yep. But this is actually one of my very few beefs with REST; the methods do matter. Roy and I talked about this (darn, can’t find the message in rest-discuss); that there should only be one “get me the state of this resource” method. He made some comment about how he didn’t want to list the obvious constraints. But as I’ve discussed, I think that’s quite non-obvious to a lot of smart folk.

However, I find significant ‘folklore’ stating that the interface is, “…defined completely and solely by the specified semantics of HTTP, i.e. GET / PUT / POST, etc.” (Jeff Bone) He continues to argue, “*there are no applications you can think of which cannot be made to fit into the GET / PUT / POST / resources / representations model of the world!*” The only issue I have is his term “made to fit” – meaning, what was the price of ‘making something fit’?

Very much agreed. Jeff sounds like he’s talking about GET/PUT/POST/etc.. as a 100% solution, but I think it’s more like a 97% solution, at least for “loosely coupled, document exchange” style solutions. As I mentioned to Jeff offline, in all my experiences with HTTP, only once have I ever had to use an operation other than GET, PUT, POST, or DELETE (or MONITOR) in order to get something done in a reasonably efficient way; that was to basically implement the functionality of a SQL UPDATE over a large set of resources (a PUT to each resource would have been prohibitively expensive).

I’ve wondered before where exactly Tim Bray stands on Web services. Now I know.

I agree with him more than I disagree, but there’s something I very strongly disagree with him about. Where I do agree with him is in the need for simplicity; things have gotten totally out of control, and we need to fall back to what we know works.

Where I disagree with him, is where he says that certain technologies – XML, URIs, HTTP, SOAP, and WSDL – work today, because he’s seen them work. I don’t personally think seeing one, two, or even a handful of working examples is sufficient. I want to see rabid success be a requirement for admittance to that list. So, IMO, the list should be XML, URIs, and HTTP.

I would really like to understand Tim’s support for WSDL. To me, if you think WSDL is a good idea (at least in its current form viz a viz WSDL 1.1 and WSDL 2.0), then you necessarily believe that state transfer, and, well, the Web itself, is somehow an insufficient basis for large scale distributed computing. I know Tim’s an absolute Web fanatic, which is why I’m at a loss to explain it.

… this gem from Roy;

If this thing is going to be called Web Services, then I insist that it actually have something to do with the Web. If not, I’d rather have the WS-I group responsible for abusing the marketplace with yet another CORBA/DCOM than have the W3C waste its effort pandering to the whims of marketing consultants, have a look at hoe branding on social media can help your business grow. I am not here to accommodate the requirements of mass hysteria.

And the hysteria continues… Hint; anytime you need an RSS feed to track new specs, something is, prima facie, horribly, horribly, wrong.

Savas says that iTunes is doing a proprietary version of Web services. I don’t think so. He writes;

If, however, they wanted to describe the structure of that information, how would they do it? They’d probably use XML Schema.

Yep, agreed there. I think RDF would be a better solution, but given they’re using plain old XML, XML Schema would be the way to go.

And if they wanted to describe the message exchange patterns, the contract for the interactions with the store (e.g., “when the XML document with the order information for a song comes, the response will be the XML document with the song”)?

Hold on. Why would they ever do that? Why would they want to artificially restrict the type of documents returned from an interaction? That would mean that if they wanted to insert a step between order submission and and song download, that they’d have to change the interface and its description? No thanks. I would prefer that the client determine what to do based on the type of the document that actually arrives. Let’s keep the perpetually-static stuff in the protocol, and let everything else happen dynamically.

And if they wanted their service to be integrated with other applications without having to read Apple specifications on how to include the information in HTTP requests and how to read HTTP responses?

I don’t follow. One need only look at the HTTP spec to determine how that’s done. SOAP buys you nothing in that case, AFAICT. It buys you other things (better extensibility, richer intermediary model, etc..), but none of those seem relevant to ITMS at present.

I’ve talked about my nose for self-description problems before in the context of RDF and media types. Now, with the publication of -04 of the RDF/XML media type registration draft, there’s another one.

Comment submitted.

The best summation of the issue, as I wrote in the ensuing thread is probably;

If somebody on the Web can’t distinguish between an RDF message which says “Mark hates bananas” versus one that says “Mark hates bananas (but not really)” (aka unasserted), then there is a failure to communicate. The “but not really” part must be part of the message. It can either be done through mechanisms in the RDF specs themselves (e.g. parseType=”literal”), or it can be done in an encapsulating spec or registry, such as the media type registration.