RESTful服務的網頁設計

我有一個名爲Pricing的資源，我想要檢索。一個Offer可以有定價和一個Promo可以有Pricing資源，並有另一個實體Customer與Pricing可以映射。我想根據OfferId/PromoId/CustomerId之一檢索Pricing。RESTful服務的網頁設計

設計URL對於這一點，我運行到兩個選項：

選項1：把它作爲查詢字符串

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

選項2：有三個API

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

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

選項2避免如果其他條件檢索資源，看起來更清潔，但似乎是支持REST標準的URL設計？

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

來源

2013-09-25 Pankaj

我覺得一般的共識是，你應該有3個網址像/定價/優惠/ 1234。請參閱示例http://code.msdn.microsoft.com/Build-truly-RESTful-API-194a6253 –

，這將是最乾淨的方式和遵循標準的尋路是：

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

的佈局之中：/pricing/${offer|promo|customer|/${PathParamForId}

然後你可以做三個單獨的方法每一個報價/促銷/顧客。

然後，您只需確保您的API有充分的文檔記錄，以便用戶知道路徑的預期行爲。（報價之間差Vs促銷查找等）

來源

2013-09-26 01:45:10 Welsh

但是，從URL本身看來，它似乎建議我們檢索offer/promo/customer，而不是定價 –

除非您將其視爲「我們正在檢索ID爲X的促銷/促銷/客戶類別的定價」。需要更多關於對象佈局/存儲和業務邏輯的詳細信息，以瞭解最佳結構和必要條件。無論哪種方式，它不應該使用查詢參數，而是路徑參數。 – Welsh

我也有@AdrianShum相同的意見。在選項1的情況下，根據特定標準檢索定價資源是不言自明的，在選項2的情況下，我們將不得不讓讀者知道按照您的建議在特定環境下閱讀。爲什麼你不贊成使用查詢參數？ – Pankaj

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

它可能混淆用戶。例如，/pricing/offer/234似乎是代表Offer資源，而不是Pricing資源。
在商業邏輯，Offer資源包含Pricing，但 /pricing/offer/234代表權相反的方式。看起來像就像一個Pricing資源包含一個Offer資源。

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

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

會得到三個價格，對不對？看來

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

是比較合理的。

你可以考慮一下另一種方法是選擇3：

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

希望它有幫助。

來源

2013-09-26 03:03:40 Freedom

這已被@Freedom建議，但我認爲它應該有自己的答案和推理。

您想檢索定價 - 但這並不意味着您必須使用它開始網址pricing。

Promo,Offer和Customer看起來像資源。他們可能擁有自己的網址，例如offer/123。即使他們沒有URL，他們仍然是Pricing的邏輯容器/組合元素。所以Pricing應該是這些的子資源。

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

如果定價都有自己的ID也一樣，你仍然可以添加額外的方式列出所有pricings或由ID讓他們：

/pricings 
/pricings/12

來源

2015-03-27 18:07:29 Kapep

RESTful服務的網頁設計

回答

相關問題