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