當認證用戶希望訪問他完全擁有的資源時，在 URL 路徑中指定用戶 ID 似乎是多余的。
因此，在以下示例中，哪種方式更適合命名我的 API 端點？
示例 1
PUT /users/{id}/profile-pic。
或
PUT /profile/profile-pic
示例2 用戶想在他的個人資料中添加一個愛好
POST /profile-pic
POST /users/{id}/hobbies POST /profile/hobbies
uj5u.com熱心網友回復：
看到人們關注他們在URI和回應方面的API設計是一件令人高興的事。一個設計不佳的API將很快死亡，因為人們將避免使用它們。
即使它不會被公開，而且除了你自己或你的團隊之外沒有人會使用它，但考慮到你的同事和你未來的自己，花一些時間來考慮你的URI會是什么樣子。
回到你的問題，我的朋友，根據我邀請你閱讀的Hands-on restful API design patterns and best practices一書，REST API由四個獨特的原型組成，具體如下 如下：
- Document：檔案是資源表示的基礎，具有基于欄位和鏈接的結構。
https://api-test.lufthansa.com/v1/profiles
https://api-test.lufthansa.com/v1/profiles/customers
Collection。集合也是一種資源，它是一個由API提供者或服務器管理的資源目錄。
https://api-test.lufthansa.com/v1/profiles/customers/accountbalance
https://api-test.lufthansa.com/v1/profiles/customers/memberstatus
- 商店。商店是一個由客戶端管理的資源庫。存盤器允許 API 客戶端將資源放入其中，為被添加的資源選擇 URI，將其取出，并在其決定時洗掉它們。
http://api.example.com/cart-management/users/{id}/carts
http://api.example.com/song-management/users/{id}/playlists
- Controller。控制器資源類似于可執行方法，有引數和回傳值。REST API依靠控制器資源來執行不屬于任何CRUD方法的特定應用操作。
POST /alerts/245245/resend
因此，在你的案例中，你可以遵循GitHub API的設計。看看他們是如何檢索一個組織的專案的。你的會是這樣的：
PUT /users/{id}/profile-pic
POST /users/{id}/hobbies
我很抱歉把它寫得很長，我想把我的觀點建立在具體的東西上。
uj5u.com熱心網友回復：
當一個經過認證的用戶希望訪問一個他完全擁有的資源時，在URL路徑中指定用戶ID似乎是多余的。
不應該這樣，資源識別符號的語意和授權頭的語意是不同的。
只有 Bob 可以獲得 /profile/Bob 的副本，這是一個訪問策略的問題，而不是訊息語意。
回顧Fielding對resource的定義。 "Bob的資料 "和 "Alice的資料 "是不同的可命名資訊（暫且假設Bob和Alice本身是不同的），因此應該有不同的識別符號。
這就是 "RESTful "的答案。
在實踐中，HTTP 有關于認證的特殊規則，對認證請求的處理意味著你可能會 "逃脫 "將授權標頭視為資源識別符號的一部分（尤其是在授權用戶僅被允許訪問其自身資源層次的情況下）。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/309954.html
標籤：