我们今天讨论了传输操作导致状态代码200,OK 。返回的两个对象看起来像这样。
第一个是可以理解的(并遵循预期的合同)。
{ name: "john", age: 34, city: "stockholm" }
第二个,遵循合同,但毫无疑问是错误的数据。
{ name: null, age: -3.141526, city: "http://some.com/address/poof" }
一方声称状态代码200不正确因为值错误。另一方认为状态代码描述了操作本身以及请求/响应的格式,这种格式很好因为转移与合同一致。
很明显,REST端点从其获取数据的源中获取异常。因此,第一方希望结果是 404找不到或 500内部错误。另一方是在前一种情况下对象结构为空(一直为空)的条件下对它开放的,并且在后一种情况下它不会尝试遵循商定的格式。
结帐the Kamasutra它说:
请求已成功。响应返回的信息取决于请求中使用的方法。
现在,从技术上讲,我们无法确定所请求的资源是否有名称,可能计划在PI年出生,并且恰好位于将其名称更改为URL的城市。 实际上可能,尽管不太可能。但是,我希望看到状态代码200中包含的内容的明确声明。
问题:请求状态代码400或更高是否有效,因为这些值似乎(或者甚至明显)是错误的?
答案 0 :(得分:2)
RFC 2616现在完全无关一旦它被一组共同定义HTTP / 1.1协议的新RFC取代:
对于HTTP status codes,请参阅RFC 7231。此类文档定义了每个状态代码指示的内容选择最能给出理解和满足请求的结果的那个。
本文档还定义了状态代码的类,这有助于确定最合适的响应状态:
状态代码的第一个数字定义了响应类。最后两位数字没有任何分类角色。第一个数字有五个值:
1xx
(提供信息):已收到请求,正在继续处理
2xx
(已成功):请求已成功收到, 理解并接受
3xx
(重定向):需要采取进一步行动 完成请求
4xx
(客户端错误):请求包含错误的语法或不能 实现
5xx
(服务器错误):服务器无法完成 有效请求
请记住,HTTP状态代码是可扩展的。 RFC 7231不包含其他规范中定义的扩展状态代码。完整的状态代码列表由IANA维护。
2xx
类状态代码表示请求已成功已接收,已理解且已接受。一旦您不接受无效数据,即服务器无法处理的实体,200
状态代码就不适合这种情况。
您正在查找422
状态代码:请求有效内容的语法有效,但由于数据无效而无法处理。看看:
11.2. 422 Unprocessable Entity
422
(不可处理的实体)状态代码表示服务器 了解请求实体的内容类型(因此a415
(不支持的媒体类型)状态代码不合适),以及 请求实体的语法是正确的(因此400
(错误请求) 状态代码不合适但是无法处理包含的内容 说明。例如,如果是XML,则可能会出现此错误情况 请求正文包含格式正确(即语法正确),但是 语义错误的XML指令。
根据您的情况,只需阅读 JSON 而不是 XML 。
422
在IANA中注册,并在RFC 4918中定义,Michael Kropat是定义WebDAV的文档,WebDAV是HTTP协议的扩展。
set of decision charts汇总,帮助确定每种情况的最佳状态代码。状态代码分为三大类:
从这里开始:
选择2xx
和3xx
状态代码:
选择4xx
状态代码:
选择5xx
状态代码:
{{3}}