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

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

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设计的澄清或示例.

我已经注意到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模式.与往常一样,您的具体目标和需求将影响您的选择,但简单性始终是目标的良好目标.

创建产品应该只是一个POST

http://server/product

更新产品应该只是一个PUT

http://server/product/$id

获得产品应该只是一个GET

http://server/product/$id

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

http://server/product/$id

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

当有人做GET时http://server/product/$id,他们会得到某种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动词将它们暴露给宇宙.