对于树层次结构，REST URL架构应该如何？

Question

我们假设我有商店，商店货架和货架上的产品。 因此，为了获得商店货架上的产品列表，我将使用以下请求：

GET http://server/stores/123/shelves/456/products

从这里，我如何获得个别产品？ 我应该使用：

GET http://server/products/789

要么：

GET http://server/stores/123/shelves/456/products/789

第一种方法更简洁，因为一旦获得产品列表，如果您只想查看特定产品的详细信息，则不关心它属于哪个商店。 但是，第二种方法更符合逻辑，因为您正在查看特定商店中特定货架的产品。

同样，PUT / DELETE操作怎么样？

DELETE http://server/stores/123/shelves/456/products/789

要么：

DELETE http://server/products/789

为这样的树层次结构设计模式的正确方法是什么？

PS如果我误解了有关REST架构的一些内容，请提供有关如何使其更好的示例。 有太多人喜欢说“REST不是CRUD”和“REST不是RPC”，然后绝对没有提供良好RESTful设计的澄清或示例。

Answer 1

我已经注意到RESTful URI设计的两种方法： 分层和过滤

我认为层次结构过于冗长，有可能存在冗余端点（而不是DRY），并且伪装成您真正感兴趣的资源状态（毕竟，REST = 代表性状态转移）。

我赞成简单的URI

简单优雅。 我会选择像这样的URI结构

GET http://server/products/789

因为我对产品资源的状态感兴趣。

如果我想要所有属于特定商店特定货架的产品，那么我会这样做

GET http://server/products?store=123&shelf=456

如果我想在特定货架上的特定商店创建产品，那么我会发布

{
    product: {
        store: 123,
        shelf: 456,
        name: "test product"
    }
}

通过

POST http://server/products

最终，它是tomayto，tomahto

REST不需要一个在另一个上。 但是，根据我自己的经验，使用将单个实体映射到单个端点的RESTful API（例如：iOS上的RestKit对象映射）而不是根据传递的参数将实体映射到许多不同的端点更有效。

关于REST

就REST而言，它不是协议，也没有RFC。 它与HTTP / 1.1 RFC紧密相关，作为实现其CRUD操作的一种方式，但许多软件工程师会认为REST不依赖于HTTP。 我不同意并考虑诸如猜想，因为UCI的Roy Fielding的原始论文（ http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm ）解释了REST和HTTP /的深层次连接1.1。 您也可以享受Roy对该主题的看法： http ： //roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven 。

REST定义的原则可以应用于其他协议，但REST是为互联网构建的，而HTTP是万维网的协议。

REST与RPC

RPC就是要调用远程函数，而且是以动词为中心的 。

REST就是使用CRUD约定来处理数据，具体取决于CRUD操作如何应用于给定的数据类型并且是以名词为中心的 。

您可以使用REST或RPC完成相同的操作，但REST遵循DRY原则，因为对于每个URI，您可以执行4个操作，而RPC需要每个操作的端点。

PS

这很大程度上是我的看法，并且基于我的经验，但我希望它能说明如何最有效地设计RESTful URI模式。 与往常一样，您的具体目标和需求将影响您的选择，但简单性始终是目标的良好目标。

Answer 2

创建产品应该只是一个POST

http://server/product

更新产品应该只是一个PUT

http://server/product/$id

获得产品应该只是一个GET

http://server/product/$id

删除产品应该只是一个删除

http://server/product/$id

您应该使用那里的http方法从更简单的uri结构中获取更多功能。 如果创建产品需要传递商店和货架作为要求，那么这些应该在POST的主体中传递（或者如果您要更换货架，则传递PUT）。

当有人对http://server/product/$id进行GET时，他们会得到某种xml / json响应，对吧？ 那是什么样的？ 创建或更新的传入数据应在请求正文中以相同的方式进行POST或PUT。 这就是你如何通过商店和货架，而不是通过uri。 uri应该尽可能简单，只需指向资源（产品），使用http动词来区分功能。

如果你想获得货架23的内容，你可以去GET

http://server/shelf/23

当您这样做时，您将获得一个json / xml / custom媒体类型文档，其中包含货架数据和一组产品元素，其中包含返回其产品uri的链接。

如果您希望能够将产品23从一个架子移动到另一个架子，那么您需要进行PUT操作

http://server/product/23 

在PUT的主体中，您可以选择代表您的产品，但使用更新的货架。

一开始这是一种奇怪的思维模式，因为你不是在处理整个系统的功能，而是专注于资源（产品，货架，商店）并使用http动词将它们暴露给宇宙。

Answer 3

由于产品可能在几个商店或几个货架（类别？），我会让每个产品都有一个唯一的数字，无论它在层次结构中的位置如何。 然后使用扁平产品编号。 这使得API在您的商店中移动某些产品时更加稳定。

简而言之，不要在API中添加不必要的冗余。 要获得货架清单商店ID就足够了，对于产品清单，货架ID就够了......等等。

Answer 4

不要基于URL结构设计REST api。 以下是我认为您应该如何设计REST API。

尝试定义REST接口而不讨论哪些链接将包含在哪些资源中，就像讨论RPC接口并忽略参数和返回值一样。

Answer 5

看起来你正在尝试构建许多不同的用例，但所有内容都被构建到一个超级服务中。 打破它会更好。

http://server/product_info/123123 or http://server/product_info?product=123123
http://server/product_inventory?store=123&shelf=345

那么你也可以支持：

http://server/product_inventory?store=123

然后PUT和DELETE对于更改库存或添加新产品有意义。