我们的单页应用和移动应用使用了一个不那么RESTful的API。
自从过去以来，URI并不是这样，所以URI已经返回了对特定页面有用的东西。这导致了大量的端点，其中许多端点具有非常相似的响应。
Datawise我们拥有数十个相关资源的资源。在某些情况下，我们希望返回相关的资源，或者其中一些，以及其他我们不需要的情况。有些回复很慢，因此我们在特定情况下只需要它们。
我们遇到的问题是将数据拆分为有意义的URI，而无需另外请求获取每个相关资源。
因此，我们考虑了/ batch端点，其中包含正文中的多个请求的POST请求可以在服务器上并行执行这些请求。像这样https://developers.facebook.com/docs/graph-api/making-multiple-requests这样我们就可以将数据拆分成有意义的URI，而不必为每个页面发出20个API请求。
这是处理相关资源的可接受方式吗？或者为我们可能需要的每个响应设置一个URI会更好吗？
答案 0 :(得分：2)
HTTP / 2将允许您在单个连接上复用请求，从而消除此问题。
同时，我建议您不要违反当前解决方案的任何REST约束。但是，创建一批请求会破坏资源标识约束，这将对表示的可缓存性产生重大影响。
答案 1 :(得分：0)
批处理很好 - 不要让RESTful设计模式引导你走上糟糕表现的道路。
您的批处理解决方案可能设计为可以分批调用每个可以批处理的部分。如果是这样的话，为每个人创建RESTful端点可能会很简单，对于那些希望以多次往返为代价的人来说。
您还可以使用查询参数来选择不同的打包资源返回。例如，对于用户，您可以使用以下内容：
GET /v1/users/1?related={none,all,basic}
您还可以使用字段选择器：
GET /v1/users/1?data=addresses,history