Lesson Weekend

Let's take a look at the routes we'll need in our record store application. For now, our application only includes albums that need CRUD functionality. Our application will get much more complicated if we also include artists or create relationships between artists and albums (which we'll cover more in the next section). Even so, routing can be quite complex, especially once we start using nested routing later in this section. Be patient with yourself and trust that these concepts will become more clear as we practice with routing more.

Because routing for CRUD functionality is so common, there is a standard naming convention for each route. These naming conventions are known to be RESTful and are also used for building APIs (short for application programming interfaces). We will cover REST and APIs more later in this course. For now, just know that REST is a series of best practices and design patterns that includes standardized naming.

Here are the routes we'll need to implement CRUD functionality in our application. Let's imagine our record store has the domain www.bestundergroundrecords.com. This way, we can see what the URL will look like for a user navigating to a page.


A few things about the list above:

  • :id represents a dynamic ID. This could be 72 or album-98 or a UUID like d88c6706-6b5e-11e9-a923-1681be663d3e. We'll use integers in our Sinatra applications. These kinds of dynamic values are always preceded by a :. Sinatra doesn't care what we call it. We could pass a value into :name or :cool_id or something else. However, :id makes the most sense here.
  • Note that several routes have the same URL. Examples include GET albums/:id and PATCH albums/:id. Even though both use the same URL, they will route to different actions in our application.
  • We cannot access any POST, PATCH, or DELETE routes by typing in the URL. We will need to create forms or buttons that specify that specific action. For example, a form might have a POST action and a delete button might have a DELETE action.

We will go over all these concepts further soon.

We'll also add a few more routes to access our forms:


We could easily embed forms in our other views; for instance, it wouldn't be challenging to automatically add an edit form to the detail page for an album. However, routing will be clearer if we keep everything separate for now.

Always use RESTful naming conventions when adding CRUD-related routing to Sinatra. From time to time, it will be necessary to add custom routes (which we'll discuss in a future lesson), but the routes listed above are standard for creating, reading, updating and deleting items from a server-side application.

In the next lesson, we'll apply our routes to a bare bones Sinatra application.


REST: Short for REpresentational State Transfer. Among other things, a naming convention for routing.

Routes for Record Store

HTTP verb Route CRUD Action Description URL
GET /albums READ Get a list of all albums. www.bestundergroundrecords.com/albums
GET /albums/:id READ Look at the detail page for a single album. www.bestundergroundrecords.com/albums/72
POST /albums CREATE Add a new album to the list of albums. www.bestundergroundrecords.com/albums
PATCH /albums/:id UPDATE Update a single album. www.bestundergroundrecords.com/albums/72
DELETE /albums/:id DELETE Delete an album from the list. www.bestundergroundrecords.com/albums/72

Always use RESTful naming conventions when adding CRUD-related routing to Sinatra.

Lesson 5 of 37
Last updated July 28, 2022