如何处理REST API中的大量资源

Question

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

该应用程序是现有的时间表系统,其中一个资源是一组用户的"时间段".这些资源的示例URI是:

/users/44/timeslots/

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

我想知道如何(或者如果)我应该处理在上面的URI上发出GET将从数十或数十万行返回兆字节数据的情况,并且需要相当数量的服务器资源来实际响应第一名.

• 在这些情况下,是否存在惯例使用的HTTP响应？
  我发现HTTP代码413与Request实体相关,该实体太大,但不适用于当Response实体太大时
• 是否存在限制响应或告诉客户这是一个愚蠢的请求的替代约定？
• 我应该让服务器遵守这个大规模的请求吗？

编辑:要清楚,我已经过滤和拆分实现的资源,并考虑了其他大型集合资源的分页.我想适当地回应那些没有意义的请求(显然是由构建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&dow = mon

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

利用REST的一个工具 - 超媒体和链接(另请参阅HATEOAS)链接到超媒体的下一部分,利用您的领域理解的"块状概念"(页面,时间段).无需下载兆字节,这也不利于缓存,这会影响可扩展性/速度.