是否应使用HTTP状态代码来表示服务器上的业务逻辑错误？

对于客户端（浏览器中的JS）与服务器通信的一些API设计，我处在一个十字路口。由于有效的安全锁定，我们使用HTTP 409冲突来表示操作失败。安全锁可以防止开发人员意外更改我们客户的生产系统。我的任务是在客户端上更优雅地处理409s，以指示为什么特定的API调用失败。

我的解决方案是包装我们的任何AJAX调用的失败处理程序，当由于409导致某些操作失败时，它将在客户端上显示通知-一切都很好，并且可以与使用相同机制的其他4XX和5XX错误一起使用。

出现问题时，我们的一个路由处理程序在遇到业务逻辑错误时以409s响应-我的AJAX包装器报告安全锁已打开，而客户端的现有故障处理程序报告了（它认为）问题是基于主体的回应。一个简单的解决方案是更改处理程序的响应或用于表示安全锁的状态代码。

这使我走到了十字路口：HTTP状态代码是否应该甚至用来表示业务逻辑错误？这个问题解决了我面临的同一问题，但是并没有获得太大的吸引力。正如链接答案中所建议的那样，我倾向于使用HTTP 200 OK以及适当的正文来表示业务逻辑中的失败。

有人在这里有什么强烈的意见吗？有谁能说服我这是代表失败的错误方式？

凯西（Kasey）涵盖了重点。

任何网络api中的关键思想：您正在调整域以使其看起来像文档存储。GET / PUT / POST / DELETE等都是与文档存储进行交互的所有方式。

因此，考虑使用什么代码的一种方法是了解文档存储中的类似操作以及该类似情况下的故障情况。

2xx完全不合适

状态代码的2xx（成功）类表示已成功接收，理解并接受了客户的请求。

5xx也不合适

状态代码的5xx（服务器错误）类表示服务器知道它已错误

在这种情况下，服务器没有犯错；它知道您目前不应该以这种方式修改该资源。

业务逻辑错误（这意味着业务不变量当前不允许进行建议的修改）可能是409

409（冲突）状态代码表示由于与目标资源的当前状态冲突而无法完成请求。此代码用于用户可能能够解决冲突并重新提交请求的情况。服务器应该产生一个有效载荷，该载荷包括足够的信息供用户识别冲突的根源。

请注意最后一点-409响应的有效负载应将有关发生问题的信息传达给用户，并且理想情况下应包括超媒体控件，这些控件可将用户引导至可以帮助解决冲突的资源。

我的解决方案是包装我们的任何AJAX调用的失败处理程序，当由于409导致某些操作失败时，它将在客户端上显示通知-一切都很好，并且可以与使用相同机制的其他4XX和5XX错误一起使用。

我会指出这是问题所在；您在客户端的实现假定状态码足以确定问题。相反，您的客户端代码应检查有效负载，并根据可用信息进行操作。

毕竟，就是文档存储如何做到这一点

409  Conflict

your proposed change has been declined because ${REASON}.  
The following resolution protocols are available: ${LINKS[@]})

同样的方法400 Bad Request也可以接受；大致翻译为“您的请求存在问题。我们不会费心找出最适合的状态码，因此您可以开始。有关详细信息，请参见有效负载。”

我将使用422。输入有效，因此400不是正确的错误代码，无法使用

WebDAV规范包含此建议

422（不可处理实体）状态代码表示服务器了解请求实体的内容类型（因此415（不支持的媒体类型）状态代码不合适），并且请求实体的语法正确（因此400（错误请求） ）状态代码不合适），但无法处理其中的说明。例如，如果XML请求主体包含格式正确（即，语法正确）但语义上错误的XML指令，则可能发生此错误情况。

我不认为这很匹配（尽管我同意这会引起一些疑问400）。我的解释是422“您发送了错误的实体”，409而“您在错误的时间发送了实体”。

换句话说，422指示孤立考虑的请求消息有问题，其中409指示请求消息与资源的当前状态冲突。

Ben Nadal对422的讨论可能会有用。

以我的经验，HTTP错误代码不足以表示业务错误。但是，它们对于表示错误类别很有用。

因此，我的建议是将HTTP错误代码用于错误类别，但为业务逻辑故障选择特定的错误（例如409 Conflict ... 200 OK在这里会产生误导），并在响应中包括指示特定业务错误的数据。确保这是响应内容的一部分，而不是状态文本，因为某些浏览器会忽略自定义状态文本。我喜欢使用的语言具有联合类型，可以方便地表示消息。但是您也可以为错误情况定义字符串常量。

例子

// error with text response
409 Conflict "safety_lock_engaged"
409 Conflict "customer_not_eligible_for_selected_discount"
// warning with JSON response
202 Accepted { "backorderedProductIds": [ 37, 476 ] }

通常，我会避免使用HTTP状态代码来表示特定的业务逻辑错误。这是因为它们已经具有全球标准定义的语义。其他系统，新开发人员等会因您偏离标准而感到困惑。

我在最近的类似研究中发现，在400 Bad Request验证错误等情况下，通常接受使用该方法。这样，您对所有业务逻辑错误使用一个状态代码。

顺便说一句，409当您在编辑资源并尝试再次保存它时更改了资源时，应使用该命令。

您可以使用“错误请求”，并包括违反的业务规则的ID，以及响应正文中的更多详细信息。