One of the things that any good developer strives for in the development of a web application, or any application for that matter, is a well organized code-base with consistent use of patterns and naming conventions. This contributes a great deal to the overall maintainability of an application. However, maintaining a well defined organization and consistency to a code-base especially one that is being worked on by multiple developers is not an easy task. In web development, there have never been any widely accepted patterns for how to name models, controllers, and their action methods. Developers are often not sure when looking at a code-base where they should put a new action method and how that method should be named. If this is a problem that you’ve faced, RESTful development is definitely something that you should be interested in.

Recently, there has been a surge in popularity for a development pattern or technique known as RESTful development. Popular frameworks such as Ruby on Rails are fueling popularity of RESTful development. The creator of the Rails framework, David Heinemeier Hansson, is a great proponent of RESTful development. David introduced RESTful development to the Rails community in his RailsConf keynote address of 2006, titled A World of Resources. In that keynote, he challenged developers to embrace the constraints of RESTful development. With the release of version 2 of the Rails framework, RESTful development has become the standard way of creating a Rails application. So what is RESTful development and why are developers excited about it?

The term REST was coined by Roy Fielding in his Ph.D. dissertation. Roy Fielding was also one of the creators of the HTTP protocol. REST stands for Representational State Transfer. REST describes a method of architecting software built around the concept of resources. REST happens to be a very good fit for web application development. Although REST itself is not explicitly tied to the web or web application development, it is within the context of the web and web applications that we will discuss it. Within the REST architecture, requests from the browser use standard HTTP methods to manipulate the application’s resources. Most web developers are familiar with just two of the available HTTP methods, the GET and POST methods. However, the HTTP protocol defines eight methods, GET, POST, PUT, DELETE, HEAD, TRACE, OPTIONS, and CONNECT. REST is concerned with the first four of these methods, GET, POST, PUT, and DELETE. These are the methods that a RESTful web application will use to manipulate resources. REST happens to be a very good fit for database-backed web applications. In a database-backed web application, resources map well to models, which in turn map well to database tables.

In a traditional web application developed in a framework such as Rails, a request would specify an action and a resource to perform the action on. For example, the following is a common URL found in a Rails application:

http://www.myapp.com/book/show/5

This URL tells the Rails backend to use the show method of the book controller to display the book resource that has an id of 5. An application developed using REST would not specify the action in the URL. Instead the URL would specify only the resource. The action is determined by the HTTP method with which the request is submitted. For example, a RESTful equivalent of the above URL would be:

http://www.myapp.com/book/5

This request would be submitted using the HTTP GET method and routed to the correct method, show, based on having come from a GET request. Let’s expand on the example of manipulating a book resource and look at how you would perform other actions on a book resource using RESTful development. The table below shows how various actions performed on a resource are mapped to URLs and HTTP methods.

Notice that the URL for performing show, destroy, and update on a resource is identical. These requests are routed to the correct controller action based on the HTTP method that is used to submit them.

So the idea is that you would apply this pattern throughout your web application’s architecture. Every controller would consist of the same standard set of methods show, destroy, update, and create. The application framework will route to the correct method based on looking at both the URL and the HTTP method used for incoming requests. Suddenly, you have great consistency in your web applications. All of your controllers are implemented in the same style and contain the same set of methods. You may be thinking about now that it is not very likely that you can actually implement an entire web application using just resources with matched controllers and that small set of controller actions. You may find that you need a few additional controller methods, but you will be surprised at how far you can get by consistenly following this pattern. You will find that this architecture will also clean up your controller and model designs. It will become clearer based on what you need the web application to manipulate what the correct models/resources are for your application. Keep in mind as you develop that not every resource will necessarily be backed by a database table. You may have resources that are not persisted in the database, yet you still follow this same resource/model matched with a controller implementation pattern.

Some advantages of RESTful architecture

So what are some of the advantages that you get from using this RESTful development approach?

Well Defined Application Design - RESTful architectured defineds a standard way of implementing controllers and access to models in a web application. Applications that consistently follow this architecture will end up with a very clean, very maintainable, and easy to read and understand code base. Traditionally when you have a web development project that is worked on by several people maybe not all concurrently, each may bring his own style of how they use controllers, what names they give to controller methods, what they determine are models, etc. The RESTful approach will make it much easier for every developer that comes onto a project to maintain a very consistent implementation style and thus preserve a solid architecture across the application.

CRUD-based Controllers - controllers map 1-to-1 to each of your models. Each controller contains the code necessary to manipulate a specific model through standard CRUD methods, create, show, update, and destroy.

Clean URLs - Because URLs used in a RESTful appplication represent resources and not actions they are less verbose and always follow a consistent format of a controller followed by the id of a resource to manipulate.

One of the advantages listed above, Well Defined Application Design, brings to mind an excellent quote made by Jonas Nicklas on the Rails mailing list and repeated in The Rails Way which is this: ”Before REST came I (and pretty much everyone else) never really knew where to put stuff.” With a RESTful architecture, you know where to put your code. Every application that implements a RESTful architecture will have a consistent design and developers will know exactly where to put code.

REST as a Web Service architecture

While REST is an excellent fit for database-backed web applications, some would say it is even a stronger fit for web services. The REST architecture provides an excellent platform for providing services. Afterall, web services are essentially APIs that let you manipulate some form of resource. Rather than create another layer on top of HTTP, such as the SOAP web service protocol does, REST based web services rely on the existing functionality of HTTP to provide web services. Because REST uses what is already built-in to HTTP rather than layering another semantic layer on top of it as SOAP does, REST is a much simpler architecture for implementing web services. The most popular consumer facing web services such as those provided by Amazon, Google, Yahoo, and others all offer a REST based interface. REST is more popular than SOAP today for implementing commercial web services. For example, considering the book example again, you could easily imagine a web service API that used URLs identical to that which a browser uses to get HTML content. This gets into the next topic of interest related to REST, that of Representation.

REST and Representations

When you request a page using a RESTful architecture, the page that is returned can be considered a representation of the resource that you are requesting. However, think of an HTML page as just one possible representation of any given resource. Other representations might include an XML document, a text document, or a block of JSON encoded JavaScript. Using the RESTful architecture, you would request a different representation of a resource using the same method, but by passing a different piece of metadata to the server indicating the representation that you would like to have returned. For example the following two requests would both be routed to the same controller and action method:

http://www.myapp.com/book/5

http://www.myapp.com/book/5.xml

The first request would return an HTML representation of the book resource. The second request would return an XML representation of the book resource. This is another advantage of a RESTful architecture. The same controllers and actions can be used to deliver a variety of response representations, think HTML, RSS, XML, etc. This makes implementing web services in a RESTful architecture extremely easy, and again maintains a consistent design style.

So, that about wraps up my overview of RESTful development. Hopefully you’ve been able to learn from it.

Read the original blog entry...