Web Things, by Mark Baker

Mark Little responds to an interesting post by Bill Burke about compensation based transactions. I don’t really have any direct response to the gist of that discussion, but wanted to highlight a couple of Mark’s arguments that I consider to be probably the top two arguments by those who feel there’s value in both the Web and Web services (the “fence sitters”, as Mark recalls me calling them 8-).

First up, the belief that the Web has nothing to say about reliability, transactions, etc… Mark writes;

Yes, we have interoperability on the WWW (ignoring the differences in HTML syntax and browsers). But we do not have interoperabilty for transactions, reliable messaging, workflow etc. That’s not to say we can’t do it: as I said before, we did manage to do REST+transactions in HP but it was in a small-scale deployment involving only a couple of partners. There is no technical impediment to doing this: it’s entirely political. It can be done, I just don’t see it ever being done. Until it happens, REST/HTTP cannot compete with the kinds of heterogeneous out-of-the-box interoperability that we have demonstrated with WS-*

I’ve talked about this a lot, most recently in my position paper to the W3C Workshop on Enterprise Services. The gist of the argument is that the Web address all of those needs, just in a way which you might not recognize because it has to address them within the confines of architectural constraints that Web services folks aren’t used to. Again, that’s not to say that every possible one of your needs can be met out of the box today, only that far more of them can than you might believe.

Mark also uses the very common argument that because interoperability requires agreement on data for both Web and Web services, that there’s no significant difference between them (I hope that summarizes his point);

So just because I decide to use REST and HTTP doesn’t mean I get instant portability and interoperability. Yes, I get interoperability at the low level, but it says nothing about interoperability at the payload.

I can’t quickly find any past blog entries that touch on this point (though I know they’re there), but this argument I find the most confusing. I suspect it has to do with what I perceive to be a disconnect between Internet and intranet protocol stacks, but I can’t say for sure.

What Mark calls the “low level” isn’t the low level at all. Assuming he means HTTP, the agreement you get by using it is more (higher level) agreement than you get if you were just using SOAP (or XML-RPC or IIOP or BEEP or …). That’s because you’re agreeing on the methods in addition to an envelope (not to mention many other features).

Seems like folks are excited about Roy’s upcoming ApacheCon talk.

The title – A little REST and Relaxation – is the same title as the keynote (video) he gave at Jazoon this summer, so I assume it’ll be similar if not the same (hopefully a bit longer, as Roy’s obviously rushed for time in the video).

I liked the talk a lot, as you might have guessed. I particularly liked how Roy echoed some of the things I’ve said the past few years nearly word for word. For example, he talked about how SOA was effectively the null architectural style. He also talked about the pros and cons of relaxing REST’s constraints, including the very high cost of relaxing the uniform interface constraint (something I’ve pointed out many times), but the relatively low cost of relaxing client/server.

Update; Pete reminds me that Roy used the Lego analogy, which I’ve used before too.

I think Google really missed the mark with its attempt at embeddable maps. I suppose something is better than nothing for the myriads of folks who want this functionality, but when a simpler, less opaque solution (read; declarative), GMapEZ, has existed for ages, you have to wonder what Google were thinking. The blob of HTML you get might as well be Javascript, or heck, even a Java applet in the sense that it’s opaque to all but the most inquisitive of developers.

This is becoming a bad trend.

Sanjiva uses the wrong word when pointing out distributed systems development is hard.

I thought that RESTafarians used to say that WS-* was all too complicated and REST is so easy and beautiful. ;-).

No RESTafarian I know ever said REST development (in general) was easy, only that it was simple, where “simple” refers both to the architectural property of simplicity induced by some of REST’s constraints as well as to the general notion that using any reasonably constraining architectural style reduces the number of decisions a user of that style has to make. “Easy” would mean that this second notion of “simple” implied that all the remaining choices were trivial, which is clearly not the case. Yes, distributed systems are hard. But their styles needn’t be complex.

I’ve posted the position paper I authored for the W3C/OpenAjax Workshop on Mobile Ajax. It’s all about the value of declarative application development, which I’ve discussed before.

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).

Eric Roch comments on a post from Anne Manes from a couple of months ago, and seems to be under some misconceptions about REST.

Misconception: “Stateless” means no persistent data

To be RESTful state must be transferred from the server with each interaction. This can be problematic for many applications – can you trust the other party to maintain state from a security and transactional perspective? For example, if the application keeps a running calculation of product costs – is it okay to transfer the calculated costs and trust the cost when it comes back in the state transfer? Some costing applications are complex and recalculating costs every time the user responses just to be RESTful might not make sense.

This is a very common misconception for REST newbies. What Eric’s doing there is confusing application state and resource state. REST’s stateless constraint only requires that application state be maintained on the client. It places no constraints on resource state, such as Eric’s “running total” above.

Obviously REST wouldn’t be very interesting if it were unable to support persistent data.

Misconception: REST doesn’t support dynamically generated content

Also, since you need unique URIs for caching, you cannot have one URI for a dynamically built page and be RESTful.

That one, I’ve never heard before 8-) It’s not true of course, because dereferencing a URI one day can return a different representation than it does the next day. That’s pretty fundamental to REST.

No wonder Eric’s been such a strong Web services supporter if he thinks REST can’t support changing data, nor persistent state! 8-O

Misconception: HTTP(S) can’t do what I need, so I can’t use REST

Then there are of course the constraints of the HTTP(S) transport […]

Sure, but they have nothing to do with REST. Just because HTTP(S) can’t address your needs, it doesn’t mean you have to abandon REST. You might consider an HTTP extension if you would otherwise be able to use it, but if HTTP is totally out of the question and you need a new protocol, you can still use REST’s constraints in designing that protocol. I’ve done that myself in fact, and designed a UDP based transfer protocol for use over satellite links.

Elias has noticed that my blog has fallen silent recently, and suggests that REST’s victory over WS-* has something to do with it.

He’s right.

I haven’t had much contract work the past few weeks, but have been helping a couple of startups. But the main reason I don’t blog is that my curmudgeonly style really only works when I’m the lone voice, arguing for the unpopular-but-superior solution. Now that the arguments I’ve been making for the past seven or so years are finally being recognized as superior, I’m sure I’d come off as just plain mean if I were to go after anybody who said that they were sticking by WS-* (something about kicking a horse when it’s down).

What comes next for me and this weblog then?

Something I considered doing a couple of years ago was a regular “Ask Mark” piece, where I’d publish one of the many REST/Web questions I get via email. I’d been answering those privately for years, but perhaps I could now do so on condition that I can publish them (though few are really interesting).

Another thought was covering REST/Web esoterica. There’s an abundance of interesting topics to cover on the fringes of REST and the Web. Yet another was a retrospective of some of the more heated battles over the past years, on weblogs and mailing lists.

Let me know what you’d like to see me cover.

BOSH is a specification that defines how XMPP can be used over HTTP. It’s obviously written by people who know what they’re talking about, because they’ve got good requirements, and get into great detail about the design choices they’ve made. Unfortunately, BOSH makes the one big mistake that so many others make; treating HTTP as a transport protocol. To wit;

POST /webclient HTTP/1.1
Host: httpcm.jabber.org
Accept-Encoding: gzip, deflate
Content-Type: text/xml; charset=utf-8
Content-Length: 188

<body rid='1249243562'
      sid='SomeSID'
      xmlns='http://jabber.org/protocol/httpbind'>
  <message to='contact@example.com'
           xmlns='jabber:client'>
    <body>I said "Hi!"</body>
  </message>

  <message to='friend@example.com'
           xmlns='jabber:client'>
    <body>I said "Hi!"</body>
  </message>
</body>

(you might also note that all of their example requests are POSTs to /webclient – a warning sign if ever there was one)

The intent of that message is to send two messages, one to each of the recipients at example.com. If we were treating HTTP as an application protocol, that would be done like this;

POST mailto:contact@example.com HTTP/1.1
Host: httpcm.jabber.org
Accept-Encoding: gzip, deflate
Content-Type: text/xml; charset=utf-8
Content-Length: nnn

<body rid='1249243562'
      sid='SomeSID'
      xmlns='http://jabber.org/protocol/httpbind'>
  <message xmlns='jabber:client'>
    <body>I said "Hi!"</body>
  </message>
<body>

POST mailto:friend@example.com HTTP/1.1
Host: httpcm.jabber.org
Accept-Encoding: gzip, deflate
Content-Type: text/xml; charset=utf-8
Content-Length: mmm

<body rid='1249243562'
      sid='SomeSID'
      xmlns='http://jabber.org/protocol/httpbind'>
  <message xmlns='jabber:client'>
    <body>I said "Hi!"</body>
  </message>
</body>

Alternately, if you don’t like proxies, the mailto URIs could be swapped out for an http URI specific to each mail address. But the point is that HTTP semantics be reused by recasting XMPP to them, rather than the current approach of grafting XMPP on top (read: obliterating). Don’t like two messages? Try pipelining them. Can’t pipeline? Does some other feature not map well onto HTTP in this way? Then it wasn’t meant to be.

We use HTTP (and the Web) because we want to be part of the Web; participate in the network effects, make information freely available (like, say, my presence status), etc.. We don’t do it because we need a way to get past firewalls. Good admins will avoid deploying software behind their firewall which subverts the intent of the firewall.

I’ve said it before, but apparently not enough as David Chappel chimes in with this;

A RESTful approach is a natural for data-oriented applications that focus on create/read/update/delete scenarios.

He’ll get no argument from me that REST is good for data-oriented applications, but saying that it’s only good for the subset that fit the CRUD model is wrong. It’s wrong because CRUD doesn’t have an equivalent for HTTP POST. Once you incorporate POST into your repertoire, then you can do all kinds of interesting things like, say, ordering stuff.

Perhaps David – or anybody else – could point me towards a data oriented application which can’t fit (well) into such a model (not REST, just the uniform interface part).