Enterprise Rails

Mapping REST to SOA

With a basic understanding of the underpinnings of REST, we are now ready to discuss REST in the context of a service-oriented architecture. A good place to start is with a cautionary note from Roy Fielding himself, who wrote the following in his dissertation:

The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.

REST is great for the types of large-grained content users are accustomed to seeing on the Web: HTML web pages, PDF documents, images, etc. In fact, you can’t help but use REST when you request these documents; users of the Web do use REST every day, whenever they request web pages. What REST isn’t great for is the context for which it has recently gotten so much attention, namely, mapping REST to database rows. Indeed, this is how ActiveResource, the Ruby on Rails implementation of REST, is being marketed: as an easy way to add a web-service interface atop ActiveRecord CRUD.

Mapping to CRUD

Although it is not generally desirable to do so, the four main HTTP verbs can be mapped to CRUD, as shown in Table 17-1. A create maps to an HTTP PUT, which translates to an SQL insert command. A read maps to an HTTP GET, which translates to an SQL select command. An update maps to an HTTP POST, which translates to an SQL update command. Finally, a delete maps to an HTTP DELETE, which translates ...