POST的适当HTTP状态代码以创建超出限制的资源 [英] Appropriate HTTP Status Code for POST to create resource exceeding the limit

问题描述

我一直在使用REST API.我发现了一个错误，我的POST请求用于获取HTTP-401代码的响应.即使已创建资源.那不是它应该如何工作的.这使我认为该API并不是世界上最出色的API.

然后我修复了请求，一切看起来都很好，但是REST API返回了HTTP-400.原因是超出资源限制".

这是我的问题: 什么是正确的HTTP状态代码来处理这种情况?我的意思是，客户端超出了资源限制，并且仍然发送POST请求. 我相信HTTP-400适用于格式错误的请求，但是所有格式都正确.我们不应该使用其他代码吗?如果是，请选择哪一个? HTTP-429 Too Many Requests似乎也很糟糕，也许HTTP-422 Unprocessable Entity?

解决方案

用于处理这种情况的正确的HTTP状态代码是什么?

状态代码与请求方法一样，是经过粗略设计的；我们并不是要在描述问题时非常精确，而是要广泛地描述问题的一般类别，以使通用客户端(例如浏览器和缓存)在响应中看到该代码时可以做正确的事情(对于示例:观察 401未经授权)

有许多决策树可帮助选择适当的代码；我想我看到了 Michael Koprat 最常见；这些往往不够全面，但通常涵盖了HTTP定义的所有代码-您也可以挖掘

资源限制"在我看来有点模棱两可，因为预期的含义可能是资源的大小太大-换句话说，消息主体/内容长度太大( 413有效负载过大似乎很合适)；或者，可能是试图传达已超出配额达到508资源限制.

4xx应该指示客户端可以解决的问题-请求出现问题，而不是主机出现问题.因此，这可能暗示413的含义是预期的含义.

但是，如果请求中有问题，而其他状态代码似乎都不匹配，请 403禁止和 405不允许的方法，其有效载荷将情况描述为暂时的并建议可能补救措施.

这真的是服务器的错误吗?不是客户的吗?

在大多数情况下，如果客户端可以取消纠结，则您应该使用状态代码的4xx类.

I have been playing with a REST API. I've found a bug, my POST request used to get response with HTTP-401 code. Even though, the resource was created. That's not how it should work. That made me think that this API was not the greatest API in the world.

Then I fixed my request, everything looked fine but then the REST API returned HTTP-400. The reason was "resource limit was exceeded".

And here comes my question: What is the correct HTTP Status Code to handle the situation? I mean, the client exceeded the limit of resources and still he sends the POST request. I believe HTTP-400 is for malformed request, but everything is properly formatted. Shouldn't we use some other code? If yes, which one? HTTP-429 Too Many Requests seems also bad, maybe HTTP-422 Unprocessable Entity?

解决方案

What is the correct HTTP Status Code to handle the situation?

Status code, like request method, is deliberately coarse grained; we're not trying to be ultra precise in describing the problem, but to broadly describe the general category of the problem, so that generic clients (like browsers and caches) can do the right thing when that code is seen in the response (for example: throwing up a login dialog when observing a 401 Unauthorized)

There are a number of decision trees to help select the appropriate code; I think I see Michael Koprat's most often; these tend not to be comprehensive, but usually cover all of the codes defined by HTTP -- you could also mine the status code registry for other options.

Then I fixed my request, everything looked fine but then the REST API returned HTTP-400. The reason was "resource limit was exceeded".

"Resource limit" seems a bit ambiguous to me, as the intended meaning might be that the size of the resource is too big -- in other words, that the message-body/content-length is too large (413 Payload Too Large would seem appropriate); alternatively, it might be an attempt to communicate that a quota has been exceeded a la 508 Resource Limit is Reached.

4xx should indicate something that the client can fix - a problem with the request, rather than a problem on the host. So that might be a hint that the 413 meaning is the one that is intended.

But if in the case where there is a problem in the request, and none of the other status codes seems to be a match, 400 Bad Request is fine.

The fine grained explanation for what's going on should be represented in the message body, but that doesn't always happen.

Body was NOT too large, the same request executed after deleting one of the resources got a successful response (that's why I think HTTP-400 is incorrect).

Fascinating: 4xx Too Many Notes. I think you could make a case for 403 Forbidden and 405 Method Not Allowed, with a payload that describes the condition as temporary and suggests possible remedies.

And is it really a server's error? Not client's one?

For the most part, if the client can untangle things, then you should be using a member of the 4xx class of status codes.

这篇关于POST的适当HTTP状态代码以创建超出限制的资源的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！