What the CRUD is a RESTful Route?

Urban Dictionary

More than just a euphemism for sheltered children, CRUD, and by extension, RESTful routing conventions, are useful implementations for the budding developer.

Also crud. (Flickr/Josh Larios)

When used together in Sinatra and Active Record applications, pairing CRUD with RESTful routes can provide us efficient and consistent design patterns that allow for easier manipulation of data. For example, as one navigates through a website by clicking links, creating posts, etc., you’re in effect making a state transition which carries you to the next page or action (the next state of the application). These navigations are blueprinted through convention and ultimately enable an application or web service to interact with a server.

Before digging any further (pun intended), let’s get some basic definitions out of the way.

HTTP Verbs:

HTTP (Hypertext Transfer Protocol) defines a set of request methods to indicate the desired action to be performed for a given resource. In effect, HTTP verbs (or rather, requests) are sent from the user’s browser, to the server containing the application information, and tell it how to proceed. For our purposes, we’ll be looking at: POST, GET, PUT, PATCH, and DELETE verbs.

CRUD:

Quite simply, CRUD stands for CREATE, READ, UPDATE, DELETE. These are the four basic functions of persistent data storage which help maintain records in a database.

REST:

REST stands for Representation State Transfer; An architectural system centered around resources and hypermedia via HTTP protocols. Or simply, a set of principles that assign how HTTP and URL standards are used.

Representation State Transfer sorely needed.

Putting It All Together

RESTful routing provides mapping from HTTP verbs from the user’s browser to controller CRUD actions on the server side. These controller actions dictate either what data is then rendered to the user back through their browser, as well as how that data will be persisted to the database.

To enact this, let’s reference the following chart:

Note: PATCH, PUT and DELETE requests require an override hidden input field on view submit forms, via Sinatra Middleware. Example (second line of code):

<form action="/object/<%=@object.id%>" method="post">
   <input type="hidden" name="_method" value="delete">
   <input type="hidden" name="object[id]" value="<%= @object.id %>">
   <input class="btn red-outline" type="submit" value="Delete">
</form>

Additionally, the following code will be required in the application’s config.ru file, placed above the run ApplicationController line:

use Rack::MethodOverride

In Summary

Rather than relying on disparate URLs alone to indicate what webpage a user would like to navigate to, RESTful routing combines HTTP Verbs and URLs so that a single URL when used with a different verb (such as GET, PUT, POST, DELETE) navigates the user to a different page.

Mappings between HTTP verbs and CRUD actions should ideally follow RESTful route convention. As such, we’ll have a clean application where an action can create a new object (new route), display an object (show route), display all objects (index route), update an object (modify/edit route), and delete an object (delete route).

RESTful route conventions are useful, cleaner, shorter, and should be strived for, however it’s quite likely that not all pages will follow such convention. For example, websites can feature an About or Contact page which won’t use objects. At the end of the day, our goal is to aim to name all routes clearly, consistently and in sensical ways while following RESTful convention when applicable.