如何处理REST API中的大量资源
我将一个REST接口绑定到现有的应用程序上，我很好奇最合适的解决方案是如何处理会返回大量数据（如果要检索它们的话）的资源。
该应用程序是一个现有的时间表系统，其中一个资源是一组用户的“时隙”。 这些资源的示例URI是：
/users/44/timeslots/
我已经阅读了很多与如何提供过滤资源来检索子集有关的问题，并且我已经有了一个解决方案。
我想知道如何（或者如果）我应该处理这种情况：在上面的URI上发布GET会从数十或数十万行中返回兆字节的数据，并且需要相当数量的服务器资源才能在第一名。
我发现HTTP代码413与一个太大的请求实体有关，但不适用于响应实体太大的情况
编辑：要清楚，我已过滤和分割的资源实施和考虑其他大型收集资源的分页。 我想适当地回应那些没有道理的请求（并且显然已经被构建URI的客户请求）。
你可以自由地设计你的URI，因为你想编码任何概念 。
因此，根据您的用户（人/机器），您可以将其用作基于问题空间或域的概念级别的拆分。 如你所说，你可能有这样的事情：
/users/44/timeslots/afternoon
/users/44/timeslots/offshift
/users/44/timeslots/hours/1
/users/44/timeslots/hours/1
/users/44/timeslots/UTC1624
一次也可以通过上面的想法/概念进行限制。 您可以通过添加查询/用户/ 44 /时隙来过滤更多内容？day = weekdays＆dow = mon
像这样使用或概念和过滤器自然会限制响应大小。 但是您需要尝试设计您的API， 而不是陷入这种情况 。 如果你的客户行为不当，给它一个400错误的请求。 如果服务器端出现问题，请使用5XX代码。
使用REST工具之一 - 超媒体和链接 （另请参阅HATEOAS）链接到超媒体的下一部分，利用您的域名可理解的“块状概念”（页面，时隙）。 无需下载兆字节，这对缓存也不利 ，影响可伸缩性/速度。
timeslots是一个集合资源，为什么不简单地在该资源上启用分页
请参阅此处：REST Web应用程序中的分页
调用不带页面信息的集合只需返回第一页（使用默认页面大小）
我应该只是让服务器遵守这个大规模的请求吗？ 我认为你不应该这样做，但这取决于你自己决定，服务器能否处理大量数据？ 你觉得它是一个有效的用例吗？
这个答案可能太弱，但这是我的团队如何处理它的。 像这样的大资源需要提供额外的过滤信息。 如果过滤信息不能保持特定范围内的大小，那么我们会返回一个内部错误（500）和一条适当的消息，以表示它没有正确使用RESTful API。
希望这可以帮助。
链接地址: http://www.djcxy.com/p/45395.html