RESTful Routes
Much of the content in this page was adapted from Nathan Bean’s CIS 400 course at K-State, with the author’s permission. That content is licensed under a Creative Commons BY-NC-SA license.
Many web applications deal with some kind of resource, i.e. people, widgets, records. Much like in object-orientation we have organized the program around objects, many web applications are organized around resources. And as we have specialized ways to construct, access, and destroy objects, web applications need to create, read, update, and destroy resource records (we call these CRUD operations).
In his 2000 PhD. dissertation, Roy Fielding defined Representational State Transfer (REST ), a way of mapping HTTP routes to the CRUD operations for a specific resource. This practice came to be known as RESTful routing, and has become one common strategy for structuring a web application’s routes. Consider the case where we have an online directory of students. The students would be our resource, and we would define routes to create, read, update and destroy them by a combination of HTTP action and route:
| CRUD Operation | HTTP Action | Route |
|---|---|---|
| Create | POST | /students |
| Read (all) | GET | /students |
| Read (one) | GET | /students/[ID] |
| Update | PUT or POST | /students/[ID] |
| Destroy | DELETE | /students/[ID] |
Here the [ID] is a unique identifier for the individual student. Note too that we have two routes for reading - one for getting a list of all students, and one for getting the details of an individual student.
REST is a remarkably straightforward implementation of very common functionality, no doubt driving its wide adoption. Many web application frameworks support REST, either explicitly through special code structures or shortcuts, or implicitly through the use of route parameters.
When we use a RESTful route to create or update new resources, we often want to take an additional step - validating the supplied data.