The 8th Missing Resource Route in the CRUD Pattern
Published: 2021-03-12 02:24:07

Conventions are patterns we or others have established as generally good ways of doing things. We save a lot of time when we reduce the amount of decisions we have to make and thought put into things by using conventions. 

I stumbled upon [Laravel](https://laravel.com) early in my software career and every convention was better than what I was doing. And years later, those conventions still serve me well. Laravel was first to introduce me to the [7 resourceful routes](https://laravel.com/docs/controllers#actions-handled-by-resource-controller) convention.

If you're not familiar, this pattern is 7 endpoints you generally code for a "resource" to Create, Read, Update and Delete. Here is a table to illustrate a "Post" resource and the HTTP verbs following this convention:

Verb      | URI                    | Action       | Description
----------|------------------------|--------------|--------------
GET       | `/posts`               | index | show list of posts      
GET       | `/posts/create`        | create | show create form
POST      | `/posts`               | store | process create form
GET       | `/posts/{id}`          | show | display single post  
GET       | `/posts/{id}/edit`     | edit | show edit form
PUT/PATCH | `/posts/{id}`          | update | process edit form
DELETE    | `/posts/{id}`          | destroy | process delete request

Following this convention has saved me so much time. Naming and structuring things can be a huge time eater. If the "resource" doesn't fit 100% into that convention, I usually can break out a new resource and continue the CRUD convention. Adam Wathan gave [a great talk](https://www.youtube.com/watch?v=MF0jFKvS4SI) about this in Laracon 2017.

### The Problem

The problem is DELETE. Every app I work on I spend time thinking of confirmations when allowing users to delete things. Each app has had slightly different UI approaches which can be a time eater because design is very subjective. So I wanted to explore this because again.. conventions save us time and I'm feeling some friction without a standardized approach.

 
### The Missing Endpoint

What I have come to think is that maybe there is a missing endpoint in this convention and adding one might be the answer. What if the destroy action had a GET endpoint which could be used to display a confirmation page, accept a password confirmation, retrieve data related to the delete etc


Verb      | URI                    | Action       | Description
----------|------------------------|--------------|--------------
GET    | `/posts/{id}/delete`          | remove | show delete confirmation
DELETE    | `/posts/{id}/delete`          | destroy | process delete request

`edit` -> `update` | `create` -> `store` | `remove` -> `destroy`

For such a small change, it really creates a positive impact. I have implemented this in a few projects and noticed the friction not only gone, but it cleans up my code quite a bit. Here are the benefits I noticed:

### Benefits

- Link to the delete route from anywhere within or outside the  codebase
- A dedicated endpoint if any data is needed to populate confirmation message: "you're about to delete 1,253 related records"

### More thought

Both the `store` and `update` actions, (the other 2 endpoints that affect change in the database) have a corresponding GET route before performing the actions. This makes sense because they need an endpoint to accept inputs. But for sensitive data, so does `destroy`.. a password confirmation. 


### Conclusion

Not every convention is going to work for everything, including this one. I think this idea has some benefits, but it really just depends about your project. I wrote this to just share an idea incase others share in my experience and want another convention to consider.

--- 

Let's connect on Twitter, I mostly tweet Laravel stuff.

https://twitter.com/im_brian_d