这是设计 REST API URI 的正确方法吗？

Question

所以我正在做一个小项目。这是一个 REST API，将充当 'buy and sell' 网站的 back-end。目前我有两个主要资源：用户和广告。一个用户可以创建多个广告。每个广告都是由某个用户创建的。

有人可以验证以下端点是否遵循 REST 原则并且它们有意义吗？如果您认为它们看起来不合适，请提出替代方案。

//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 -

身份验证令牌在请求中传递 header 并用于在数据库中查找用户。

在某些端点中使用身份验证令牌的原因是因为客户端无法访问已登录用户的 user_id 只有身份验证令牌。谢谢，非常感谢您的意见。

Answer 1

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)

任何符合RFC 3986“遵循 REST 原则”中描述的生产规则的标识符。

“REST 原则”告诉您要做的是设计一个网站，其中包含在网络上共享的相互链接 hypertext documents, and web forms, and to take advantage of the standards。

但是 REST 不会告诉您的是您的网站上应该有哪些页面，或者您的网页应该使用什么拼写约定，或者如何桥接网站与 interesting business activities in your domain.

之间的差距

您想要用于资源标识符的任何拼写约定都很好。机器不关心标识符的拼写是否与资源的语义匹配。

人类往往更喜欢人类可读的标识符 - 当您可以从标识符拼写中猜出资源是什么时，访问日志和浏览器历史记录更容易分析。

可以通过 URI templates 轻松描述的标识符系列使许多映射工作（如路由）变得更加容易。

当然，bookmarks remain stable。

这是设计 REST API URI 的正确方法吗？

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

rest

web-applications