所以我正在做一個小專案。它是一個 REST API，將充當“買賣”網站的后端。目前我有兩個主要資源：用戶和廣告。一個用戶可以創建多個廣告。每個廣告都是由某個用戶創建的。
有人可以驗證以下端點是否遵循 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 -
身份驗證令牌在請求標頭中傳遞，用于在資料庫中查找用戶。
在某些端點中使用身份驗證令牌的原因是因為客戶端無權訪問登錄用戶的 user_id，只有身份驗證令牌。謝謝，非常感謝您的意見。
uj5u.com熱心網友回復：
有人可以驗證以下端點是否遵循 REST 原則并且它們有意義嗎？
REST沒有“端點”，它有資源。（菲爾丁，2018 年）
與RFC 3986 中描述的生產規則一致的任何識別符號“遵循 REST 原則”。
“REST 原則”會告訴您做的是設計一個具有相互鏈接的超文本檔案和網路表單的網站，并利用網路上共享的標準。
但是 REST沒有告訴您的是您的網站上應該有哪些頁面，或者您的網頁應該使用什么拼寫約定，或者如何彌合網站和您域中有趣的業務活動之間的差距。
您想用于資源識別符號的任何拼寫約定都可以。機器不關心識別符號的拼寫是否與資源的語意匹配。
人類傾向于更喜歡人類可讀的識別符號 - 當您可以從識別符號拼寫中猜測資源是什么時，訪問日志和瀏覽器歷史更容易分析。
可以由URI 模板輕松描述的識別符號系列使許多映射雜務（如路由）變得更加容易。
當然，如果書簽保持穩定，這真的很有用。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/359668.html