我有一个 RESTful 服务，它在发生内部故障时抛出 500 INTERNAL SERVER ERROR 状态，原因有很多：连接或字段大小导致的数据库错误、代码错误或托管代码调用问题。IIS 将产生的未处理异常报告为 500。这是否适合使用 500？根据MSDN Common REST API Error Codes ，它可能意味着“重试请求” 。我正在寻找的正确 API 错误代码类似于“### 服务器将永远不会处理此请求，直到进行代码更改，不要重新发送，否则您将永远循环并 DOSing 我的服务器”。400 Bad Request 会更合适吗？似乎这表明请求语法本身格式错误，而不是服务阻塞。
此外，当客户遇到这样的错误时应该怎么做？服务器不想要另一个与前一个完全相同的 RESTful 操作。用户可能已经花了一些时间进行数据输入。现在我们必须说服他们离开壁架。也许他们可以自己修复它，这是最佳做法？开发人员有哪些类似的经历，是如何解决的？谢谢。
4xx 错误是“客户端有问题，他们发送了错误的东西”。
5xx 错误是“服务器出了点问题，抱歉今天生病了。”
这基本上意味着客户端无法从 5xx 错误中得到任何暗示。它可能是永久性的，也可能是短暂的，客户不知道。
IIS 发送 500 错误，因为 IT 不知道发生了什么。如果您的应用程序盲目地将异常抛出到 Web 层，那么它就无能为力或说什么了。
如果服务器逻辑以某种方式实际上知道出了什么问题，并且何时可以修复它，它可以发送一个 503 错误，告诉客户端它不可用，并且一个 Retry-After 标头告诉客户端它什么时候回来。
至于客户端行为，它在某种程度上取决于客户端使用服务的历史记录。也许服务间歇性地失败并出现 500 个错误，而另一个请求将正常工作。例如，如果您有一组负载平衡服务器，则可能会发生这种情况。他们命中的第一台服务器病了，但可能还没有病到负载平衡器已经将其停止轮换。所以，另一台服务器可能会很好——在这种情况下，客户端可以重试看看会发生什么。
但最终，如何做取决于客户。它可以尝试一个简单的退避算法。重试一次或两次。立即重试一次，然后在 10 秒后重试。
或者它可以只是将 500 错误推回给用户，并带有礼貌的消息“运气不好”。
只有客户端用例和需求才能真正决定当服务器死机时它的行为应该是什么。
在客户端，我们必须假设 Web 服务是好的，并且这要么是格式错误的请求（即用户键入了不合适的内容），要么是某种网络错误。我使用的方法是使用警告框，要求用户刷新屏幕（F5），然后用正确的输入再试一次。您可能需要添加“如果错误仍然存在，请联系...”。