Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Has Web Style Worked?

Has Web Style Worked?

This item in japanese


In a recent posting, Jean-Jacques Dubray (JJ) reminds us that it is almost 7 years since Tim Bray predicated the end of SOA:

I did an interview and a podcast [...] and the question came up in both, and in the hallway talk too: “What do you think we should do about SOA?” Which weirdly, nobody had asked me before, and I could find only one answer: “Don’t do anything. ‘SOA’ may have meant something once but it’s just vendor bullshit now.”

Tim ended by stating (predicting) that rather than SOA being the future, Web Style was the future. As JJ mentions, that predicting opened the doors for many others to follow over the coming years, including the likes of Anne-Thomas Manes and others. One of the results was that many SOA projects were slowed or killed, with JJ having his own direct experience of the former:

My manager at the time told me that Tim Bray's post was circulating in our IT department and he didn't know where to start to craft an answer to his management. His team had built their own ESB at a time when hardly anyone had heard of XML and several years of hard work and constantly rising transaction volumes (a respectable 10 M requests/day at the time, in early 2007)  were now jeopardized by a single paragraph written by Tim Bray.

Well JJ has spent some considerable time over the years on InfoQ and elsewhere, talking about the problems that Web Style overlooks. In this recent article, he has also been taking a look at many of the services that purport to implement Web Style:

Out of 9000 APIs [in the Programmable Web's directory], my best estimate is that less than 1% are following Tim Bray's Web Style. They are all but following an "API" style, short of RPC.

And JJ gives some examples of what he means by this by considering what he believes is a representative sample:

  • Ask Ziggy which offers the ability (sic)  to define "actions" (such as Play, NextSong, Previous Song, Shuffle...)
  • WhatLanguage explains that you can use, as you wish, a GET (if your request is less than 7500 chars) or a POST to the same URI to detect the language of a given string
  • actually seem to be offering a Web Style API, but it does not do much, it is simply CRUDing 5 resources (tasks, project, users,...)
  • SkyBuffer is also following the Web Style, but just like, this is just some CRUD on a couple of entities
  • MaShape which is a "Cloud API hub" is very interesting because they offer a better way for developers to consumer APIs. How do they do that? They invite developers to "Learn how to describe your API on Mashape to autogenerate client libraries and documentation". Yes you heard right, after years of bashing, developers start talking about client library code generation.

 JJ thinks that the API approach is at odds with the pure Web Style that was being pushed by Tim et al:

Wasn't the Web Style all about the "Uniform Interface", Bookmarks and auto-magic HATEAOS? not to forget standard IANA types? Yes, you don't hear that kind of argument much these days. APIs rule. People are no longer ashamed to use a verb in their URLs or POST a (complex) query. Most importantly, MongoDB showed us that there is a lot more needed to CRUD than these 4 little verbs and an anemic URL syntax. Developers and Architects are so desperate to go around the "Web Style" that they even try to add namespaces to JSON.

When looking at these supposedly Web Style services, JJ comes to the conclusion that it has in fact failed to deliver on the hype and is in fact "dead". However, JJ goes even further than this, declaring the Web itself to be all but dead:

[...] between developers who can't figure out how to produce anything of value with HTML5 and compete with Native apps and end users finally getting cold at the wonderful idea of being "the product" central to the Web business model. Tim Berner-Lee which is coming out every six month with a "Long live the Web" message but after a wrath of security abuses, it seems that even a KBE can no longer save the Web.

Fortunately the article doesn't just leave us with a gloomy overview of the past and the "technical debt" that has wraught. JJ looks at where we are today and the influence of new waves such as mobile, which he believes represents possibly the biggest paradigm shift computing has ever seen:

Few people would remember, but software engineering was built on an old, very old paradigm of "file processing" which culminated with UFS. The desktop metaphor and the main usage patterns of PCs remained anchored in "file processing". Mobile is no longer about files, mobile terminals assist us in pretty much any activity we do. If nothing else, future operating systems will be activity centric.

However, he believes that we must also leave Web technologies behind in order to succeed:

The best user experience will win, anyone who has, is or will be betting against it will lose. The Web rose, because it too, once, provided a better user experience. It didn't rise because it was "the Web".

And finally, JJ states that we have to be far more pragmatic about how we approach problems and really learn from the past:

More CRUD is not going to cut it, even with an API as superbly designed as the MongoDB API. We also have to grow up an understand that, OO is the wrong paradigm to represent interactions between distributed components. Hence we have to stop reifying everything we do into stateless singleton method calls. Annotations on a class are simply too weak to drive the semantic revolution that SOA started and we now need to finish.

But even taking on board all of these changes that JJ suggests, what is the ultimate goal? Well JJ thinks it is a robust Composite Programming Model where the model and view are free from one another but still properly connected, following an activity/action/lifecycle paradigm. Unfortunately JJ doesn't go into a lot of detail in this article on that model, but perhaps the intent is to follow up with some related publications.

Rate this Article