首先，我知道當您指向資源時需要使用路徑引數，而當您定義可以添加“屬性”（或時間更改）的內容時，需要使用查詢引數。
但是，讓我們假設我需要獲取屬于用戶的資料。
在這種情況下，我喜歡像這樣撰寫 REST API URL。
https://mylink/user/getbyid
并不是
https://mylink/user/get
在我撰寫 REST API 的方式中，我會像/user/getbyid?id=1. 以我不撰寫 API 的方式，您將呼叫它/user/get/1。
因為我撰寫了像/user/getbyid, 之類的 API 呼叫/user/getbyname，/user/getbyuid所以我很少使用 Path 引數。99% 的時間我都在使用查詢引數。
考慮到我撰寫 api 呼叫的方式，我是否違背了最佳實踐？或者我的做法是對的還是無視的？
uj5u.com熱心網友回復：
我知道當您指向資源時需要使用路徑引數，而當您定義可以添加“屬性”（或時間更改）的內容時，需要使用查詢引數。
這實際上是不對的 - 歡迎您根據自己的喜好將資訊編碼到路徑或查詢中；機器不在乎，只要您的識別符號與 RFC 3986 中定義的生產規則一致即可。
“資源識別符號”包括路徑和查詢部分。
由于我撰寫了諸如 /user/getbyid、/user/getbyname、/user/getbyuid 之類的 API 呼叫，因此我很少使用 Path 引數。99% 的時間我都在使用查詢引數。
是的，沒關系。
考慮到我撰寫 api 呼叫的方式，我是否違背了最佳實踐？或者我的做法是對的還是無視的？
無視，我會說。資源識別符號很像變數名；人們可能會花費數小時來爭論變數名，而機器并不關心。資源識別符號也是如此。
這些識別符號可以改進嗎？我認同; 關鍵思想是我們正在識別資源，而不是識別資源如何實作的實作細節。從某種意義上說，識別符號是“檔案的名稱”。
洗掉 getby... 路徑段也可以。
/users?id=1
/users?name=bob
/users?uuid=469149ae-ecc6-4652-b094-17c211ff58ef
...但是，根據您的路由實作，消除這三個資源的歧義可能很笨拙。添加額外的路徑段以使路由更容易是可以的。
uj5u.com熱心網友回復：
設計 REST API 以執行基本 CRUD（創建、讀取、更新、洗掉）操作的最佳實踐，使用 HTTP 方法GET POST PUT PATCH DELETE、URL 和/或引數的組合。
假設你想設計一個 REST API 來為 User 執行 CRUD 操作
1.創建
要執行創建，請/users使用POSThttp 方法設計一個端點。
# http method URL parameters
POST https://<yourdomain>/users, { first_name: "Peak", last_name: "Gen"}
2. 閱讀
要執行Read，請/users/<id>使用GEThttp 方法設計一個端點。
# http method URL parameters
GET https://<yourdomain>/users/1
2. 更新
要執行Update，請/users/<id>使用PUT或PATCHhttp 方法設計端點。
# http method URL parameters
PUT https://<yourdomain>/users/1, { first_name: "Nitin", last_name: "Sri"}
2. 洗掉
要執行Delete，請/users/<id>使用DELETEhttp 方法設計一個端點。
# http method URL parameters
DELETE https://<yourdomain>/users/1
如果您注意到，在讀取、更新和洗掉中使用了相同的 URL，但它們的 HTTP 方法不同。表示相同的 URL 根據其 HTTP 方法路由到不同的操作。
閱讀有關REST API 的更多資訊
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/387058.html