rest资源设计_REST资源何时应获得其自己的地址？

rest资源设计

在纯粹的REST方法中，所有端点（起始端点除外）都是不透明的，因此不需要发布其各种详细信息。 即使使用这种方法，本文中的要点也很重要，因为服务器逻辑将必须确定何时需要结束点。

介绍

在REST体系结构中，实体或资源（ 对于本文的其余部分将使用术语“实体”）可能具有也可能没有其自己的地址。例如，假设我们有一个库存应用程序，供商人用来销售其产品。立即可以看到一个产品实体。它的URL类似于：/ product / {id}

现在，销售产品的商人可以将自己的评论添加到产品中。例如， ”
“ 星期五 卖得很好 ”或“ 如果产品没有开始销售，请考虑更改价格 ”。一个产品可以有0 .. *注释。如前所述，产品具有自己的地址：/ product / {id}，例如/ product / 1231233

和这样的响应负载

{"id":"1231233","type":"Beer","comments": [{"id":"1","comment":"Sells very well on Fridays"                 }, {"id":"2","comment":"Consider changing price if product doesn't start selling"  }]}

可以看出，有效负载返回Comment对象的集合。每个评论都应该有自己的地址，还是可以将它们嵌入产品响应中？为了帮助回答这个问题，应考虑以下内容。

实体在包含实体上下文之外是否有任何意义？

如果实体（例如注释）在其包含的实体（例如产品）之外具有含义，则它们应具有自己的地址。例如，假设实体是学生，并且学生返回了他/她所学习的大学列表。这些大学在学生之外具有自己的含义。因此，显然大学应该有自己的地址。在“活动/注释”业务情景中，“注释”仅针对活动存在。没有其他实体会引用它们或需要引用它们。因此，需要考虑其他方面。

是否需要对单个实体执行操作？

是否应该允许客户端创建，读取，更新或删除单个实体？这些必须分开考虑。

写：创建，更新，删除

在产品/评论场景中，永远不会在产品外部或没有产品的情况下创建评论。它实际上是添加到产品中的。这可以视为对产品的部分更新。但是，对现有注释的更新或删除也可以视为产品的部分更新。这会造成如何使用产品的部分更新来区分创建/更新和删除注释的复杂性。如果需要这样做，则为注释创建上下文地址（指示产品/注释的层次结构性质）然后允许客户向其发送POST，PUT，PATCH，DELETES会更简单。

范例网址：/ product / 1231233 / comment / 1

读

在某些情况下，包含父实体的实体可能不会返回有关子实体的所有信息。例如，再次考虑产品–>评论场景。假设评论很大。这意味着产品的有效载荷也非常大。在这种情况下，对于产品而言，仅返回评论摘要，如果客户希望完整的实体提出单个请求，则可能更为谨慎。同样，如果要获得一个单独的实体会付出巨大的性能成本（例如，必须调用第三方API来获取有关注释的所有信息），那么将URL链接发送给实体（而不是而不是实际实体的内容。

N + 1问题

如果需要单独读取，请注意不要引入N + 1问题。例如，假设一个产品可能有100条注释。如果客户需要所有信息，Product API将仅返回Comment的摘要以及指向每个评论的链接。但是，如果客户端希望每一个注释，则意味着现在将有100个HTTP请求。如果这是一种潜在的情况，则应考虑将所有评论汇总到产品中的辅助端点。这类似于API网关模式。

端点表面积

在任何发布合同的体系结构中，如果合同太多，开发人员就很难理解。大多数知名的API（例如PayPal，Amazon，Twitter，Google）通常只有大约20至30个地址。这是一个好目标。如果有5,000个不同的地址，它可能会变得太大而难以控制等。

总之，决策图提供了有关您应该做什么的指南。

翻译自: https://www.javacodegeeks.com/2018/01/rest-resource-get-address.html

rest资源设计