For some routes on an API, like GET /news
, one would asume the user only wants news that pertains to them, so the userId is implicitly taken from authentication info.
However, some of the routes on an API i'm designing modify the "users" resource - i.e. changing some account info. For example, the user might want to change their name on the account. I could do
POST /users/name
or
PUT /users/:userId/name
1) Is this dichotomy generally correct (correct meaning most REST APIs would be designed in this fashion)? The idea that PUT would use an explicit userId where POST would take it from authentication info
2) If yes to the above, which style makes more sense for "modifying-account-info" type routes? If no, what do you suggest?
/name
just as an example for some information about a user that can be changed or does your app actually use a granularity that small? Usually I would assume that there is more than just one field of info per remote call. For example, a userInfo JSon consisting of name, email, and maybe a few other fields. Only when data becomes more complex (like a list of projects a user belongs to), they would get separate URLs likeGET /user/:userId/projects
andGET /user/:userId/project/:projectId