RESTful服務的url設計

Question

我有一個名為Pricing的資源，我想要檢索。 Offer可以有定價， Promo可以有Pricing資源，還有另一個實體Customer可以映射Pricing 。 我想根據OfferId / PromoId / CustomerId之一檢索Pricing 。

要為此設計URL，我遇到兩個選項：

選項1：將其作為查詢字符串傳遞

/pricing?OfferId=234&PromoId=345&CustomerId=543234

選項2：有三個API

/pricing/offer?id=234
/pricing/promo?id=345
/pricing/customer?id=543234

OfferId IMO， OfferId / PromoId / CustomerId視為資源的屬性。 因此將屬性作為查詢字符串傳遞。我更傾向於選項1。

選項2避免if else條件檢索資源，看起來更干凈，但它似乎支持REST設計的URL標准？

什么是設計URL的REST標准。 你會推薦哪個選項？

Answer 1

我更喜歡選項1。
選項2具有以下缺陷：

1. 它可能會使用戶感到困惑。 例如， /pricing/offer/234似乎代表Offer資源，而不是Pricing資源。
2. 在商業邏輯， Offer資源包含了Pricing ，但/pricing/offer/234代表權相反的方式。 似乎Pricing資源包含Offer資源。

實際上，選項1也存在一些問題。 例如，

/pricing?OfferId=234&PromoId=345&CustomerId=543234  

會得到三個Pricings，對嗎？ 它似乎

/pricings?OfferId=234&PromoId=345&CustomerId=543234  

更合理。

您可以考慮的另一個選項是選項3：

/offer/234/pricing
/promo/345/pricing
/cusomer/543234/pricing

希望它有所幫助。

Answer 2

最干凈並遵循標准路徑的方式是：

/pricing/offer/234
/pricing/promo/345
/pricing/customer/543234

布局為： /pricing/${offer|promo|customer|/${PathParamForId}

然后，您可以將其作為三個單獨的方法，每個方法用於提供/促銷/客戶。

然后，您只需確保您的API有詳細記錄，以便用戶了解路徑的預期行為。 （報價與促銷查詢之間的差異等）

Answer 3

這已經由@Freedom提出，但我認為它應該得到自己的答案和推理。

您想要檢索定價 - 但這並不意味着您必須使用pricing來啟動URL。

Promo ， Offer和Customer看起來像資源。 他們可能有自己的URL，比如offer/123 。 即使他們沒有URL，他們似乎仍然是Pricing的邏輯容器/組成元素。 所以Pricing應該是那些的子資源。

/offers/234/pricing
/promos/345/pricing
/customers/543234/pricing

如果定價也有自己的ID，您仍然可以添加其他方法來列出所有價格或通過該ID獲取它們：

/pricings
/pricings/12