我一直在使用REST API。我发现了一个错误，我的POST请求用于获取HTTP-401代码的响应。即使已创建资源。那不是它应该如何工作的。这使我认为该API并不是世界上最出色的API。
然后我固定了请求，一切看起来都很好，但是REST API返回了HTTP-400。原因是“超出资源限制”。
这是我的问题：
处理该情况的正确HTTP状态代码是什么？我的意思是，客户端超出了资源限制，并且仍然发送POST请求。
我相信HTTP-400适用于格式错误的请求，但是所有格式都正确。我们不应该使用其他代码吗？如果是，是哪一个？
HTTP-429 Too Many Requests似乎也很糟糕，也许HTTP-422 Unprocessable Entity？
答案 0 :(得分：1)
处理此情况的正确HTTP状态代码是什么？
状态代码与请求方法一样，是经过粗略设计的；我们并不是要在描述问题时非常精确，而是要广泛地描述问题的一般类别，以使通用客户端（例如浏览器和缓存）在响应中看到该代码时可以做正确的事情（对于示例：观察401 Unauthorized时抛出登录对话框
有许多决策树可帮助选择合适的代码；我认为我最常看到Michael Koprat；这些往往不够全面，但通常涵盖了HTTP定义的所有代码-您也可以挖掘status code registry的其他选项。
然后我修复了请求，一切看起来都很好，但是REST API返回了HTTP-400。原因是“超出资源限制”。
“资源限制”在我看来有点模棱两可，因为预期的含义可能是资源的大小太大，换句话说，消息主体/内容长度太长（{{ 3}}似乎合适）；另外，也可能是尝试传达配额已超过la 413 Payload Too Large。
4xx应该指示客户端可以解决的问题-请求出现问题，而不是主机出现问题。因此，这可能暗示413的含义是预期的。
但是，如果请求中有问题，而其他状态代码似乎都不匹配，则508 Resource Limit is Reached是 fine 。
关于正在发生的事情的细粒度解释应该在消息正文中表示，但这并不总是会发生。
主体不是太大，删除一个资源后执行的同一请求得到了成功的响应（这就是为什么我认为HTTP-400不正确）。
引人入胜：4xx Too Many Notes。我认为您可以为400 Bad Request和403 Forbidden辩护，并使用有效载荷将情况描述为临时情况并提出可能的补救措施。
这真的是服务器的错误吗？不是客户的吗？
在大多数情况下，如果客户可以取消纠结，那么您应该使用状态代码405 Method Not Allowed的成员。