我有一个post api调用,该调用当前在我的预订系统中创建一个约会。
如果api调用发送了约会请求,并且api可以成功创建一个约会,则api返回201创建的状态代码。
当前,如果未创建约会请求(由于各种原因,例如时间不再可用或现在正在使用房间),则api返回400错误的请求状态代码。
“ 400错误的请求响应状态代码表示服务器由于某些原因被视为客户端错误而无法或将不会处理请求”
发送的数据不是无效的语法,并且可能会重新发送并成功。
是否存在与此创建资源失败相关的状态代码。 422无法处理的实体在这种情况下会是有效的响应吗?
答案 0 :(得分:3)
409 可以适合此用例(以及我的个人喜好):
”由于与当前冲突,请求无法完成 目标资源的状态。该代码用于以下情况 用户可能能够解决冲突并重新提交 请求。”
通常在PUT中使用,但可以在这种情况下使用。例如,他们可以更改请求中的建议时间。或者,如果房间可用,他们可以稍后重试。
422也可以用来指示字段级错误。
无论哪种方式,重要的是要伴随它附上指示该问题的良好错误消息。来自rfc7231:
服务器应发送包含以下内容的说明的表示形式: 错误情况,以及它是暂时还是永久的情况。这些状态代码适用于任何请求方法。
答案 1 :(得分:0)
如果错误是由于服务器上出现问题而导致的,并且没有客户端的错误,则可以使用5xx
范围(服务器错误)。 4xx
错误是为客户端导致的错误保留的。在这种情况下,最常使用500 Internal Server Error
。
所以:
客户端故障-> 4xx
服务器故障-> 5xx
答案 2 :(得分:0)
[...]如果未创建约会请求(由于各种原因,例如时间不再可用或现在正在使用房间)[...] >
状态代码用于指示服务器尝试理解并满足客户端请求的结果。鉴于这是客户端错误,因此最合适的状态代码应在4xx
范围内。
对于问题中描述的情况,您可以使用409
:
409
(冲突)状态码表示请求无法 由于与目标的当前状态冲突而完成 资源。此代码用于用户可能会 能够解决冲突并重新提交请求。服务器 应该生成一个有效载荷,该有效载荷应为用户提供足够的信息 识别冲突的根源。 [...]
400
与422
通常,使用400
来指示有效负载中的语法错误或URL中的无效参数。并使用422
来指示有效载荷中的语义问题。查看每个状态代码的定义方式:
400
(错误请求)状态码表示服务器由于某些原因(例如格式错误的请求语法,无效的请求消息框架或欺骗性的客户端错误)而无法处理请求请求路由)。
11.2. 422 Unprocessable Entity
422
(不可处理实体)状态代码表示服务器 了解请求实体的内容类型(因此415
(不受支持的媒体类型)状态码不正确),并且 请求实体的语法正确(因此400
(错误请求) 状态代码不正确),但无法处理其中的内容 说明。例如对于如果XML可能会出现此错误情况 请求正文包含格式正确(即语法正确)的内容,但 语义错误的XML指令。
还要考虑由著名的GitHub API v3 API返回的状态代码:
API调用中存在三种可能的客户端错误类型 接收请求正文:
发送无效的JSON将导致
400 Bad Request
响应。 [...]发送错误类型的JSON值将导致
400 Bad Request response
。 [...]发送无效字段将导致
422 Unprocessable Entity
响应。 [...]
Michael Kropat组合在一起的set of diagrams对于选择最合适的状态代码非常有见地。请参见下图,了解4xx
状态代码:
答案 3 :(得分:0)
我的建议是使用 412前提条件失败状态代码,该代码指示服务器由于失败/拒绝其他条件或业务逻辑而无法处理POST请求。
引用:https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412