March 30, 2007
Dave Thomas has posted a really good article entitled The RADAR Architecture: RESTful Application, Dumb-Ass Recipient. I can already see the RADAR books published by O'Reilly, Manning, Wrox, Apress and of course, The Pragmatic Programmers, on the shelves at Barnes & Noble. The concept is inspired by RESTful Rails, but proposes an alternate approach from the one currently used by Rails.
If you aren't familiar with RESTful Application Architecture, I'll try to give a brief crash course. The basic idea is that you treat everything in your application as a resource. Each resource has a few different URLs you use to view and edit the data. You use the HTTP methods has they were originally intended to indicate to the action you wish to take on the data.
According to the [Wikipedia article on HTTP], version 1.0 of the spec was released in May 1996, almost 11 years ago. For years, the developers of web browsers, and therefore by association, the developers of web applications, have completed ignore most of the HTTP methods that were included in the spec. We all know about GET and POST, GET is used to retrieve a document, and POST is used to send data to the server. But there were other methods that were in the spec, specifically PUT and DELETE. Sadly, some browsers (I don't know which ones do an don't) don't support PUT and DELETE, so therefore they cannot be used by HTML-browser-based web applications. But let's ignore HTML web browsers and just look at the spec for a minute.
(As a sidebar, somewhere there is someone who worked on the original HTTP spec screaming "it's 'bout time!". It's funny how sometimes in the world of technology, it takes years for people to start using a particular technology how it was originally intended, and when they finally do, it makes a big impact.)
If you think about it, a typical database driven, web application, it's really just a glorified database front-end. It allows end users to perform CRUD operations on data stored in the database. As it turns out, the original HTTP methods map nicely to the CRUD operations:
Create = POST Retrieve = GET Update = PUT Delete = DELETE
Most of the time, there are 2 variants of the retrieve operation. First is the list, where you see a list of all of the resources of a given type, and the second is details, where you see the details of a given resource. So, with that, you might have the following URLs associated with working with articles:
GET /articles => Retrieve a list of all articles GET /articles/1 => Retrieve the details for article "1" POST /articles => Create a new article PUT /articles/1 => Update article "1" DELETE /articles/1 => Delete article "1"
GET /articles => Retrieve a list of all articles GET /articles/1 => Retrieve an HTML page that displays article "1" GET /articles/new => Retrieve an HTML form to be used to create a new article POST /articles => Create a new article GET /articles/1;edit => Retrieve an HTML form to be used to update article "1" PUT /articles/1 => Update article "1" DELETE /articles/1 => Delete article "1"
Rails has a way to handle this, which is the use of the
respond_to method. Jamis Buck describes how to use respond_to to support multiple client formats in this article, but the summary is that if the client asks for XML, you give it XML, if the client asks for HTML, you give it HTML.
In Dave's article, he suggests an alternative architecture. You first build a pure REST application server, that isn't clutter with the extra methods required by HTML-based applications. Therefore it only responds to the original 5 HTTP method/URI combinations that I listed above. I would imagine you would still use this in conjunction with
respond_to in order to give the client the data in various formats, like XML, JSON, etc, but those would only be data formats, not formats like HTML that include visual elements. Then, you have a "proxy" server application, that receives HTTP requests from a dumb browser, retrieves the data from the REST application, then formats the data with HTML, and returns the HTML to the dumb browser. Then, when you create an RIA, it can talk directly to the REST application server.
You could implement this type of architecture without separate applications, one for the HTML-client proxy (a.k.a RADAR) and the one for the REST API. You could create a single application with separate layers to support the different client types. A common application architecture contains 3 layers, presentation, business logic, and persistence. The presentation layer could be the RADAR HTML-client proxy, and business logic could be the REST API, and the persistence layer could be your typical Data Access Object implementation, or in the case of Rails, ActiveRecord. If everything is in one server/cluster process, it actually would make more sense to have 2 different presentation layers, the RADAR layer and the REST API layer, and your business layer would be application code that each layer communicates with, that is modeled directly after the REST API.
This is just one of example of the interesting application design concepts that are coming out of the Rails community, and these are application design concepts that could be applied in any language/platform. Java developers who are turning a blind eye to Rails and application frameworks built in other languages are missing out on an opportunity to learn from these concepts.