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服务的网页设计

回答

相关问题