Crossing boundaries: REST on Rails

Over the past 20 years, a trend has led to the development of commercial software tools: to combat complexity with complexity. Nowhere is this trend more pronounced than in the field of distributed computing. The C and Java™ communities have seen some incredibly complex frameworks built to support distributed communications. The Distributed Computing Environment (DCE) supports remote procedure calls between applications written in C language. The common Object Request Broker Architecture (CORBA) standard supports communication between object-oriented applications. The Enterprise JavaBean (EJB) specification provides security, persistence, transactions, messaging, and remote services. Advocacy of the various frameworks has been rife, but these frameworks have not met expectations, and some have even been disastrous as a result of their complexity. Of these frameworks, only EJB 3.0 is a strongly simplified result that has the potential to succeed on a distributed application. The market may or may not give this other space to the face of an enemy, but EJB still needs to be delivered.

The latest large distributed framework is WEB services. WEB services technology allows applications to communicate with each other in a platform-independent or programming language-independent way (see Resources). WEB service standards are also threatened by the complexity demon, but the alternative strategy called REST promises a simpler approach. This article describes how to add RESTful Web services to Ruby on Rails and invoke services from Ruby and Java code.

WEB Services Domain

Like EJB, CORBA, and DCE, the core abstraction of WEB services is also remote procedure invocation. The Web service exploits a protocol called SOAP (initially, SOAP represents a Simple object access protocol, but the term is now degraded), representing the structure of the message in XML. Here's a tip: If the protocol starts with a simple S, it's not easy. The Web Service Definition language (WSDL) provides a standard specification of the service. Like soap, WSDL is also a tricky and complex API, and SOAP and WSDL involve only the surface of the many APIs that make up the great monster of Web services (see Resources). Web services require a major overhaul, thanks to Roy Fielding, an influential doctoral thesis, Web services have been overhauled (see Resources).

Fielding's paper describes the REST application networking strategy. REST is fundamentally different from a full stack Web service, with three main reasons:

The core abstraction of REST is a remote resource, not a remote procedure call.

REST did not invent an exhaustive list of standards, but instead adopted existing Internet standards, including HTTP, XML, and TCP/IP.

REST does not cover every possible scenario, but rather covers the most common problems.

Please think of REST as a browse. REST customers access resources using the same HTTP commands as browsers. When the REST client accesses the representation of the resource, the customer transitions to a state. With different HTTP commands, the REST client can create, read, update, or delete records of resources.

For example, take a typical blog as an example. Get a list of posts by entering a URL, such as blog.rapidred.com. Then, if you want to edit a blog entry, you can enter the HTTP parameter (for example, blog.rapidred.com/edit?article=12345) in the URL, and then display the edit form. Because each blog entry has its own URL, click on the link or enter the URL directly, you can use the HTTP command to read, modify or delete content.

In short, REST can:

Naming resources on the WEB with TCP/IP

Querying and manipulating these resources with HTTP

Constructs data using text-based, standard message formats, such as XML or HTML

Ruby on Rails provides excellent support for WEB services with REST.

Action Web Services Overview

Rails implements a Web service with a module called Action Web Services. Many development frameworks encourage views and WEB services to use stand-alone controllers. This strategy maintains a consistent style between the controllers. The problem is that you need a new controller for each of the things that you serve. For example, the Ajax user interface requires that remote XML calls to JavaScript be obtained from the controller.

Instead of assigning a single controller to a WEB service, using Rails, you can use the same controller to provide content to html-based views, xml-based Web services, and xml-based JavaScript components on a universal basis. The best way to understand the action Web Services is to see how it works in the context of a working application.

Create a database called Service_development with the database manager of your choice. Next, you use the command to create Rails projects and models:

> rails service
> script/generate model Person

After the model is generated, there is a migration called DB/MIGRATE/001_CREATE_PEOPLE.RB. Please edit this migration to imaging Listing 1:

Listing 1. Migration of people tables

class CreatePeople < ActiveRecord::Migration
　 def self.up
　　 create_table :people do |t|
　　　 t.column :first_name, :string, :limit => 40
　　　 t.column :last_name, :string, :limit => 40
　　　 t.column :email, :string, :limit => 40
　　　 t.column :phone, :string, :limit => 15
　　 end
　 end
　 def self.down
　　 drop_table :people
　 end
end