Resourceful Routing Theory

Resourceful Routing Theory

Resourceful Routing Theory

Before proceeding further, you should take a moment to learn about the theory of Resourceful Routing.

Upcoming steps will apply concepts from this theory. Having an understanding of it will help you see things more clearly.

This can be a confusing topic. It often takes some practical experiences combined with a study of the theory for it to fully make sense. Reading this guide before diving into hands-on work can be beneficial, but it's expected that not everything will be crystal-clear after this initial read through. You will be given a chance to revisit this content a few times in the future, after you've had some hands-on experiences.

Historically, web servers worked by allowing users to directly access certain files and folders. For example, where you to visit the URL, the webserver would look for a file called see_details.php inside an widgets_folder folder. Additionally, the number 12 would likely be assigned to a variable named widget inside that page, and influence what the page does.

Many modern web applications prefer to create "pretty urls", or "routes", which are more clean and user-friendly versions of those URLs. The example above might be replaced with

Resourceful Routing is a best practice for organizing the routes for your website. It does this by encouraging you to think of the data on your website as Resources, and to apply a common set or URLs to each Resource.

As an example, consider a website about widgets. You want to maintain an inventory of widget records. Widgets, then, is one of the Resources on your website. To do this, you will need the ability to create, read, update, and delete records.

These four verbs are commonly referred to as CRUD, and are regarded as the standard data management interface.

To achieve CRUD functionality for our widget resource, Resourceful Routing defines four actions. These four actions all display something to the user, be it specific widget data or forms for creating and editing widgets.

Action Purpose
Create display a form for creating a new widget
Index display a listing of all widgets
Show display full information for a single widget
Edit display a form for updating an existing record

There are three additional actions defined by Resourceful Routing which deal with processing the user's commands around managing the widget records inventory.

These three actions aren't typically associated with displaying anything on screen. Rather, they receive a command from the user, process it, and then redirect them to a suitable landing page.

You can think of these as what happens when you click the save, update, or delete button for a widget. Typically, when you click a 'Save' button on the Create form, your browser sends a request with the form data to the Store URL. Once the server finishes processing this, it will redirect you back to the widget Index URL, or possible the widget Show URL for the widget you've just created.

Action Purpose
Store process the submission of the "create new widget form" (the Create action from above)
Update process the submission of the "edit existing form" (the Edit action from above)
Destroy process a "delete widget request", often triggered by a 'delete' button on a 'show' or 'edit' page

These 7 URLs for any given resource represent the Resourceful Routing pattern. Following this pattern within your website helps keeps things organized and predictable. Furthermore, the urls these lead to are designed to be as meaningful as possible for the users of your website. It does this, in part, by making use of a variety of HTTP methods available.

HTTP, the language used for communication between your web browser and web servers, defines a number of different methods for communication.

Method Purpose
GET Retrieve data or content
POST Store the attached data
PUT/PATCH Update the defined record with the attached data
DELETE Delete the defined record

You can see how performing a GET request versus a POST request to the same url can have different meaning and can be mapped to different controllers.

Bringing everything together, here are all seven urls, the HTTP method associated with them, and some additional context.

Action HTTP Method URI Full URL Example
Index GET /widgets
Create GET /widgets/create
Store POST /widgets
Show GET /widgets/{widget}
Edit GET /widgets/{widget}/edit
Update POST /widgets/{widget}
Destroy DELETE /widgets/{widget}

The benefits of the Resource Routing pattern may start to become more clear if you consider that your same website may need to keep track of Grommets as well as Widgets. We can add routes for those, as well.

Action HTTP Method URI Full URL Example
Index GET /grommets
Create GET /grommets/create
Store POST /grommets
Show GET /grommets/{grommet}
Edit GET /grommets/{grommet}/edit
Update POST /grommets/{grommet}
Destroy DELETE /grommets/{grommet}

What if you decided you wanted to add the ability to track Gizmos, as well?

Following along with the pattern, you can quickly expect to need to add:

  • An Index GET route with the URI /gizmos
  • A Create GET route with the URI /gizmos/create
  • A Store POST route with the URI /gizmos
  • A Show GET route with the URI /gizmos/{gizmo}
  • A Edit GET route with the URI /gizmos/{gizmo}/edit
  • An Update POST route with the URI /gizmos/{gizmo}
  • A Destroy DELETE route with the URI /gizmos/{gizmo}

In Laravel, there is a file dedicated to defining routes. Soon enough you will be setting to work defining routes in your Laravel application, and writing the code to handle requests to them. Any time you are engaged in adding a route to that file, it's a good idea to pause for a moment, think carefully about the intent of the route you are adding, and trying to make it fit within a Resourceful Routing context.

There's a lot of information packed into this Resourceful Routing crash-course! Hopefully some aspects of it are making sense, and will serve you well when you dig into adding our first routes to our application.

Before you do, there are a couple more concepts worth study.