Martin Heller
Contributing Writer

REST and Ruby on Rails 1.2

analysis
Jan 26, 20072 mins

The much-anticipated Ruby on Rails 1.2 update has shipped, as has the second edition of Agile Web Development with Rails. As our earlier news item mentioned, a major feature of Rails 1.2 is REST (Representational State Transfer) functionality. I have updated my own Rails installation to version 1.2.1 and have run a full set of tests on local copies of the Rails applications in which I have been involved. I

The much-anticipated Ruby on Rails 1.2 update has shipped, as has the second edition of Agile Web Development with Rails. As our earlier news item mentioned, a major feature of Rails 1.2 is REST (Representational State Transfer) functionality.

I have updated my own Rails installation to version 1.2.1 and have run a full set of tests on local copies of the Rails applications in which I have been involved. I got pages of warnings and feature deprecations. I’m in no hurry to upgrade the production sites, which are running just fine on Rails 1.1, thank you, but I’m planning to use Rails 1.2 for my future Rails sites.

Unless you’ve been following the Rails evolution or REST itself, REST is probably a new term for you. The term is about 6 years old; it originated in a thesis by Roy Fielding. The following figure from the thesis summarizes how the constraints of Representational State Transfer derive from other architectural styles:

rest_derivation.gif

Fielding’s thesis is a bit daunting; fortunately, several people have jumped into the breach to explain REST to mere mortals. Many of these articles are listed on the REST Wiki; one of my favorites is REST In Plain English. That article explains how a uniform interface and statelessness look in the real world, or at least in the real Web.

An even better discussion of REST, one that relates directly to Rails 1.2, appears in Chapter 20 of Agile Web Development with Rails. The section from Chapter 12 on creating a REST interface is also quite good, and is available here.

Basically, what Dave Thomas has to say about REST in Chapter 20 is that

“in REST, we use a simple set of verbs to operate on a rich set of nouns. If we’re using HTTP, the verbs correspond to HTTP methods (GET, PUT, POST, and DELETE, typically). The nouns are the resources in our application. We name those resources using URLs.”

So, the difference between the old way of writing Rails actions and the REST way is that we don’t invent a lot of actions with verb phrases as names. Instead, we use standard verbs, and take advantage of Rails’ new resource routing facility, embodied in the map.resources keyword to ActionController::Routing::Routes.

Martin Heller

Martin Heller is a contributing writer at InfoWorld. Formerly a web and Windows programming consultant, he developed databases, software, and websites from his office in Andover, Massachusetts, from 1986 to 2010. From 2010 to August of 2012, Martin was vice president of technology and education at Alpha Software. From March 2013 to January 2014, he was chairman of Tubifi, maker of a cloud-based video editor, having previously served as CEO.

Martin is the author or co-author of nearly a dozen PC software packages and half a dozen Web applications. He is also the author of several books on Windows programming. As a consultant, Martin has worked with companies of all sizes to design, develop, improve, and/or debug Windows, web, and database applications, and has performed strategic business consulting for high-tech corporations ranging from tiny to Fortune 100 and from local to multinational.

Martin’s specialties include programming languages C++, Python, C#, JavaScript, and SQL, and databases PostgreSQL, MySQL, Microsoft SQL Server, Oracle Database, Google Cloud Spanner, CockroachDB, MongoDB, Cassandra, and Couchbase. He writes about software development, data management, analytics, AI, and machine learning, contributing technology analyses, explainers, how-to articles, and hands-on reviews of software development tools, data platforms, AI models, machine learning libraries, and much more.

More from this author