Web Things, by Mark Baker

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.