因此,我正在设计一个Restful Api,对其他Web服务的调用将汇总结果并返回给客户端。 如果任何其他Web服务的连接由于某种原因而失败,那么最好返回什么?
现在正在向客户端返回500-Internal Server错误,但是我想向客户端返回更多有关导致请求失败的详细信息。 返回500 http响应代码和响应正文(其中包含详细说明错误实际发生的消息)或仅返回503-Service Unavailable http响应代码是否多余?
您的响应代码应取决于您对请求的处理方式。 如果客户端在这种情况下可以期望接收到部分信息和一条消息,指示哪些远程数据馈送不可用,则发送200。在该响应中,我将不包括HTTP代码或失败的URI,仅提供不可用的提供程序的名称。 ,可能是原因。 如果这样做,当您需要添加非基于URI的提供程序时,您可能会发现自己陷入了困境。 如果必须,请确保包括“类型”并要求客户使用它。 这将部分确保您的未来适应性,但希望许多客户端将忽略该类型,并且如果以后添加新类型会中断。
如果客户端无法对部分数据执行任何操作,则应返回503,因为您的服务不可用。 它恰好不可用,因为它所依赖的远程服务器已关闭。 这与返回503没什么不同,因为您自己的数据库已关闭。 您的API无法返回某些内容,因为其所需的内容目前无法使用,但稍后会再次提供。 您应该在响应的正文中包含中断的原因,并且如果您对何时可以再次使用远程服务器有任何想法,则可以包含Retry-After
标头。
404不合适,因为它意味着所请求的资源不存在-客户端错误。 该资源确实存在,只是现在无法返回,因为您的服务器无法构建它。
409是不合适的,因为没有用户可以解决的冲突。
206不适合使用,因为当请求包含Range
标头时将使用206,并且没有迹象表明这些请求需要这样做。
由于您的聚合基本上找不到要查找的内容,因此也许找不到HTTP 404是合适的。
如果不是所有的远程调用都失败,那么至少会有一些相关的结果,您可以返回HTTP 200 OK,并带有一个附加状态,通知某些远程源当前不可用。
我不会返回HTTP 503,因为此代码表明您的服务暂时不可用-因此您建议客户端稍后重试。 通常,当服务器重新启动且尚未准备好服务请求时,将返回HTTP 503。