我们正在尝试构建一个REST接口,允许用户测试特定资源的存在.我们假设我们正在销售域名：用户需要确定域名是否可用.

结合200和404响应代码的HTTP GET乍一看似乎是明智的.

我们遇到的问题是区分我们的查找服务成功提供的请求和在其他组件的异常行为下提供的请求.例如：

> 404和200可以由实际阻止请求的中间代理返回.这可能是由于代理配置错误,甚至是外部基础设施,如使用基于表单的不良身份验证的咖啡店Wifi.
>客户端可能正在使用损坏的URL.这可能通过弃用或(再次)错误配置发生.但是,我们可以通过301对抗前者.

目前最佳做法是区分成功实现的响应与客户对该请求的意图,以及通过特殊行为提供的响应？

通过响应机构的隧道响应来消除问题,因为我们可以确保这些是我们服务的独特之处.但是,似乎没有RESTful！

最佳答案 只需让您的应用程序在其HTTP响应中添加一些内容,以区别于中介机构抛出的响应.任何或所有这些都可行：

>有关响应内容中可识别为应用程序内容的错误的信息(例如,应用程序错误：未找到域名(404))
>响应中的Content-Type标头,指示响应内容应解码为应用程序错误(例如,Content-Type：application / vnd.domain-finder.error json)
>响应中的自定义标头,表示它是应用程序错误

实现这样的方案后,如果API客户希望对应用程序错误与基础结构错误做出不同的反应,则需要了解所选择的机制,因此请将其清楚地记录下来.