作者:我是王灿_246 | 来源:互联网 | 2022-12-06 19:04
我已经阅读了很多关于正确的http状态代码的帖子和文章,以便返回客户端请求错误.其他人建议使用400,因为它已在RFC 7231中重新定义,但我不确定给出的示例是否涵盖了我脑海中的所有客户端错误,因为这些示例是语法.
400(错误请求)状态代码指示服务器由于被认为是客户端错误(例如,格式错误的请求语法,无效的请求
消息成帧或欺骗性请求路由)而不能或不会处理该请求.
我确实在rfc 7231的附录B中找到了这个陈述:
400(错误请求)状态代码已被放宽,因此
不限于语法错误.(第6.5.1节)
这是否意味着我可以将任何类型的客户端错误视为错误请求?将400用于客户端请求并在消息中指定更具体的错误会更好吗?
另一方面,其他人说最好使用422(不可处理的实体).虽然这更侧重于语义,但它仅在RFC 4918中列出,它是http/1.1的webDAV扩展.
的422(无法处理的实体)状态代码表示该服务器
理解的内容类型的请求实体(因此一个的
415(不支持的媒体类型)状态代码是不适当的),并且
所述请求实体的语法是正确的(因此400(错误的请求)
状态代码不合适)但无法处理包含的指令.例如,如果XML
请求主体包含格式正确(即语法正确)但
语义错误的XML指令,则可能发生此错误情况.
我可以使用此webDAV扩展代码来处理我的http请求吗?在422的情况下,我可以使用它,即使它不在核心http代码中.
我应该使用400或422来解决客户端错误吗?
以下是我想到的可能的客户端错误:
1.) Invalid parameter. The client provided parameters but are found invalid. Example: I said that the userId is 1, but when I checked there's no userId of 1. Another example of invalid parameter is wrong data type.
2.) Missing required parameters
3.) Let's say I need to hash a value based on given params and it failed
4.) Blocked content is being used. Like, i want to apply for membership and i passed the userId of 1. However, userId of one is blocked / deactivated
5.) When I try to delete an entry but the entry is still being used in another table.
6.) Let's say i require a signature in my payload and the signature does not match when recalculated in the backend
7.) Let's say I have a value that counts a specific attribute like "shares" and it has reached the maximum value like 10.
etc...
任何信息性的回应将受到高度赞赏.非常感谢,伙计们!
更新:我检查了谷歌api错误,他们没有使用422.另一方面,Twitter使用422.我比以往更困惑>.<虽然有一部分我认为400是更好的选择,因为它包括在RFC doc和422中没有.我可能错了.
1> cassiomolin..:
我可以使用此WebDAV扩展代码来处理我的HTTP请求吗?在这种情况下422
,我可以使用它,即使它不在核心HTTP代码中.
HTTP是一个可扩展的协议和422
被登记在IANA,这使得它成为标准状态代码.因此,没有什么能阻止您422
在应用程序中使用.
我应该使用400
或422
为我的客户端错误?
这取决于,但你可以使用两者.通常,用于400
指示有效内容中的语法错误或URL中的无效参数.并用于422
指示有效负载中的语义问题.
例如,请参阅GitHub v3 API使用的方法:
客户错误
接收请求主体的API调用有三种可能的客户端错误类型:
发送无效的JSON将导致400
错误的请求响应.
HTTP/1.1 400 Bad Request
Content-Length: 35
{"message":"Problems parsing JSON"}
发送错误类型的JSON值将导致400
错误的请求响应.
HTTP/1.1 400 Bad Request
Content-Length: 40
{"message":"Body should be a JSON object"}
发送无效字段将导致422
无法处理的实体响应.
HTTP/1.1 422 Unprocessable Entity
Content-Length: 149
{
"message": "Validation Failed",
"errors": [
{
"resource": "Issue",
"field": "title",
"code": "missing_field"
}
]
}
选择最合适的4xx
状态代码
Michael Kropat整理了一套决策图表,帮助确定每种情况的最佳状态代码.有关4xx
状态代码,请参阅以下内容
HTTP API的问题详细信息
HTTP状态代码有时不足以传达有关错误的足够信息.在RFC 7807定义了简单的JSON和XML文档格式来通知客户端的HTTP API的问题.这是报告API错误的一个很好的起点.
它还定义了application/problem+json
与application/problem+xml
媒体类型.