我们正在尝试构建一个 REST 接口，允许用户测试特定资源是否存在。假设我们正在销售域名：用户需要确定该域名是否可用。
An HTTP GET结合200 and 404乍一看，响应代码似乎很合理。
我们遇到的问题是区分查找服务成功服务的请求和其他组件在异常行为下服务的请求。例如：
404 and 200可以由实际阻止请求的中间代理返回。这可能是由于代理配置错误，甚至是外部基础设施（例如咖啡店 Wifi）使用了不良的基于表单的身份验证。
客户端可能使用损坏的 URL。这可能是由于弃用或（再次）错误配置而发生的。我们可以通过以下方式对抗前者301， 然而。
当前区分已成功满足客户请求意图的响应和通过异常行为提供的响应的最佳实践是什么？
通过响应主体隧道响应可以消除该问题，因为我们可以确保这些响应对于我们的服务来说是唯一的。然而，看起来不太安静！
只需让您的应用程序向其 HTTP 响应添加一些内容，以将其与中介抛出的响应区分开来。任何或所有这些都可以：
- 有关响应内容中可识别为应用程序内容的错误的信息（例如，
Application error: Domain name not found (404))
- A
Content-Type响应中的标头，指示响应内容应解码为应用程序错误（例如，Content-Type: application/vnd.domain-finder.error+json)
- 响应中的自定义标头表明这是一个应用程序错误
一旦你实现了这样的方案，如果你的 API 客户端想要对应用程序错误和基础设施错误做出不同的反应，他们将需要了解你选择的机制，所以只需清楚地记录下来即可。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
