RESTful服务的java 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

IMO，OfferId/PromoId/CustomerId应被视为资源的属性。因此，将属性作为查询字符串传递。我更倾向于选择1

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

设计URL的REST标准是什么。你会推荐哪种选择

Answer 1

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

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

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

然后，您可以将其作为三种不同的方法来执行，每种方法都适用于offer/promo/customer

然后，您只需确保您的API有良好的文档记录，以便用户了解路径的预期行为。（优惠与促销查找等之间的差异）

Answer 2

这已经由@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

Answer 3

我更喜欢选项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?OfferId=234&PromoId=345&CustomerId=543234  

更合理

您可以考虑的另一个选项是选项3：

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

希望对你有帮助