Restful routes for file and manual configuration

[dustineichler]

As a method of organization or separation, I'd like to propose or discuss a request for a "restful routes and or restful file naming convention".

For example. One current option might look like this:

      <Route path="tasks/:taskID/edit" file="routes/tasks.$taskId.edit/route.jsx" />
      <Route path="tasks/:taskID/update" file="routes/tasks.$taskId.update/route.jsx" />
      <Route path="tasks/new" file="routes/tasks.new/route.jsx" />
      <Route path="tasks/:taskId/show" file="routes/tasks.$taskId.show/route.jsx" />
      <Route path="tasks/:taskId/delete" file="routes/tasks.$taskId.delete/route.jsx" />

However, I'm proposing the following...

Scenario: GET all tasks
Given the tasks route is available
When I send a GET request to the "/tasks" endpoint
Then ...

      <Route path="tasks" file="routes/tasks/index.route.jsx" method="GET" />

Scenario: GET a specific task
Given the tasks route is available
When I send a GET request to the "/tasks/{id}" endpoint with a valid task id
Then ...

      <Route path="tasks/:id" file="routes/tasks/show.route.jsx" method="GET" id="$taskId" />

Scenario: POST a new task
Given the tasks route is available
When I send a POST request to the "/tasks" endpoint with the task data
Then ...

      <Route path="tasks" file="routes/tasks/create.route.jsx" method="POST" />

Scenario: PUT an existing task
Given the tasks route is available
And a task with id "{id}" exists
When I send a PUT request to the "/tasks/{id}" endpoint with updated task data
Then ...

      <Route path="tasks/:id" file="routes/tasks/update.route.jsx" method="UPDATE" id="$taskId" />

Scenario: DELETE a task
Given the tasks route is available
And a task with id "{id}" exists
When I send a DELETE request to the "/tasks/{id}" endpoint
Then ...

      <Route path="tasks/:id" file="routes/tasks/delete.route.jsx" method="DELETE" id="$taskID" />

I present this without any knowledge about how react-router actually works. However, extending what is possible with the routes table would be useful immediately useful.

[HerrBertling]

How would you distinguish which route to render on the client? That will be an initial GET request because you need to show something, right? You could have DELETE, POST,… all as different forms on the route and do stuff based on some pointer (hidden intent inputs work quite nice), but that would be handled in the route's action then. But it also could lead to some weird UI where you're maybe better served with presenting different bits and pieces for tasks/:id/edit, tasks/new,…

I feel like you entirely left out the UI part for this proposal 😅

[dustineichler]

@HerrBertling Yeah you're right, but this was not a intended as well thought-out proposal in any imagination of the phrase. Any edge cases should be discussed below naturally, but point taken.

What are you imaging? I'm assuming the default would be a "GET" request and map to a corresponding route with a key, id or other custom designator.

[HerrBertling]

I present this without any knowledge about how react-router actually works.

Definitely check out what a loader and an action function do in a route 😅 they are pretty much the equivalent to a GET and POST endpoint. Doesn’t get more fine grained, so the other fun stuff you’d do for REST-y data mutation would have to happen in the loader. They “mirror” or rather align with HTML form methods, so that’s all you get 🤷🏼‍♂️

So what I’m imagining is… what Remix/react-router does out of the box: Handle data requests/mutations in the first step like any HTML form would. Then go from there in your action by e.g. sending some intent value in a hidden input or a button value.