RESTfulサービス用のURLデザイン

Question

私は検索したいPricingというリソースを持っています。 Offerは価格設定が可能で、PromoはPricingリソースを持つことができ、Pricingを割り当てることができる別のエンティティCustomerがあります。 OfferId/PromoId/CustomerIdのいずれかに基づいてPricingを取得したいとします。

このためURLを設計するには、私は2つの選択肢の中に実行しているよ：

オプション1：クエリ文字列としてパスを

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

オプション2：は3つのAPI

を持っています

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

IMO、OfferId/PromoId/CustomerIdはリソースの属性として扱われるべきである。したがって、属性をクエリ文字列として渡します。私はオプション1にもっと傾いています。

オプション2はリソースを取得するための条件があり、はるかにクリーナーに見えますが、URLデザインのREST標準をサポートしているようですか？

URLを設計するためのREST標準とは何ですか。どのオプションをお勧めしますか？

Answer 1

最もきれいになる方法と標準パス機能を、以下のようになります：

レイアウトされた状態で

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

：あなたは、オファー/プロモーションのために3つの別々の方法として、1それぞれを行うことができ/pricing/${offer|promo|customer|/${PathParamForId}

/顧客。

次に、ユーザーがパスの予想される動作を把握できるように、APIの文書化が必要です。 （プロモーション検索等対オファーとの差）

Answer 2

Iオプション2は、以下の欠点を有しているオプション1
を好む：

1. それはユーザを混乱させる可能性。たとえば、/pricing/offer/234が のように見える場合は、リソースを表し、Pricingリソースではありません。
2. ビジネスロジックでは、OfferリソースにはPricingが含まれていますが、逆の意味では /pricing/offer/234となります。 リソースを含むPricingリソースのように、 と思われます。

実際には、オプション1にも問題があります。例えば、

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

は3つの価格設定を得るでしょうか？それは、

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

と思われます。

あなたが考えることができます別のオプションは、オプション3である：

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

は、それが参考に願っています。

Answer 3

これはすでに@Freedomで提案されていますが、私はそれ自身の答えと推論に値すると思います。

価格を取得する必要がありますが、それでURLを開始する必要はありません。pricing

Promo,OfferおよびCustomerはリソースのように見えます。彼らはおそらくoffer/123のような独自のURLを持っています。 URLを持たなくても、Pricingの論理コンテナ/コンポジション要素のようです。したがって、Pricingはそれらのサブリソースである必要があります。

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

価格はあまりにも独自のIDを持っている場合、あなたはまだすべてのpricingsを一覧表示するか、そのIDでそれらを取得するための追加の方法を追加することができます。

/pricings 
/pricings/12