Web Things, by Mark Baker

I’ve had a couple of conversations recently – one online and one off – that both centered around an important aspect of distributed computing that is often overlooked: the role of users in determining message semantics. When we write and deploy software, either client or server, it is easily forgotten that this software has been deployed on behalf of some user, either us, our employer, a customer, etc.. For example, Web browsers act on behalf of the users sitting right in front of them, while Web servers act on behalf of the publishers. We even have a special name for this software – though only typically used to refer to clients – user agents. The name drives home the point that they do our bidding alone. When a user initiates an action which requires messages to be sent, then the message needs to reflect the intent of the user. For example (the subject of the aforementioned online discussion) when a user clicks a link in a browser it is with the intent of dereferencing that link, an action which is by definition safe. Therefore, any message sent as a result of a clicked link must be a safe message, otherwise it would be misrepresenting the user. Another scenario where this issue pops up is in the context of application/session state. My friend Bob Haugen and I recently discussed whether the canonical Web shopping cart was stateful or stateless. After a few back-and-forths, we had boiled down the discussion – I thought it was stateful, Bob wasn’t sure – to this same issue. Bob thought that the POST message that gets sent in response to a “purchase” action by the user had the meaning “Purchase what’s in that shopping cart”. And if that was the case, he’d be right, it would be stateless. But my point was that the message can’t mean that because pretty much every user wants to be explicit about what they’re purchasing, and so include the details about the purchase – items, quantity, price, shipping terms, etc.. – in the message sent to the server. In explaining my position, I pointed out that pretty much every shopping cart service I’ve ever used notifies users if prices changes between the time the item was added to the shopping cart, and when the purchase is initiated. This is done because the service understands that it is the user’s intent to be specific about what they’re buying, it’s just that the technology in use – a Web browser – doesn’t easily permit that kind of information to be maintained on the client so that it can be sent over in the POST message. Food for thought, I hope.

While reading the comments in Steve’s initial ESB post, I spotted a paragraph that nailed the elephant-in-the-room meta issue on the head;

Its funny but so few people who also use ESB and WS-* style protocols and tools frequently operate with such disdain for other ways of doing things.

There are, of course, a very large number of automated solutions to a particular problem. But of all of them, only a few will exhibit the desired properties, to the proper degree, that you require for the environment in which it is to be deployed. The more you require, the fewer the number of suitable solutions.

IMO, if you don’t feel disdain towards a lot (97%?) of these solutions, then you simply don’t understand what it means to be a software architect.

I have to say, I’m with James in his response to Sam’s long bets;

To say, as Sam and Tim both do, that REST is important is like saying the fan in my laptop is “important”. There’s really nothing to discuss about it. RESTful services are fundamentally critical to the continued evolution of the Web. It just is. You just need to do things in a RESTful way. Period.

REST is just a starting point. What’s more important going forward is the framework which permits us to reason about REST extensions and other changes to the Web (or portions thereof).

Stu Charlton responds to my comment (and Mark’s) about how Pat Helland did things the hard way in discovering REST in a recent paper of his;

So, while the two Marks are suggesting Pat’s reached REST the hard way, I would suggest this is something he’s been saying for years, […]

That is the hard way! 8-O If Pat’s been unknowingly preaching REST constraints for years, then he’s done it from scratch. That’s a great personal accomplishment of course; I wish I were that smart. But wouldn’t it have been great if he had noticed that what he was talking about was being built out right under his nose for the past 15 years? 8-) I don’t fault him for that any more than I fault the bulk of the industry for also missing it (which is to say, a tiny bit 8-).

Anyhow, hopefully this paper can be the catalyst that helps push the industry towards a better understanding of the power and value of the Web. Of course, it also brings a new perspective to bear on the Web itself, from a seasoned distributed computing veteran, so that can only help Web proponents, perhaps motivating new Web based solutions. At the very least, they’ve got me thinking, which is always good 8-)

Eric, any chance we could get Pat to the workshop?

… is the title of a new blog post by yours truly on my consultancy’s weblog.

Paul writes that innovation in the browser ain’t dead yet. I agree. From a distributed systems POV, I think there’s two important things that need to happen to the browser, in addition to the richer languages that Paul talks about (and don’t forget about RDF and OWL!);

• making the browser a peer
• allowing the browser to own application state

The former deals with integrating a Web server into the Web browser, enabling the “Two Way Web”, like KnowNow and Idokorro (my company) do.

The latter, related to the former, suggests that cookies can be replaced by purely client-side application state. What this would look like, is that you’d drag-and-drop items from a browser window into a desktop-located container – for example, a shopping basket – and then to check out, you drag the container back to the page. This keeps the session state – the basket – on the client, per REST’s Stateless constraint. This would require an extension to HTML/XHTML to support draggable objects, as well as a means to support file upload via a drop action (i.e. targetted at some element on the page).