Question

我正在将REST接口用于现有应用程序，我很好奇最合适的解决方案是什么来处理资源，如果要检索这些资源会返回过多的数据。

应用程序是现有的时间表系统，其中一个资源是一组用户的“时间段”。这些资源的示例URI是：

/users/44/timeslots/

我已经阅读了很多与如何为此资源提供过滤以检索子集有关的问题，我已经有了解决方法。

我想知道如何（或者是否）我应该处理在上面的URI上发出GET将从数十或数十万行返回兆字节数据的情况，并且实际上需要相当多的服务器资源首先回应。

编辑：为了清楚起见，我对已实施的资源进行了过滤和拆分，并考虑了其他大型集合资源的分页。我想对那些没有意义的请求做出适当的回应（显然是由构建URI的客户端请求的）。

Answer 1

您可以根据需要编码任何概念来自由设计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＆amp; dow = mon

使用或概念和这样的过滤器自然会限制响应大小。但是你需要尝试设计你的API 不要进入那种情况。如果您的客户端行为不当，请给它 400 Bad Request 。如果服务器端出现问题，请使用5XX代码。

利用REST的其中一个工具 - 超媒体和链接（另请参阅HATEOAS）链接到超媒体的下一部分，使用“块状概念”，您的域名理解（页面，时间段）。无需下载那些不利于缓存的兆字节，这会影响可扩展性/速度。

Answer 2

timeslots是一个集合资源，为什么你不能简单地在该资源上启用分页

在没有页面信息的情况下调用get集合只会返回第一页（具有默认页面大小）

我应该让服务器遵守这个庞大的请求吗？ 我认为你不应该这样，但是由你来决定，服务器可以处理大量的数据吗？你发现它是一个有效的用例吗？

Answer 3

这可能太弱了，但这是我的团队处理它的方式。需要大量资源才能提供额外的过滤信息。如果过滤信息不是为了将大小保持在特定范围内，那么我们返回一个带有相应消息的内部错误（500），以表示无法正确使用RESTful API。

希望这有帮助。

Answer 4

或者，您也可以（按照其他人的建议）将资源分成不同的URL，这些资源位于不同的URL（代表部分或页面，或者原始资源的其他过滤版本）。