What is RESTful Development?

Posted by Timothy Fisher Wed, 06 Feb 2008 03:10:00 GMT

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.

Tags architecture, programming, rails, rest, restful, web | 3 comments

The Java Phrasebook as a Teaching Tool

Posted by Timothy Fisher Sat, 02 Feb 2008 23:30:00 GMT

Tags education, java, phrasebook, programming | no comments

Programming Languages : Use the best tool for the job

Posted by Timothy Fisher Mon, 21 Jan 2008 16:58:00 GMT

Over the weekend I finished reading the book The Rails Way. I actually enjoyed this book so much that I took the time to read it cover to cover. As good as this book was, it is not specifically the topic of this post. The last chapter of the book contains a series of statements by a bunch of developers who have grown to love Rails. They explain what it is they like about Rails. Each of the statements is interesting, some more so than others. One of the very last statements, written by Nola Stowe, talks about the lack of community across languages and using the right tool for the job. This is what I want to talk about with this post.

Developers who speak extremely highly of a single language while criticizing other languages are being very closed-minded and are shutting themselves off to some great learning opportunities. Once you’ve mastered any given language, and even before you’ve mastered a language, one of the best ways to continue to grow your expertise of that language is to learn and study a new language. You may look at how something is done in a different language and that may inspire you to rethink how you are doing things in the language that you love. The Ruby on Rails framework is a great example of how implementation ideas in one language can influence many other languages. The Rails framework is one of the most innovative web applications to come along in any language. Rails introduced a simple way of building web applications using DSLs, convention over configuration, code generators, and a robust object relational mapping layer. Much of the core architecture of Rails has since been implemented in almost every other language that is used to build web applications. Frameworks in other languages such as Grails, Cake, Django and others all have borrowed ideas from Rails. Also, this borrowing of ideas is not a one way street. Rails was not designed in a vacuum either. While it is true that Rails did alot of new things, it too borrowed ideas from other frameworks and languages.

Consider PHP, this is a language that is routinely criticized as a language that creates some really awful applications that are full of spaghetti code. Is this the fault of the language? Of course not. PHP brought web application development to the masses and I’d venture to say that those developers that create spaghetti code applications with PHP would do no better in a different language. PHP5 actually introduced a pretty good object implemenation to the language and a good developer can write very good applications in PHP, just as a good developer can write good application ins Ruby, Java, or C#. Are there things that a Java developer can learn from PHP? I think so. I believe that each and every new language learned can teach you something.

Too often when you look for language comparisons you come across alot of articles, posts, and other content that praises one language and attacks other languages. If your a Ruby or Railis developer, you’ve probablyl seen the photo of the stack of books that someone put online a couple years ago. The photo shows a large stack of Java books sitting next to a stack of two Ruby and Rails books. The idea behind the photo being that Java is so complicated it requires tens of books to fully understand, while with Ruby and Rails you can get all you need with 2 books. Such a picture wouldn’t fare so well today. I’d venture to say that today Ruby and Rails related books are coming out at an equal or faster pace than Java books. Having alot of books out about a language and its various frameworks and libraries is in my opinion a positive thing. Java has a huge open source following and there are libraries available for Java that do almost everything you want. Having books available about these frameworks and libraries is not a bad thing and does not in and of itself make developing with the language more complex. With the surge in popularity that Rails brought to Ruby, the libraries are gettin better for Ruby but they still can not compare with what Java offers. In a similar vein, more recently there have been a series of videos that promote Ruby while mocking another language. These types of language hype may be entertaining but they are detrimental to the software development community at large in that they usually only breed more distrust and negative feelings across specific language communities. I believe that anything that discourages a young developer from learning a new language is a bad thing.

In the enterprise consulting world, you often hear that comment that such and such company is a Java shop, or a .Net shop, meaning that everything they do is in that language. I think that being characterized as a Java shop or a .Net shop, or a Ruby shop is not something a company should be proud of. For example, Rails has shown tremendous productivity improvements over other languages when developing database-backed web applications. A company that traditionally builds all of their applications in Java or .Net would be foolish to simply ignore this fact because they are a Java shop or a .Net shop. Similarly, Ruby is one of the coolest languages to be using right now. It has a dynamic and rapidly growing community, and the hottest framework on the planet in Rails. However, a project may come along for which there is an existing library implemented in Java which would allow you to complete the project quickly using Java, whereas in Ruby you would have to write this same library. Don’t choose to use Ruby because it is cool or the funnest language to use right now. Use a language because it makes sense for the projects your team is working on. JRuby brings even more interesting twists and scenarios. With JRuby it becomes easy to combine Java and Ruby on the same platform and within the same application. You could use the wonderful Java libraries while writing your new code in Ruby.

Neal Ford speaks of something he calls Polyglot programming. Polyglot programming is the concept of using many different language together even on a single project. The idea is that you should always be focused on using the best tool for the job. Today it is actually rare to write a web application using a single langauge. Your business logic may be written in Java, but consider other languages that you probably use without a second thought, JavaScript, SQL, perhaps a Perl script or too for maintenance tasks. The two primary platforms of today, the Java platform and the .Net platform, are both able to support a growing number of languages. For example the Java platform today supports Java, Ruby, Groovy, Scala and probably a bunch of lesser known languages. Each language may have strengths in a given area. Don’t be afraid to mix and match your languages even on a single project. Use the best tool for the job at hand. We should all be Polyglot programmers. Every good developer should expand their knowledge of languages beyond the one or two that they feel comfortable using. Even if you continue to use a single language, you may find a whole new way of thinking about that language when you’ve studied other languages.

Don’t let positive or negative hype turn you off from learning a programming language that may be outside of your comfort zone. I know that at first glance Ruby can seem very different to Java programmers. It is a dynamic, scripted language and that is a different world to many Java developers. I had been doing Java development for nearly 10 years before I learned Ruby. Now I advocate for Ruby every chance I get. I have not met too many developers who have given Ruby a real trial and have not come away with a positive experience, even if they choose not to use Ruby going forward. So in summary, don’t choose a language simply because thats what your company has always done or because thats the only language you know. I agree that those may in fact be important factors in what is the best choice for your team, but evaluate your optioins and use the right tool for the job.

Last week I attended a conference in Ohio called CodeMash. The theme of this conference is to bring together developers with different programming language backgrounds and have them learn from each other. I think the concept of the conference is wonderful. This is the second year that I’ve attended it and I will continue to do so in the future. We need more community across languages as opposed to just single language user groups and conferences. It would be great to see more user groups of different languages hold combined meetings with topics that are common to multiple languages. I think both groups can learn alot from each other.

Tags java, languages, php, programming, rails, ruby, .net | 2 comments