Pha*_*007 11 http http-status-codes
我想知道API到达用户许可证时应该返回的理想HTTP状态代码是什么?
最初我在考虑它的402(需要付款),但这不是我的情况.我的情况是,如果我的用户有限制添加10个插件,如果她尝试添加第11个插件,他们应该得到他们的限制已达到的错误.
请帮助我使用适当的HTTP状态代码.
提前致谢
cas*_*lin 15
超出配额没有HTTP状态代码,但是如果您在响应有效负载中添加了良好的描述,则有一些HTTP状态代码适合这种情况.
如果已超出请求的配额,但可以在付款时执行更多请求,您可以考虑402状态代码(即使文档说它保留供将来使用,其原因很明确,并且很好地定义了它的用途):
该
402(需要付款)状态码保留供未来使用.
您可以403用来指示在超出请求限额时禁止请求.始终欢迎请求有效负载中的良好描述:
的
403(禁止)状态代码表示该服务器理解请求,但拒绝授权.希望公开请求被禁止的服务器可以在响应有效负载中描述该原因(如果有的话).[..]
如果您对每小时/每天的请求数量施加限制,则429状态代码可能适合您的需要(但是,服务器使用此状态代码表示在短时间内收到了太多请求,也就是说,客户端是限制的):
该
429状态代码表示用户在给定的时间量("限速")发送的请求过多.响应表示应该包括解释条件的详细信息,并且可以包括一个
Retry-After标题,指示在发出新请求之前等待多长时间.例如:
Run Code Online (Sandbox Code Playgroud)HTTP/1.1 429 Too Many Requests Content-Type: text/html Retry-After: 3600 <html> <head> <title>Too Many Requests</title> </head> <body> <h1>Too Many Requests</h1> <p>I only allow 50 requests per hour to this Web site per logged in user. Try again soon.</p> </body> </html>请注意,此规范未定义源服务器如何识别用户,也不定义请求如何计算.例如,限制请求率的源服务器可以基于每个资源,整个服务器或甚至一组服务器之间的请求计数来这样做.同样,它可以通过其身份验证凭据或有状态cookie来标识用户.
429状态代码的响应绝不能由缓存存储.
该HTTP状态代码是可扩展的.如果上述状态代码不符合您的需求,您可以创建自己的状态.由于这是客户端错误,因此新的状态代码应该在该4xx范围内.
小智 7
422 Unprocessable Entity在这种情况下应该起作用。请求本身在语法上形成良好。问题出在当前条件下,因为用户达到了限制。错误响应应该有助于解决这种现状。https://httpstatuses.com/422
我的第二个赌注是409 Conflict,但与版本控制和冲突更改有关。https://httpstatuses.com/409
| 归档时间: |
|
| 查看次数: |
6521 次 |
| 最近记录: |