Is this the correct way to design REST API URI's?-CodePudding

So I'm working on a small project. It's a REST API that will act as the back-end for a 'buy and sell' website. At the moment I have two main resources: Users and Ads. A user can create many ads. Every ad was created by some user.

Could someone verify that the following endpoints follow REST principles and that they make sense? If you don't think they look right please suggest an alternative.

//Users
Create a user - POST /api/users - 
user details are passed as json in request body.

Get a user by id - GET /api/users/{user_id} 

Get the logged in user - GET /api/users/authenticated_user -
An authentication token is passed in the request header and is used to find the user in the database.

Update the logged in user - PUT /api/users/authenticated_user - 
new user details are passed in the request body. An authentication token is passed in the request header and is used to find the user in the database.

Delete the logged in user DELETE /api/users/authenticated_user -
 An authentication token is passed in the request header and is used to find the user in the database.

Get an ads user - GET /api/ads/{ad_id}/user
    

//Ads
Get all ads - GET /api/ads

Create an ad - POST api/ads -
 ad details are passed in request body and the user_id of the ad creater is got from the authentication token passed in request header. Would this endpoint make more sense to be something like: /api/users/authenticated_user/ads

Get an ad by id - GET /api/ads/{ad_id}

Update an ad - PUT api/ads/{ad_id} - 
ad details are passed in request body and the user_id of the ad creater is got from the authentication token passed in request header to make sure the ad was created by him/her. Would this make more sense to be api/users/authenticated_user/ads/{ad_id}

Delete an ad - DELETE api/ads/{ad_id} - 
The user_id of the ad creater is got from the authentication token passed in request header to make sure the ad was created by him/her. Would this make more sense to be api/users/authenticated_user/ads/{ad_id}

Get a users ads by id - GET /api/users/{user_id}/ads

Get logged in users ads - GET /api/users/authenticated_user/ads -

An authentication token is passed in the request header and is used to find the user in the database.

The reason for using the authentication token in some endpoints is because the client doesn't have access to the user_id of the logged in user only the authentication token. Thankyou, would really appreciate your input.

CodePudding user response：

Could someone verify that the following endpoints follow REST principles and that they make sense?

REST doesn't have "endpoints", it has resources. (Fielding, 2018)

Any identifier that is consistent with the production rules described in RFC 3986 "follows REST principles".

What "REST principles" would tell you to do is to design a web site, with interlinked hypertext documents, and web forms, and to take advantage of the standards that are shared on the web.

But what REST doesn't tell you is what pages should be on your web site, or what spelling conventions should be used for your web pages, or how to bridge the gap between the web site and the interesting business activities in your domain.

Any spelling convention you want to use for your resource identifiers is fine. The machines don't care if the spelling of the identifier matches the semantics of the resource.

Humans tend to prefer human readable identifiers - access logs and browser histories are easier to analyze when you can guess what the resource is from the identifier spelling.

Identifier families that can easily be described by URI templates make a number of mapping chores (like routing) much easier.

And of course, it's really useful if bookmarks remain stable.