acroyear | Replaced by REST

The End Of The Road For Web Services - Simon Says...:

Once all the smoke had been cleared from the mirrors by the hand-waving and hot air, it became obvious to most thinking technologists that attempting to implement CORBA on the internet was even worse than implementing it on a private network. Despite cries of protest even now at that description that's essentially what WS-I was all about.

Before too long the lightweight, stateless, web-inspired approach documented by Roy Fielding in his doctoral thesis and named REST at his suggestion became the norm for internet use, and once we had JSON too, the outcome was inevitable. All the work of WS-I was clearly doomed to lead a webless existence as part of the complexity big vendors encourage their corporate customers to use internally, ironically leading them to be locked-in to the tools the vendors supply to mitigate the complexity.

It took many, many years for that doom to be made reality. In the course of a decade of corporate politics in smoke-filled rooms, many fine and talented corporate standards engineers have spent countless hours perfecting a set of specifications that are expertly crafted and logically complete. Fine work, and many lessons learned, but sadly irrelevant to most of us. Goodbye, WS-I. I know and respect many of your participants, but I won't mourn your passing.

New directions in web architecture. Again. - O'Reilly Radar:

Important as Ajax and REST have been to the history of the web, each only represents half of a larger revolution. And in the past few months, we've seen some new sites that have taken the revolution to its logical conclusion. Specifically: take a look at the new Twitter. It's a nice web application, sure -- but look at the HTML. There's not much there. The HTML page you get from Twitter is largely a bunch of empty divs, with a big wad of JavaScript. What's happening? The JavaScript is the entire application; the divs exist only to provide tags so the JavaScript can rewrite the DOM at will. In turn, the JavaScript is constantly (and asynchronously) making requests from the Twitter site, which is just returning data from its API. In fact, the Twitter site is returning the same data for its web page that it would return for its mobile app, for TweetDeck, or for any of the apps in the Twitter ecosystem.

This design isn't particularly new; we've seen it ever since developers started reverse-engineering GMail and Google Maps to get ideas for their own projects. Those big Google apps may have been the first examples of this architectural trend. They were certainly among the first to use JavaScript as a full-fledge client programming language. But we're seeing many more sites built along these lines.

This latter style of app, all javascript and minimal HTML, processed by a fancy framework like SproutCore (in my case) or Sencha, talking to a RESTful server throwing JSON back at it, is what I'm doing now. And that server could be anything - .NET, J2EE, Ruby, PHP, or some simple layer built directly into the database, or even entirely self-contained SQLite layers that talk to the new HTML5 datastore in your (upcoming or mobile) browser.

Throw in a wrapper framework like PhoneGap, and you can take that very complex web application and turn it into a "native" app for an iPhone, iPad, or Android-based device (Windows Mobile coming soon) with minimal effort.