Rails 1.2 was recently released, and I've been updating and upgrading Pikaplanner to take advantage of some of the new features in 1.2.

The highlight of Rails 1.2 is built-in REST support, and I've been updating my controllers to provide what amounts to a standard, easy-to use, web-services API.

My first step in the process was to work through some of the examples in Rob Orsini's terrific developer volume Rails Cookbook. Diego Scataglini's examples in Rob's book provide a simple and quick intro to REST support in Rails 1.2.

REST is a great example of Clayton Christensen's concept of a disruptive technology. I've worked with SOAP and RPC in the past, and at first blush REST is less powerful than either. Still, with Rails, REST is easy and cheap to adopt at the service-provider end, and easy to experiment with at the receiver end.

For example, one of the first code areas I worked through was a simple product listing. The goal here is to provide both a web (HTML) and web services (XML) interface to our (sample) product information.

The REST support in Rails makes it easy, and all we need to do to turn our web pages into a web-services interface is tell (though the URL) our application that we want XML (instead of HTML) back.

So: to see the web page listing our products, we'd use "/products", as shown below:

So far, so good, so common—in Rails we've called up pages like this in the ":controller/:action/:id" form (that defaults to a GET on index.html here) zillions of times. What's new, with REST and Rails 1.2, is that all we have to do to have a web services interface is tell the application we want XML back, instead of HTML. So our URL is of the form ":controller/:action/:id.xml", as shown below:

and as you can see we get XML back - a web services interface practically for free (developer time-wise).

There is a lot of magic underlying this simple example, but a handful of key points stand out:

1) All we need for our "web services" interface is to tell our controller we want XML back.

2) We could have gotten JavaScript back (where that is appropriate) in the same manner

3) The key shift in development mindset is that the interface is not imperative (as SOAP and most web services are) but declarative—everything important in the system a) has its own URL for CRUD access, b) exists as a stateless resource, in which complex actions can be created by changes in state of one resource triggering actions to change the state of other, related resources, and 3) is capable of varying the format of responses, depending on what is requested.

That third point is a mouthful, and the core of stuff on which theses have been written.

Declarative programming is a significant mind-shift, one I'll be writing more about in the future.

Back in hazy Los Angeles, hair had grown dangerously high. In the wake of MTV's timely discovery of heavy metal, the City of Angeles sent out a casting call for multiplatinum blondes and abusers of hair products of all kinds....To anyone with rock-star dreams the smog of second-hand cigarette smoke and hair spray was an enchanting mist.—Heavy Metal

All booms are sociologically the same - stemming from a core belief that "the xxx (fill in your new new thing here) changes everything. That was 1984, but the scene was repeating in 1994 up north in Silicon Valley. Microsoft was still riding Windows 3.1, with the release of W95 still imminently a year away. Oracle was making big money again, with a successful Oracle 7 DB release, and some momentum on the applications side. SAP was rising to rule the business apps world, with a tailwind from Y2K fears, and strong pull on the delivery side from the consulting world.

Little did any of them know that the hottest action was off in the cornfields of Champaign, IL. By now the Children of the Corn (Andreesen, et. al) are famous and rich, but back then they rose to fame on the realization that computers don't "think" (any more than, as Edsgar Dijkstra dryly noted, submarines "swim"). They may compute, but MSFT and ORCL had the business sewn up. What they didn't do yet was communicate, and the CotC took Tim Berners Lee's collaborative innovation and gave it a universal front end.

By 1994 the early wave were downloading prototype browsers, and pointing them at the "World Wide Web" to see if anything was there. There wasn't that much out there yet, and there was almost no ability to find anything, but the promise was real. This was the age ad-hoc tools and services, most of which were to be evolutionary dead-ends that couldn't answer the question "how can we make money at this and scale it?"

Netscape answered the question by lopping the first half off of it, and answering the rest. If software was all about scale, then Netscape was all about scale, with VC funding solving the money problem, and the web itself solving the distribution problem.

The Netscape IPO on August 9, 1995 marked the point of departure - 18 months from inception to IPO, a $2B market cap, all without a clear revenue model! Scale and standards-invention/control were the keys to software wealth, and Netscape had a lock on them for this new "web" thing.

The "new new thing" in software was off and running.

My son Bryan has hockey games today and tomorrow, and I get to be game reporter and web scribe for them, as I've been all season. They play; I watch and write up game summaries for the web.

This is the state of the user web experience as we enter 2007. All I have to do is write and press a button, and presto - the whole world can read the game summary (my breathless prose can be found here). Anyone can do it, and lots of "anyones" are.

Anyone today can "write" for the web without having to "program" for the web—the web experience isn't about programming anymore. Dvorak is right: Microsoft FrontPage (the first webbing tool I ever used) is dead, and blogging has killed it.

The King is dead! Long live the BLOG.