8

我有一个Pricing我想要检索的资源。一个Offer可以有定价，一个Promo可以有Pricing资源，还有另一个Customer可以Pricing映射的实体。我想Pricing根据OfferId/ PromoId/之一进行检索CustomerId。

要为此设计 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应该被视为资源的属性。因此将属性作为查询字符串传递。我更倾向于选项 1。PromoIdCustomerId

选项 2 避免了 if else 条件来检索资源并且看起来更干净，但它似乎支持 URL 设计的 REST 标准？

设计 URL 的 REST 标准是什么。你会推荐哪个选项？

4

3 回答 3

5

我更喜欢方案一
，方案二有以下缺陷：

  1. 它可能会使用户感到困惑。例如，/pricing/offer/234似乎代表一种Offer资源，而不是一种Pricing资源。
  2. 在业务逻辑中，Offer资源包含 a 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-26T03:03:40.163 回答
4

最干净并遵循标准路径的方式是：

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

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

然后，您可以将其作为三种单独的方法来执行，每种方法用于报价/促销/客户。

然后你只需要确保你的 API 有很好的文档记录，这样用户就可以知道路径的预期行为。（优惠与促销查找等之间的区别等）

于 2013-09-26T01:45:10.780 回答
0

@Freedom已经建议了这一点，但我认为它值得自己的答案和推理。

您想检索定价 - 但这并不意味着您必须以它作为 URL 的开头pricing。

Promo，Offer并且Customer看起来像资源。他们可能有自己的 URL，例如offer/123. 即使它们没有 URL，它们似乎仍然是Pricing. 所以 aPricing应该是那些的子资源。

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

如果定价也有自己的 ID，您仍然可以添加其他方式来列出所有定价或通过该 ID 获取它们：

/pricings
/pricings/12
于 2015-03-27T18:07:29.420 回答