Question

让我们考虑以下流向RESTfull API：

    API root      
       |  
       v  
   user list     
       |  
       v  
  user details  
       |  
       v  
  user messages

假设我有一个客户端使用API，我想从ID为42的用户检索消息。根据我一直在研究的内容，我的客户不应该知道如何“构建”网址，它应该遵循API提供的链接。

如何为ID为42的用户检索邮件？

我能想到的唯一方法是将整个API从它的根“走”到用户消息，这对我来说看起来不那么漂亮或高效。

例如：
1 - 获取/并获取用户列表的链接
2 - GET / user /？id = 42并获取ID为42的用户详细信息的链接 3 - GET / user / 42 /并获取用户42消息列表的链接
4 - GET / user / 42 / messages /并最终获得用户消息

我弄错了吗？根据罗伊的菲尔丁论文，这是正确的方法吗？或者可以假设消息url是“/ user / {id} / messages /”并直接发出请求？

Answer 1

在API根目录中使用网址模板。让客户端在运行时使用API根目录。它应该查找名为“user-messages”的URL模板，其值为“/ user / {userid} / messages /”。然后让客户端在模板中用“42”替换“{userid}”并对结果URL进行GET。您可以为所有必需的常用用例添加所需的这些URL模板。

此解决方案与“经典”Web API之间的区别在于URL的后期绑定：客户端在运行时使用其模板读取API根目录 - 而不是使用URL模板的知识编译客户端。

有关网址模板的一些信息，请查看HAL媒体类型：http://stateless.co/hal_specification.html

我前段时间写过这篇文章来解释超媒体的好处：http://soabits.blogspot.dk/2013/12/selling-benefits-of-hypermedia.html

Answer 2

我相信你真正关心的是你应该如何实施HATEOAS。现在因为它是REST规范的一个组成部分，所以建议每个实体都应该包含它所包含的子实体的链接。在您的情况下，API ROOT应显示每个“用户”具有链接（/ root / users / {id}）的用户列表，以及相应用户的详细信息。每个用户详细信息实体将包含指向“消息”列表的链接（/ root / users / {id} / messages），最后，inturn也包含指向实际消息详细信息的链接（/ root / users / { ID} /消息/ {MESSAGEID}）。这个概念非常有用（因此也是规范的一部分），因为客户端不需要知道实体所在的URL。例如，如果您的用户位于http://users.abc.com/rest/users/ {id}，但您的邮件位于http://messages.abc.com/rest/ {userId} / messages / {messageId}，则包含“邮件”列表的用户实体已经拥有链接嵌入式指向不同服务器上的正确资源。

现在说，我实际上并没有看到很多REST实现（我必须承认我没有太多的经验，但足以发表意见）HATEOAS被广泛使用。在大多数情况下，资源几乎总是在同一服务器（环境）上，并且资源的路径几乎总是相对于根URL。因此，客户端在解析来自对象的嵌入式链接时没有意义。他们可以自己生成一个，特别是当客户端希望直接提供对资源的访问时（如果您已经知道messageId是什么，则直接查看消息而不获取用户实体）。

最后，这一切都取决于您希望REST实现与规范的接近程度以及您将拥有哪种类型的客户端。我的2美分将是：如果你有时间，用HATEOAS实现REST并为此感到自豪:)。有些库可以使这个实现（HATEOAS）对你的REST实现有点透明（我相信spring有一个，虽然不是很成熟。你可以看看它here）。如果你像我一样，没有太多时间走这条路，我想你可以继续正常的REST实现而不用HATEOAS，你的客户仍然可以使用它（或者我希望如此！）

希望这有帮助！

Answer 3

我发现这篇关于黑客网址的文章：Avoid hackable URLs 关于这个问题的主题在评论部分有一个非常有趣的讨论。

从资源ID使用REST API端点

3 个答案: