设计一个RESTful API,它有一些依赖于上游服务的元素(例如数据库,另一个Web服务等).如果应用程序本身处于有效状态,并且仍然可以使用,但无法访问其中一个上游服务(由于网络问题或其他原因),是否有比使用更合适的状态代码HTTP 500？
HTTP 500对我来说不合适,因为问题不是(如RFC定义的)"内部服务器错误".服务器很好,仍然能够处理其他请求而不会崩溃,它只是降级功能,直到其他服务重新联机.
我考虑过502 - Bad Gateway因为应用程序实际上充当了这个其他服务的代理(有点),或者503 - Service Unavailable因为它是一个实际上不可用的服务,但是他们感觉不完全正确.特别是最后一个,因为它具有由于加载或处理请求太多而无法使用的含义.
Jay*_*ete 17
你不应该从你的(api提供者)角度来看待它,而是从消费者的角度来看.您应该能够向您的消费者解释他们在收到特定状态代码时应该如何行动.他们应该如何表现出与发送500时不同的行为？
作为api消费者,我真的不在乎哪里出了问题.我有一个单一的界面可以使用,这是你的公共API.你如何选择在这个界面后面实现api与我无关.
所以我知道,你有一个内部服务器错误.即使它完全合法,你也无法处理我的请求.因此,即使这是由下游系统引起的,您也应返回状态码500.
如果这是一个临时条件,但是你希望很快恢复,那么它是503.我仍然不在乎这是由下游服务引起的.我只关心你告诉我你希望很快恢复,所以我应该在一段时间后重试.
这就是w3.org所说的:
由于服务器的临时过载或维护,服务器当前无法处理请求 .这意味着这是一个暂时的条件,经过一段时间的延迟后会得到缓解.如果已知,则可以在Retry-After报头中指示延迟的长度.如果没有给出Retry-After,客户端应该像 处理500响应一样处理响应.
您可以(并且实际上应该)做的是在正文中返回错误消息.如果您的api是json api,那么您应该返回一个json格式的错误消息.
不要考虑好看.考虑明确和可预测.服务器遇到意外情况,导致无法完成请求.
编辑:您提到数据库,并且在数据库超时的情况下,它绝对是500.
/J.P
| 归档时间： |
|
| 查看次数： |
5249 次 |
| 最近记录： |