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