At work, I've seen routes like this:

/people/:id/edit

But I reckon such routes are hard to build programmatically. To my mind, better, is:

/people/edit/:id

That way, you can do stuff like:

const peopleEditRoute = '/people/edit'
...
<Route path=`${peopleEditRoute}/:id`
...
<Link to=`${peopleEditRoute)/${id}`

However, a colleague commented that '/peoples/:id/edit' is more conventional - it follows REST

Are they right?

CodePudding user response：

As per @jonrsharpe's comment, the route should be:

/people/:id

...for all of GET, POST, PATCH etc...

CodePudding user response：

/peoples/:id/edit' is more conventional - it follows REST Are they right?

No; REST doesn't care what spelling conventions you use for your resource identifiers.

I reckon such routes are hard to build programmatically.

They shouldn't be. URI Templates are a common solution, and I would expect library support in most languages where you are likely to be writing web code. (Hint: do you really want to be writing your own logic for deciding when to encode your data?)

One consideration for path segments is relative resolution: in particular the use of dot segments to move around an identifier hierarchy.

In other words, if you are in the context of the edit resource for some person, are you more likely to want a relative reference to another resource for the same person, or to the edit resource of a different person?

As noted by @jonrsharpe, if you are creating an API that is "of the web", then you typically will request the modification of a resource by sending a request (PATCH/POST/PUT) that identifies that resource as the request target.

The point here is cache invalidation. Caching is a constraint in the REST architectural style, and general purpose HTTP components know that responses can be re-used to service other requests, and know that successful unsafe requests invalidate previously cached responses.