The "right" way to route map a REST API

Question

Im working on a small node/angular application

A superadmin should be able to create/edit/delete new client accounts, within views delivered directly from the node application.

The clients on the other hand communicate with the backend/database through Angular and a REST API that the node application delivers. The clients need a username/password to login to their account.

Question: I have this route map, is it right of me to think that the :client need to be in the URL of the REST API, so the backend knows which data to fetch?

the : in the url indicates that it's a variable...

Route map Superadmin

/admin/client – POST
/admin/client/:id – GET
/admin/client/:id – PUT
/admin/client/:id – DELETE
/admin/clients – GET


Route map API JSON

/v1/:client/candidate – POST
/v1/:client/candidate/:id – GET
/v1/:client/candidate/:id – PUT
/v1/:client/candidate/:id – DELETE
/v1/:client/candidates – GET

/v1/:client/settings – GET
/v1/:client/settings – PUT

Answer 1

I think this is a little difficult to answer, because it would say one way is "right" and another is "wrong", when really there could be multiple ways of solving this problem. Here's what I would say though, around how you structure the API endpoints.

If we focus on these API endpoints specifically:

/v1/:client/candidate – POST
/v1/:client/candidate/:id – GET
/v1/:client/candidate/:id – PUT
/v1/:client/candidate/:id – DELETE
/v1/:client/candidates – GET

/v1/:client/settings – GET
/v1/:client/settings – PUT

Here we have a set of APIs that allow someone to look up and perform actions on resources for a specific client. In doing this, you've essentially opened this up to allow anyone to access anyone's data (until you add security). Building APIs like this would be more useful for a "superadmin" like you've described in your question, which would need to access multiple client profiles throughout their day. But as you might imagine, you'd need to restrict access to these endpoints to only those who have "superadmin" access OR are in fact the client themselves.

If instead the main use case of these API endpoints was to serve the clients, I would instead remove the :client parameter:

/v1/candidate – POST
/v1/candidate/:id – GET
/v1/candidate/:id – PUT
/v1/candidate/:id – DELETE
/v1/candidates – GET

/v1/settings – GET
/v1/settings – PUT

Since you mentioned that the client would need to login to hit these APIs, you already know who the client is when they make the request. You can instead look up the client from the request, and access these resources based on who is making the call. Personally I think this makes things a little easier to follow, since the request is always asking for my data, rather than some "client's" data, which you then need to verify they have access to.

But again this is all based on how you architect your application, what's the use cases, who is going to be accessing the system, etc. It might make sense to separate out the "superadmin" APIs from the normal "client" APIs like I've described above, or it might be better the keep them all together. The answer will probably end up being which is easier to understand and maintain in the long term.