Web Things, by Mark Baker

Here’s a telling statement for you, from a BEA press release;

Recognizing that every integration project requires development, and every development project requires integration

This is absolutely wrong; every integration project does not require development.

This afternoon I subscribed to (i.e. integrated into my existing aggregate feed) a few more weblogs, and did it without any new coding. This is because I already use some software which can snarf RSS feeds for me; I just had to identify the feeds for it.

Of course, if you assume, as BEA does, that each new service has a different interface than other services, then obviously new development is going to be required, just as if each RSS feed had its own interface. But that need not be the case, as I’ve demonstrated.

I know, I’m not being entirely fair; even if some new Web resource used the HTTP interface, but used a data format the client wasn’t familiar with, then more coding would need to be done. Which is why I’m so keen on RDF.

Jorgen Thelin references Bill de h&#211ra’s blog on session state.

Unsurprisingly, it appears there’s some serious misconceptions about state going on here. As Ken Arnold said, “State is Hell”, which jives with my experiences.

Bill writes;

One issue with the REST hypertext model is its view on managing state. REST constrains that state reside on the client, However the real web works precisely backwards to this: all interesting state is kept on the server, as sessions.

That second sentence is incorrect. Even cookie based Web apps still keep most application state on the client. If they didn’t, you wouldn’t be downloading web pages. The only architectural style I know of that keeps all state server-side is the Remote Session style, ala VNC.

And when exprienced enterprise practitioners like Martin Fowler say that state belongs on the server, it makes you wonder whether REST has anything to offer here.

I’d have to see a reference. I’d be very surprised if Martin said this in the way you’re implying he meant.

Then Jorgen writes;

[…] my hunch is that REST can’t provide a clean solution to the general category of “conversation” style applications (involving server-controlled request state transitions) which is the more usual meaning of the concept of “session state”.

I’m a fuzzy on what Jorgen means by “server-controlled request state transitions”, but I know that REST can handle what’s commonly called “session state” quite well. Moreover, even HTTP can handle it, without any extensions or use of cookies. All that’s needed is a client side implementation which manages state better. For example, rather than implementing “shopping carts” as a server-side container resource for shopping items, implement it as a generic client-side container, where the shopping/checking behaviour is a result of POSTing a representation of that client-side container to a checkout processor on the server. This generic client-side container would be useful for holding any application state, and therefore anything you’d want to do as a session.

There’s all kinds of pros and cons to this of course, as there is with any solution developed within the bounds of any architectural style, but REST can do it without batting an eyelash.

Edwin Khodabakchian reports on an Adam Bosworth presention entitled The Next Inflection Point.

Adam’s an extremely bright guy, and I’m fully expecting him to have a “REST epiphany” ahead of most others due to both the depth and bredth of his experiences. But while this is an extremely interesting presentation, there are some claims that just don’t synch up with the current approach taken with Web services. In particular, there’s this quote which Edwin pointed out;

We will look back in wonder and ask how we ever survived in the current anarchy where information did not flow as seamlessly and as metered and managed a manner between programs as electricity flows between devices today.

Whether or not you agree that Web services are the next big thing, I would expect that most people would see the problems in this statement; data flow with Web services is anything but seamless.

“Seamless data flow” derives from a data flow architectural style in which components expose a common (no, not necessarily uniform 8-) interface. The example I’ve used before is pipe-and-filter, ala Unix, with stdout/stdin. Non-common (i.e. component-specific) interfaces are notoriously difficult to compose, and therefore anything but seamless, because new glue code has to be written for each set of components that need to be composed (the old integration-complexity argument, O(N^2) or O(NlogN) for Web services vs. O(N) for the Web).

So I’m all for seamless data flow, but Web services simply don’t have it.

Simon responds to my comment about ERH’s message;

Does that alienate people? Yes! It should. I’d love to get the Web Services folks to rethink their foundations. Failing that, making clear that there are serious points of friction seems like the best course of action – and being civil has little to contribute to that. Forking is not a risk here – it’s an opportunity.

We’re in complete agreement about that. Where we may differ, is about the timing; I think the time for alienation has passed. I’ve personally been doing it for over three years now, and have alienated my fair share of bright and well respected people (which has come back to haunt me during my search for work, sigh .. but such is the price of grokking this stuff). I believe the time is right – or at least fast approaching – to take advantage of the increasing frustration being felt by some Web services developers who have realized that there may be something to this other way of doing things that they’ve heard about.

But, I could be wrong, which would be fine by me; it’s a lot less work to alienate. 8-)

Clemens Vasters writes;

I am sorry to say that, but if today you still believe and insist that XML is just another data format, the train may already have left the station for you.

Well, then I guess my train is long gone. Ouch. Sorry Clemens, but XML is just a data format. Now, good data formats like XML are nothing to sneeze at, and I’m glad we have it, just like I’m glad we have/had ASCII. But for heaven’s sake, it’s just syntax, a context free grammar.

He also stated;

One of the core messages of my talk is that the XML InfoSet is the focus of integration.

IMO, this is like saying C structs are the focus of integration. Ok, so you and I agree on what one is, and perhaps even how its represented. Now what? How do we integrate? We can’t, at least with just that shared knowledge. If we also shared a model for how to identify, exchange, and manipulate them, then that could form a focus for integration. Which is, of course, akin to what REST tries to do around a more general abstraction called a resource.

ERH writes (grr, no permalinks);

It’s interesting that the Web Services community has managed to alienate three different communities for three different reasons that all derive from not understanding or accepting the basic principles of the technologies they’re building on. They’re either geniuses or idiots. My money’s on idiots, but time will tell.

He’s certainly right in the first part, that these groups have been alienated; “XML” because of the subsetting and arguably the suitability for the task, “Security” because of tunneling, and “Web/HTTP” because it has nothing to do with how the Web works and generated its value in the first place.

But the “idiots” comment is totally out of line. People have suggested in the past that I’ve suggested they are idiots during my evangelizing of a REST based approach to Web services, which really hurts, though it’s certainly understandable; nobody likes to be told that they don’t understand something. But that’s all that’s going on here; they don’t currently understand. It’s absolutely not a statement about anybody’s capacity, or lack thereof, to learn.

I also wouldn’t call anybody an idiot who was proceeding based on their best current understanding of how distributed systems are built, when that understanding is built from years of hard-learned experience. Unfortunately, practically every Web services proponent I know, gathered their experience in a LAN environment, which is a very different place than the Internet, requiring very different solutions. I’d just call them people who need to broaden their horizons.

So please folks, try to keep it civil. Comments such as this one only serve to alienate, which is the last thing we need.

Scott Lawrence joins the ranks of HTTP gurus looking for work. If you need somebody who understands HTTP (not sure if he groks REST though), you couldn’t do much better than Scott.

I just sent this message (with this followup) to the Web Services Description WG to try and get first class support for application protocols (rather than requiring that they be treated as transport protocols) into WSDL. Let’s see how that goes.

Sean McGrath with another fine article about REST.

I had also been using the grammatical metaphor recently in some off-line discussions, to try and explain visibility. The one interesting nugget that emerged from that exercise, was that application protocol headers are adverbs, as they modify the verb (method). So a GET with an If-Modified-Since header, is a “conditional GET”, but – and to tie this back to visibility – it’s still a GET, the same way that “eat quickly” still describes the action of eating, whether or not you know what “quickly” means.

Yes, it’s a slow news day. 8-)

Like many other discussions (though perhaps much faster than most 8-), Simon gets to the heart of the matter;

[…] but at that level so is SOAP, its always HTTP POSTs[…]

While trying not to sound too much like a broken record, there is just one “level” here, the application layer; HTTP methods are application methods. POST is as much an application method as doSearch(). When you use HTTP/REST, you as a developer aren’t normally defining any methods, you’re just filling in the arguments to the methods that HTTP provides. That’s what “interface” in the uniform interface constraint is referring to; the API.