Last night, talented RedMonk Analyst, Michael Coté posted a write up covering Microsoft’s Astoria project including this tidbit:

“The whole point of Astoria for me is to be a thin, REST-y data-layer on-top of the cloud. The web is The Cloud, of course.”

And, this one:

“Think something like Amazon S3, but with semantics layered on-top.”

Yes! Yes! And, did I mention YES? This idea of a “REST-y data-layer on top of the cloud” is the foundation of Actionatr (although without any Microsoft in the stack). Months of experimentation and research have gone into what is now being solidified in code. Actionatr is a platform that just happens to have a web interface and a Mac interface, but this is really just the beginning.

REST is the new SQL. Sort of.

The Microsoft take on this is to build a tool that plugs into a regular SQL data store, but what I would like to get at are the possible business models that could be built on top of such a thing. In the course of building Actionatr, I was thinking about how we could bake a REST interface into MySQL, but given that authentication and some amount of other configuration would need to take place, more would be needed. I looked at using the newly 1.0 Restlet API to create a fast, configurable, auto-inspecting layer that could be dropped onto any good data model as an easily scalable data layer for RIAs, legacy web apps, desktop apps or a blend of these. Rather than over-engineering my way to permanent vaporware, I decided to just use Rails as a temporary REST-only back end (i.e no HTML interface) and leave the fast, fancy, compiled SQL-to-REST framework for later (as it would not have an immediate benefit for Actiontastic/Actionatr users).

Let’s step back for a moment to trace this evolution. After digging into Fielding’s dissertation that introduced the REST (REpresentational State Transfer) concept and thinking about ways to scale and optimize such an architecture, I came to see the HTTP transport mechanism as one big hash pipe plus four simple operations, mysteriously resembling CRUD and SQL. A hash contains key/value pairs. When a URI is the key and the data is the value (be it an XML representation, JSON, or anything else), the added HTTP request semantics of GET, PUT, POST, and DELETE give us enough information to build naive caching mechanisms at any level of a given architecture.

Getting Clean by Taking Off Your ;close

With this in mind, it is important to note that adding “extra” methods on top of these standards might be harmful if you want to scale. As one concrete example, I added a “;close” method to an existing set of methods for Action resources. Oops. The problem with such a thing is that it destroys the ability to insert these naive caching mechanisms into the middle of an architecture. The caches would have to incorporate new business logic to understand how data inside an Action resource would change after seeing a “;close” request come across the wire. Adding such a thing into what started as a clean hash lookup optimization problem would degrade performance and add complexity for all future model/resource changes.

Thus, solid RESTful design goes beyond mashups and hype. Clean RESTful design allows easier scaling by specifying the complete state for all PUT and POST operations. Subsequent GET operations no longer have to make it back to your core application; they can simply bounce off a lightning fast cache. For that matter, GETs could be partitioned, other operations could be queued and batched, etc., but that is a research area unto itself and beyond the scope of this post.

Domain-Specific RESTful Hosting

So, once you’ve got a clean REST concept going, it is only a small step forward to imagine SaaS (software as a service) models on top of this. What if, oh I don’t know, say Actionatr, pulled all of the standard elements together into a nice API, put it in the cloud, provided hosting for some dirt cheap price, and thus enabled ubiquitous checkboxes for its users regardless of OS or device? What if anyone could use this service, including developers of other productivity apps?

Beyond this, what would other standardized SaaS models look like? How about contact management? Or blogging? Or calendaring? Maybe these models would contain more elements than a good user interface should support (Actiontastic is an example of minimalism in this regard), but that wouldn’t mean that the larger master data models wouldn’t be useful. It might be more like a grab bag than an all-or-nothing approach.

Either way, one could imagine a business model based on domain-specific data hosting. The extra benefit that this would have over a more generic approach like Astoria is that a community could evolve around this domain-specific data in a way similar to the process for building microformats. So, the model could be versioned and improved over time based on collective feedback from many different application providers. In the end, this could be built on top of an Astoria-like framework but it could begin right now, before the abstraction of a framework has to occur. (Anyone want to build such a thing based on database metadata, Restlets and EC2 with me?)

Server Side Rendering is the New Legacy

Taking all of this one step further, consider the so-called “modern” web app. After creating these things for somewhere around a decade, the hackish nature of building interaction models on top of a “page viewing” legacy (bookmarks, back buttons, etc.) is starting to smell kind of funny. It’s not that HTML doesn’t serve its own purpose very well, buy why can’t we just use this HTTP-as-hash-pipe model to build ubiquitous data services and leave the application interfaces to rich clients like the soon-to-be-open-sourced Flex?