我有一个 post api 调用，当前在我的预订系统中创建一个约会。
如果api调用发送了约会请求，并且api可以成功创建约会，则api返回201创建状态码。
当前如果没有创建约会请求（由于各种原因，例如时间不再可用或房间正在使用中），api 将返回 400 bad request status code。
“400 Bad Request 响应状态码表示服务器不能或不会处理请求，因为某些东西被认为是客户端错误”
发送的数据不是无效的语法，可能会被重新发送并成功。
是否有更相关的状态码与此资源创建失败有关。在这种情况下，422 Unprocessable Entity 会是一个有效的响应吗？
【问题讨论】：
标签： rest
409 可能适合这个用例（以及我的个人喜好）：
"由于与当前的冲突，请求无法完成 目标资源的状态。此代码用于以下情况 用户可能能够解决冲突并重新提交 请求。”
通常在 PUT 中使用，但可以在这种情况下工作。例如，他们可以更改请求中的建议时间。或者，如果房间可用，他们可以稍后重试。
422 也可以指示字段级错误。
无论哪种方式，重要的是要附上一个很好的错误消息来指示问题。来自 rfc7231：
服务器应该发送一个包含解释的表示 错误情况，以及它是暂时的还是永久的。这些状态码适用于任何请求方法。
【讨论】：
[...] 如果未创建约会请求（由于各种原因，例如时间不再可用或房间正在使用中）[...]
状态码用于表明服务器尝试理解和满足客户端请求的结果。鉴于这是一个客户端错误，最合适的状态码应该在 4xx 范围内。
对于您问题中描述的情况，您可以使用409：
409（冲突）状态码表示请求无法 由于与目标的当前状态冲突而完成 资源。此代码用于用户可能 能够解决冲突并重新提交请求。服务器 应该为用户生成一个包含足够信息的有效载荷 认清冲突的根源。 [...]
400 与 422
一般来说，使用400 来指示负载中的语法 错误或URL 中的无效参数。并使用422 指示有效负载中的语义 问题。看看每个状态码是如何定义的：
400(Bad Request) 状态码表示服务器不能因为被认为是客户端错误（例如，格式错误的请求语法、无效的请求消息帧或欺骗性请求路由）而不会处理请求)。
11.2. 422 Unprocessable Entity
422（不可处理实体）状态码表示服务器 理解请求实体的内容类型（因此415（不支持的媒体类型）状态码不合适），并且 请求实体的语法是正确的（因此是400(Bad Request) 状态码不合适）但无法处理包含的 指示。例如，如果 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 状态码见下图：
【讨论】：
我的建议是使用 412 Precondition Failed 状态码，表明服务器由于失败/拒绝附加条件或业务逻辑而无法处理 POST 请求。
参考：https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412
【讨论】：
如果错误是由于服务器出现问题而不是客户端的错误，您可以使用5xx 范围（服务器错误）。 4xx 错误是为客户端引起的错误保留的。在这种情况下，大多数情况下使用500 Internal Server Error。
所以：
客户端故障 --> 4xx
服务器故障 --> 5xx
【讨论】：