请求正文中无效配置的正确 http 状态？
当 API 收到映射系统中附加数据的属性但未找到附加数据时，我无法选择正确的 HTTP 状态。我最初想到的是 422，因为它描述了用例，但听起来像是为 WebDAV 保留的。然后我想可能是 404，但我在心里将其与不正确的 URL 联系起来。另一个选项是使用错误代码 200 并显示失败消息。
示例：密钥 nvdaKey 不是系统知道的密钥配置。
发布：pgpTool.com/encrypt
{
"message": "my secret message",
"keyConfigName": "nvdaKey"
}
I am having trouble picking the correct HTTP Status for when an API is receives an attribute that maps additional data in the system but that additional data is not found. I was initially thinking 422 since it describes the use case but sounds like it is reserved for WebDAV. Then I was thinking maybe a 404 but I mentally associate that to a URL being incorrect. The other option was using error code 200 and have a failure message.
Example: the key nvdaKey is not a key configuration that the system knows about.
POST: pgpTool.com/encrypt
{
"message": "my secret message",
"keyConfigName": "nvdaKey"
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
IANA HTTP 状态代码注册表 目前列出了HTTP 语义 作为状态代码的权威参考 422
因此，如果您认为这是赢家，那就去吧。
403 Forbidden 也是一个选项（“我理解你的要求，但我拒绝履行它”）。
状态代码是文档传输中的元数据通过网络域；目标受众是通用 HTTP 组件（浏览器、缓存、代理......） 客户端应该从正文中获取消息的语义（就像我们期望人们阅读网络时通过以下方式了解错误一样）读取返回的网页，而不是读取 HTTP 标头）。
因此，除了一些纯粹的机械问题（缓存、标头解释）之外，只要您获得正确的类（客户端错误/4xx），您生成精确正确的状态代码并不一定重要。
请注意，无法识别 422 的客户端应将响应视为 400。
The IANA HTTP Status Code Registry currently lists HTTP Semantics as the authoritative reference for status code 422
So if you think that's a winner, go for it.
403 Forbidden is also an option ("I understood your request, but I refuse to fulfill it").
Status codes are meta data in the transfer of documents over a network domain; the intended audience is general purpose HTTP components (browsers, caches, proxies....) Clients are supposed to be getting the semantics of the message from the body (in just the same way we expect humans reading the web to learn of errors by reading the returned web page, rather than by reading HTTP headers).
So apart from some purely mechanical concerns (caching, interpretation of headers) it is not necessarily critical that you produce precisely the right status code, so long as you get the class (Client Error / 4xx) correct.
Do note that a client that doesn't recognize a 422 is expected to treat the response as though it were a 400.