如何构建REST资源层次结构? [英] How to structure REST resource hierarchy?

问题描述

我是服务器端Web开发的新手，最近我阅读了很多有关实现RESTful API的内容.我仍然坚持的REST API的一方面是如何构建URI层次结构，该层次结构标识客户端可以与之交互的资源.具体来说，我要确定层次结构的详细程度以及在资源由其他资源类型组成的情况下的处理方式.

I'm new to server side web development and recently I've been reading a lot about implementing RESTful API's. One aspect of REST API's that I'm still stuck on is how to go about structuring the URI hierarchy that identifies resources that the client can interact with. Specifically I'm stuck on deciding how detailed to make the hierarchy and what to do in the case of resources being composed of other resource types.

这里有一个例子，希望能显示出我的意思.想象一下，我们有一个Web服务，使用户可以从其他用户那里购买产品.因此，在这种简单情况下，有两个顶级资源用户和产品.这就是我开始构建URI层次结构的方式，

Here's an example that hopefully will show what I mean. Imagine we have a web service that lets users buy products from other users. So in this simple case, there are two top level resources users and products. Here's how I began to structure the URI hierarchy,

对于用户:

/users
      /{id}
           /location
           /about
           /name
           /seller_rating
           /bought
           /sold

对于产品:

/products
         /{id}
              /name
              /category
              /description
              /keywords
              /buyer
              /seller

在这两种情况下，每个层次结构中的对象都引用另一个层次结构中的对象的子集.例如，/users/{id}/bought是某些用户购买的产品的列表，它是/products的子集.另外，/products/{id}/seller引用了销售特定产品的用户.

In both of these cases objects in each hierarchy reference a subset of the objects in the other hierarchy. For example /users/{id}/bought is a list of the products that some user has bought, which is a subset of /products. Also, /products/{id}/seller references the user that sold a specific product.

由于这些URI引用了其他对象或其他对象的子集，因此API是否应支持以下内容:/users/{id}/bought/id/description和/products/{id}/buyer/location?因为如果支持这些类型的URI，那么如何阻止此类/users/{id}/bought/{id}/buyer/bought/{id}/seller/name或同样令人费解的事情呢?另外，在这种情况下，由于服务器中的路由器必须解释任意长度的URI，您将如何处理路由?

Since these URI's reference other objects, or subsets of other objects, should the API support things like this: /users/{id}/bought/id/description and /products/{id}/buyer/location? Because if those types of URI's are supported, what's to stop something like this /users/{id}/bought/{id}/buyer/bought/{id}/seller/name, or something equally convoluted? Also, in this case, how would you handle routing since the router in the server would have to interpret URI's of arbitrary length?

推荐答案

目标是构建方便的资源标识符，不要尝试交叉引用所有内容.您不必在URL表示中重复数据库关系:)

The goal is to build convenient resource identifiers, don't try to cross-reference everything. You don't have to repeat your database relations in URL representation :)

像/product/{id}/buyer这样的链接应该永远不存在，因为该资源已经存在标识符:/user/{id}

Links like /product/{id}/buyer should never exist, because there already is identifier for that resource: /user/{id}

尽管可以使用/product/{id}/buyers-list，因为购买者列表是其他情况下不存在的产品的属性.

Although it's ok to have /product/{id}/buyers-list because list of buyers is a property of product that does not exist in other contexts.

这篇关于如何构建REST资源层次结构?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！