I pledge right now that will be the only REST-related pun in the whole book (unless I think of a really good one later on).
REST is another one of those tortured software acronyms — it stands for REpresentational State Transfer. The basic idea dates back to the doctoral dissertation of Ray Fielding, written in 2000, although it only started gaining traction in the Rails world in early 2006, when a couple of different plugins allowed for a RESTful style within Rails. The functionality was rapidly moved to the Rails core and has just as quickly become a very commonly used practice, especially for standard Create, Read, Update, Delete (CRUD) style functionality.
There are three different ways of thinking about REST as compared to a traditional Rails application:
Pages versus resources
You'll explore each of these in the following sections.
The traditional view of data on the Web is action-oriented. A user performs an action on a page, usually by just accessing the page, but sometimes by sending data as well. The server responds with data, usually in HTML, but a pure web service is likely to send XML or JSON.
A RESTful application, in contrast, is viewed as a set of resources, each of which contains some data and exposes a set of functions to the Web. The core of these functions is made up of the standard CRUD actions, and the application programming interface (API) for ...