4

REST API 似乎天生就“健谈”，因为您在响应中提供了指向子资源的链接，而不是直接嵌入它们。例如，假设您有一个产品和评论，当您执行GETon 时/api/products/123，您可能会得到这样的结果：

{
   "name": "A monkey"
   "cost", "$5000.00",
   "reviews": [
        "/api/reviews/1",
        "/api/reviews/2",
        "/api/reviews/3"
        ...
        "/api/reviews/2071",
    ]
}

要显示所有评论，您需要执行 2071 个GET请求。也许其中一些可以通过分页来缓解（可能一次只显示 10 条评论）。还有其他方法可以缓解吗？是否有可接受的“聚合表示”可用于最大限度地减少闲聊？

4

2 回答 2

4

可能这取决于你如何看待它。由于评论总是绑定到某些产品，您可以将其视为/api/products/123/reviews包含猴子所有评论的资源。然后在GET那里做可以返回类似的东西

[{ "id": "1", "reviewer": "vivin", ... }, ... ]

（可能在该列表上有一些分页）。这样GET就/api/products/123/reviews/2071只返回具体的review

{ "id": "2071, "reviewer": "subsub", "The monkey stinks." }
于 2013-09-19T17:12:16.767 回答
2

在这种特殊情况下，是的，但是，如果它定义明确并且按照原始规范使用缓存，那么任何后续请求都应该命中缓存，而不是完整的 API。

可缓存 就像在万维网上一样，客户端可以缓存响应。因此，响应必须隐式或显式地将自己定义为可缓存或不可缓存，以防止客户端重复使用陈旧或不适当的数据来响应进一步的请求。管理良好的缓存部分或完全消除了一些客户端-服务器交互，进一步提高了可伸缩性和性能。

http://en.wikipedia.org/wiki/Representational_state_transfer

于 2013-09-19T17:01:00.350 回答