假設ProductType我們的資料庫中有一個表。這代表可以存在的產品型別：
| 產品型別 ID | 姓名 | 描述 | 容量 | 每晚價格 |
|---|---|---|---|---|
| 1 | 帳篷 | 這是帳篷 | 4 | 20 |
假設Product我們的資料庫中有一個表。這代表Products存在的實際實物（即在租賃店的庫存中）：
| ID | 產品型別 ID (FK) | 健康）狀況 | 最后使用 |
|---|---|---|---|
| 6 | 1 | 好的 | 18/11/21 |
| 7 | 1 | 壞的 | 18/11/21 |
| 8 | 1 | 中等的 | 18/11/21 |
現在假設我正在制作一個公共 API，它允許客戶查詢所有可用產品以及這些產品在特定日期集的價格。
我的選擇是： (a) 回傳ProductType物件的編輯版本，其中包含新欄位（例如quantityAvailable和priceForDates），傳達所請求的額外資訊：
{
"productTypeId": 1,
"name": "Tent",
"description": "This is a tent",
"capacity": 4,
"quantityAvailable": 1,
"priceForDates": 60,
}
(b) 將ProductType物件包裝在父物件中，然后向父物件添加額外的欄位（例如quantityAvailable和priceForDates）：
{
"quantityAvailable": 3,
"priceForDates": 60,
"product":
{
"productTypeId": 1,
"name": "Tent",
"description": "This is a tent",
"capacity": 4,
}
}
我經常遇到這種情況，我想知道 RESTful API 的最佳實踐是什么。非常歡迎任何意見。
編輯：IRL 我正在構建一個公共 API，它需要為我們公司的集成合作伙伴盡可能直觀和易于使用。
uj5u.com熱心網友回復：
這是基于意見的邊緣，但仍然是我對此的看法。
我會選擇選項（b）。原因是您可能會ProductType在其他端點中公開以下內容：
"product": {
"productTypeId": 1,
"name": "Tent",
"description": "This is a tent",
"capacity": 4,
}
在這種情況下，保持一致并ProductType在所有端點中使用相同的結構表示很重要。
最重要的是，這似乎是對檢查特定天數內產品可用性的呼吁的回應。甚至你說的方式“ (...) 允許客戶查詢所有可用的產品以及這些產品在特定日期的價格。 ”表明價格和可用產品的數量只是關于給定的附加資訊ProductType. 因此，他們應該被納入旁邊ProductType，但不作為的一部分ProductType。例如priceForDates顯然不是ProductType財產。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/362660.html