深度分页超出限制时，API应返回何种HTTP状态码？

我们有一个API，希望拒绝页码超过99的请求，示例如下：

GET example.com/users?page[number]=99 # 允许，返回200 OK
GET example.com/users?page[number]=100 # 拒绝，返回???

我们正在评估以下状态码选项，想知道哪个最合适：

• 400：过于宽泛
• 403：最有可能适用
• 410：已消失，或许可行，但并非临时情况
• 422：接近匹配，但描述为“服务器无法处理包含的指令”，不够准确
• 429：不符合Retry-After机制

状态码分析与结论 #

逐个分析选项：

• 400 Bad Request：仅表示请求格式或语法错误，但页码超限是明确的业务规则限制，不属于格式问题，用这个状态码无法精准传达拒绝原因，因此不合适。
• 410 Gone：用于标记资源永久消失的场景，而这里只是不允许访问超过99页的内容，资源本身并未消失，完全不匹配，直接排除。
• 429 Too Many Requests：针对请求频率过高的限流场景，需要搭配Retry-After响应头告知客户端重试时间，和页码超限的场景无关，排除。
• 422 Unprocessable Content：适用于请求格式正确但语义无法被服务器处理的情况（比如字段值不符合业务规则但格式合法），但页码超限更偏向于访问范围的限制，而非请求内容无法处理，描述不够精准。

最终推荐403 Forbidden：这个状态码的核心含义是服务器理解请求，但因权限或访问范围限制拒绝执行。页码超过99属于API设定的访问范围边界，用403能准确传达“你无权/不允许访问该页码内容”的意图。同时建议在响应体中补充明确的错误信息，例如：

{"error": "页码不能超过99，当前请求页码为100"}

让客户端能快速定位问题。

内容的提问来源于stack exchange，提问作者ecoologic