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

我将REST接口绑定到现有应用程序上，我很好奇最合适的解决方案是如何处理会返回过高数据量的资源被检索。如何处理REST API中的大量资源

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

/users/44/timeslots/

我已经读了很多，涉及到如何提供过滤该资源检索子问题，我已经有一个解决方案。

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

在这些情况下，是否有一个HTTP响应被惯例使用？
我发现HTTP代码413，其涉及太大请求实体，而不是一个，这将是适当的，用于当响应实体将太大
是否有限制响应或告诉替代常规客户认为这是一个愚蠢的要求？
我应该让服务器遵从这个大规模的请求吗？

编辑：要清楚，我有过滤和实现的资源的分裂，并考虑对其他大集合资源分页。我想适当地回应那些没有道理的请求（并且显然已经被构建URI的客户请求）。

来源

2011-03-25 Alex Taylor

这样的请求返回那么多的数据实际上是一个问题吗？或者，您是否仅仅试图安全防范意外检索，这会导致浪费服务器资源和带宽？ – 2011-03-25 22:31:07

如果请求很愚蠢，那么不要实现该资源的处理程序，并在某人错误地构造该URI时返回404。 ......然后在构建URL的时候击败他们:-) – 2011-03-26 00:01:00

@ jeff-hall返回那么多数据没有问题，它只是防止意外检索的安全措施，正如你所提到的。 – 2011-03-26 00:32:47

您可以自由设计您的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）链接到你的超媒体的下一部分，利用“块类似的概念”，你的域理解（页，时间时隙）。无需下载兆字节，其中不适用于高速缓存，这会影响可伸缩性/速度。

来源

2011-03-25 23:18:53

HATEOS ..哈哈。感谢@Darrel Miller纠正错字！ – 2011-03-25 23:43:10

+1：对于分页建议 – jfs 2011-03-25 23:45:17

@Derick我辩论实际将其改为超文本约束。普遍的共识似乎是HATEOAS首字母缩略词不能帮助任何人，“超文本约束”是首选术语。 – 2011-03-25 23:54:12

这可能太弱了答案，但这是我的团队如何处理它。像这样的大资源需要提供额外的过滤信息。如果过滤信息不能保持特定范围内的大小，那么我们会返回一个内部错误（500）和一条适当的消息，以表示它没有正确使用RESTful API。

希望这会有所帮助。

来源

2011-03-25 21:44:41 James

HTTP 500通常不适用于故意错误代码。当软件意外失败或遇到异常情况时，应使用500。相反，返回HTTP 400错误请求是合适的。看到这个相关的StackOverflow [post]（http://stackoverflow.com/questions/3290182/rest-http-status-codes/3290198#3290198）。 – 2011-03-25 22:32:52

时隙是一家集资源，为什么你就不能简单地对资源实现分页

在这里看到：Pagination in a REST web application

呼吁收集得到，而不页面信息直接返回第一页（使用默认页面大小）

我应该让服务器遵从这个大规模的请求吗？ 我认为你不应该这样做，但这取决于你自己决定，服务器可以处理大量数据吗？你觉得它是一个有效的用例吗？

来源

2011-03-25 23:44:49 LiorH

啊哈！用例是魔术词。这个问题对于分页场景也是有效的，是一个值用例吗？如果没有，为什么浪费时间来实施它。这又回到了原来的问题，为什么我们要讨论实现一个端点，这个端点看起来并不是一个用例，并且如果有人使用它的话可能会导致问题。 – 2011-03-25 23:58:00

正确，没有过滤器直接请求此资源的Usecase。我只是想返回对该无效请求的适当响应。 – 2011-03-26 00:37:51

@Alex 404对我来说似乎最符合逻辑。返回400会表明客户端请求的格式不正确，如果他们请求“正确”，它会返回一个值。 – 2011-03-26 03:10:20

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

回答

相关问题