单个请求请求太大资源或太多资源时的HTTP状态代码 [英] HTTP status code when single request asks for too large resource or too many of them

问题描述

在下列情况下，有人知道哪个HTTP状态代码是正确的吗？

Does somebody know which HTTP status code is the right one for the following situation?

匿名客户端可以从RESTful API的集合中请求一系列项目 GET / collection /？range_start = 100& range_end = 200 。示例查询返回包含100个项目的列表（以JSON格式）。对于客户可以请求多少项，还有一个限制，比方说300。如果客户要求例如[100,1100]范围内的1000个项目，那么响应状态代码应该是什么？超出限制的700个项目是什么意思？

An anonymous client can request a range of items from a collection from RESTful API with GET /collection/?range_start=100&range_end=200. The example query returns a list with 100 items (in JSON). There is also a limit, lets say 300, for how many items the client can request. What should the response status code be if the client asks for example 1000 items in the range [100, 1100] what means 700 items over the limit?

应该是400错误请求，403禁止，409冲突，416请求范围不满足（？）或422不可处理实体？你会推荐什么？

Should it be 400 Bad Request, 403 Forbidden, 409 Conflict, 416 Requested Range Not Satisfiable(?) or 422 Unprocessable Entity? What would you recommend?

一个相关的问题和答案建议409，但情况略有不同：
https://stackoverflow.com/a/13463815/638546

A related question and answer propose 409 but the situation is slightly different: https://stackoverflow.com/a/13463815/638546

推荐答案

403听起来是最合适的选择。它基本上是说nu-uh。你不会看到那个。，这就是这里的情况。

403 sounds like the most appropriate choice. It basically says "nu-uh. You don't get to see that.", which is pretty much the case here.

< a href =http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.4> 10.4.4 403禁止使用

服务器理解请求，但拒绝履行请求。
授权无效，请求不应重复。 [...]

10.4.4 403 Forbidden

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. [...]

当然，回复机构包含原因<是个好主意/ em>你拒绝了这个请求。

Of course, it'd be a good idea for the response body to include the reason you're refusing the request.

在我看来，所有其他代码都有特定的含义，不符合他们在这里的使用。

All the other codes seem to me to have specific meanings that disqualify their use here.

400 不太合适，因为请求有效，您理解它就好了;它只是要求你提供超过你愿意立即发送的信息。

400 is not quite appropriate because the request is valid, and you understand it just fine; it's just asking for more than you're willing to send at once.

409 是不合适的，因为它与状态特别相关资源。 （它适用于您链接的问题，因为在这种情况下，错误是添加到已经已满的集合。但是，在您的情况下，它不是有问题的资源;它是请求。）此外，

409 is not appropriate because it's specifically related to the "state" of the resource. (It is appropriate for the question you linked, because in that case the error was adding to a collection that was already "full". In your case, though, it's not the resource that has a problem; it's the request.) Also,

此代码仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许。

This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request.

其中重新提交标准意味着重复。在这种情况下，无论客户端做什么，该请求都将无效。

where by "resubmit" the standard means "repeat". In this case, no matter what the client does, that request will be invalid.

416 特指范围标题，因此它完全出局了。

416 specifically refers to the "Range" header, so it's out altogether.

417 同样指的是一个标题字段（在本例中为Expect），所以它同样出来了。

417 likewise refers to a header field (in this case "Expect"), so it's likewise out.

422 是不合适的，因为它特别意味着您发送了一个语法正确的实体，但仍然没有损坏。由于GET传统上没有请求体（没有实体），因此没有什么是不可处理的。如果客户端正在发送请求，那么您可能几乎有一个案例......但是，您还必须为RESTful API要求POST不更新任何内容的原因做好准备。

422 is not appropriate because it specifically means you sent an entity that is syntactically correct, but is still broken. Since GETs traditionally have no request body (no entity), there's nothing to be unprocessable. If the client were POSTing a request, you might almost have a case...but then, you'd also have to make a good case for why a RESTful API requires a POST that doesn't update anything.

（我大约有47％的人确信代码在WebDAV之外也没有多大意义......但似乎有可能的用例。只是不是这个。）

(I'm about 47% sure that the code also doesn't make much sense outside of WebDAV...but it does seem there are conceivable use cases. Just not this one.)

这篇关于单个请求请求太大资源或太多资源时的HTTP状态代码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！