REST

Back in the year 2000, Roy Thomas Fielding had wanted to make inter-application communication much easier and simplify the URL’s corresponding HTTP verbs. So, in his PhD dissertation, he came up with REST (REpresentational State Transfer) as a standard way web apps should structure their URLs. His paper suggested a few other things, but we focus mostly on how it changed URLs. Fielding also noticed the rise in web applications communicating with each other. That’s a win-win!

REST — it’s an architectural design pattern, not a framework or code itself. By using RESTful principles, the Rails app is able to have a clear and standardized naming structure for routes and actions. RESTful routes have a clear mapping between the URL resources and the corresponding controller actions.👍

If we want to build out a newsletter feature, we would need to have four key actions- Create, Read, Update, Destroy- CRUD actions. In addition, we need an index page, two more routes for the visual interface when creating and updating records. That in total = 7.

The GET routes are all routes that usually render some erb content to a web browser. The POST and PATCH are the URL in the form action, and DELETE is a new type of verb.

╔═══════════╦════════════════════╦══════════════════════════╗
Method ActionDescription
╠═══════════╬════════════════════╬══════════════════════════╣
║ GET. ║ /newsletters ║ Show all newsletters. ║
║ POST. ║ /newsletters ║ Create a new newsletter. ║
║ GET. ║ /newsletters/new ║ Render the form for ║
║ ║ ║ creating a new newsletter║
║ GET. ║ /newsletters/:id ║ Render the form for ║
║ ║ /edit ║ editing a newsletter. ║
║ GET. ║ /newsletters/:id ║ Show a single newsletter.║
║ PATCH. ║ /newsletters/:id ║ Update a newsletter. ║
║ DELETE. ║ /newsletters/:id ║ Delete a newsletter. ║
╚═══════════╩════════════════════╩══════════════════════════╝

Rails maps these specific methods or “actions” as they are called in Rails. If we had a controller called NewsletterController, we would define these seven methods, and Rails will call them automatically based on the correct route.

Brake down of each of the controller actions and what it represents:

╔═══════════╦═════════════════════════════════════════════════╗
MethodDescription
╠═══════════╬═════════════════════════════════════════════════╣
║ index ║ Show all newsletters. ║
║ create ║ Create a new newsletter. ║
║ new ║ Render the form for creating a new newsletter. ║
║ edit ║ Render the form for editing a newsletter. ║
║ show ║ Show a single newsletter. ║
║ update ║ Update a newsletter. ║
║ destroy ║ Delete a newsletter. ║
╚═══════════╩═════════════════════════════════════════════════╝

Here is a diagram that shows how the views, controller actions, routes, and HTTP verbs are all mapped together:

  • GET — The GET method retrieves whatever information is identified by the Request URI. This means if you go to , you will get all of the posts that the application wants your application to have.
  • POST — The POST method is used to send data enclosed in the request to the server. The server is expected to use this data to create some new resource.
  • PATCH/PUT — The PUT/PATCH methods both represent the HTTP verbs that are used to update existing resources. So if you sent a request to with a new post name, the post with an of 1 would be updated.
  • DELETE — The DELETE method requests that the server delete the resource identified by the Request URI. This means… that it deletes the record. It’s nice and explicit.

SOFTWARE ENGINEER — WEB DEVELOPER WITH HEART FOR FRONT-END, MINIMALISM AND RASMENTALISM.