Question

我有一个名为Pricing的资源，我想要检索。 Offer可以定价，Promo可以拥有Pricing资源，还有另一个实体Customer可以映射Pricing。我想根据Pricing / OfferId / PromoId中的任何一个检索CustomerId。

要为此设计网址，我遇到两个选项：

选项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避免if else条件检索资源并且看起来更清晰但是它似乎支持REST设计的URL标准吗？

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

Answer 1

我更喜欢选项1 选项2具有以下缺陷：

可能会让用户感到困惑。例如，/pricing/offer/234似乎表示Offer资源，而不是Pricing资源。
在业务逻辑中，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}

然后，您可以将其作为三个单独的方法，每个方法分别用于offer / promo / customer。

然后，您只需确保您的API有详细记录，以便用户了解路径的预期行为。（报价与促销查询之间的差异等）

Answer 3

这已由@Freedom提出，但我认为它应该得到自己的答案和推理。

您想要检索定价 - 但这并不意味着您必须使用pricing启动网址。

Promo，Offer和Customer看起来像资源。他们可能有自己的网址，例如offer/123。即使他们没有网址，他们似乎仍然是Pricing的逻辑容器/组合元素。所以Pricing应该是那些的子资源。

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

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

/pricings
/pricings/12

RESTful服务的url设计

3 个答案: