14

因此，RESTful API 的一般模式是返回一个带有嵌入式链接的对象，您可以使用它来检索相关对象。但有时为了方便起见，您想一次拉回整个对象图块。

例如，假设您有一个包含客户、订单和退货的商店应用程序。您想同时显示客户 ID 12345 的个人信息、所有订单和所有退货。（可能有充分的理由不总是退回订单和退货以及客户个人信息。）

执行此操作的纯 RESTful 方式类似于：

  1. GET /
    • 返回链接模板列表，包括一个用于查询客户的模板
  2. GET /customers/12345（基于来自的链接模板/）
    • 返回客户个人信息
    • 返回链接以获取该客户的订单和退货
  3. GET /orders?customerId=12345（来自/customers/12345回复）
    • 获取客户 12345 的订单
  4. GET /returns?customerId=12345（来自/customers/12345回复）
    • 获取客户 12345 的退货

customers但是，一旦您有了URI，就能够在一个查询中将所有这些都拉回来，那就太好了。这种便捷查询是否有最佳实践，您想在其中嵌入部分或全部链接而不是发出多个请求？我在想类似的事情：

GET /customers/12345?include=orders,returns

但如果人们有办法做到这一点，我宁愿不只是编造一些东西。

（FWIW，我不是在开一家商店，所以我们不要争论这些是否是模型的正确对象，或者你将如何深入研究实际产品，等等。）

更新添加：看起来在HAL中这些被称为“嵌入式资源”，但在显示的示例中，似乎没有任何方法可以选择要嵌入的资源。我发现一篇博客文章提出了类似于我上面描述的内容，embed用作查询参数：

GET /ticket/12?embed=customer.name,assigned_user

这是一种标准或半标准的做法，还是只是某个博主编造的？

4

1 回答 1

1

由于必须为支持它们的每个链接关系记录这些类型参数的语义，并且这或多或少是您必须编码的东西，我不知道有什么可以从中受益有一个标准的表达方式。URL 结构更有可能由服务器返回的最简单或最谨慎的内容驱动，而不是任何特定的标准或最佳实践。

也就是说，如果您正在寻找灵感，您可以查看 OData 使用$expand 参数所做的事情，并从中建模您的链接关系。请记住，您仍然应该清楚地定义关系的契约，否则客户端程序员可能会看到类似 OData 的约定并假设（错误地）您的应用程序完全符合 OData 并且表现得像一个。

于 2013-11-16T04:46:31.737 回答