HTTP状态码4xx与5xx
g_u*_*int 4 http http-status-codes
我正在创建一个REST API,并且发现在某些情况下很难选择正确的HTTP状态代码.
假设我期望某个值,当它不存在时,我无法执行某个任务并返回错误.由于缺少值,服务器无法处理请求,但是发送它的客户端,状态良好但不完整.是否最好返回错误4xx或5xx错误？
cas*_*lin 23
坚持标准!
决定将您发送给客户端的HTTP状态代码取决于您,但您确实应该遵守标准.在RFC 7231是用于HTTP/1.1协议的内容和语义的电流基准.在HTTP协议的顶部创建API时必须阅读.
4xxvs 5xx状态代码
使用4xx状态代码表示客户端错误和5xx服务器错误的状态代码:
该
4xx(客户端错误)类的状态代码表示客户端似乎出现了偏差.除了在响应HEAD请求时,服务器应该发送一个表示,其中包含错误情况的解释,以及它是暂时的还是永久的.这些状态代码适用于任何请求方法.用户代理应该向用户显示任何包含的表示.
将
5xx(服务器错误)类的状态代码表示服务器知道,它已经犯错或不能够执行所请求的方法.除了在响应HEAD请求时,服务器应该发送一个表示,其中包含错误情况的解释,以及它是暂时的还是永久的.用户代理应该应该向用户显示任何包含的表示.这些响应代码适用于任何请求方法.
您应该使用哪个状态代码
对于您在问题中提到的情况,您可以使用400或者422(从WebDAV,HTTP扩展):
的
400(错误请求)状态代码表示服务器无法或不愿请求过程中,由于一些被认为是一个客户端错误(例如,恶意请求语法,无效的请求消息帧,或欺骗性的请求路由).
该
422(处理的实体)状态代码表示的服务器理解的内容类型的请求实体的(因此一个415(不支持的媒体类型)状态代码是不适当的),并且请求实体的语法是正确的(因而400(错误请求)状态代码是不合适的)但无法处理所包含的说明.例如,如果XML请求主体包含格式正确(即语法正确)但语义错误的XML指令,则可能发生此错误情况.
与状态代码一起,确保发送包含响应有效内容中错误情况说明的表示(如JSON或XML).看一下RFC 7807,它描述了HTTP API问题细节的标准.
一个伟大的决策图表
有关更多详细信息,请查看Racksburg的此决策图表:
状态代码分为三大类:
从这里开始:
选择2xx和3xx状态代码:
选择4xx状态代码:
选择5xx状态代码:
- 我终于意识到为什么 5xx 图中的最后一个菱形对我来说没有意义。就是因为它落后了！“您的代码无法处理该请求，您是否感到难过？” 如果**否**，您并不感到难过，那么您将返回 501 Not Implemented。如果**是**，你确实感觉不好，那么你将其视为错误，并返回 500 Internal Server Error。 (2认同)
| 归档时间： |
|
| 查看次数： |
4345 次 |
| 最近记录： |