我们正在尝试构建一个REST接口，允许用户测试特定资源的存在。我们假设我们正在销售域名：用户需要确定域名是否可用。
HTTP GET结合200和404响应代码乍一看似乎很明智。
我们遇到的问题是区分我们的查找服务成功提供的请求，以及在其他组件的异常行为下提供的请求。例如：
404和200可以由实际阻止请求的中间代理返回。这可能是由于代理配置错误，甚至是使用基于表单的身份验证不良的咖啡店Wifi等外部基础设施。
客户端可能正在使用损坏的网址。这可能通过弃用或（再次）错误配置发生。但是，我们可以通过301来对抗前者。
目前最佳做法是区分已成功履行的回复与客户对该请求的意图，以及通过特殊行为提供的回复？
通过响应机构隧道响应消除了问题，因为我们可以确保这些服务对我们的服务是唯一的。但是，似乎没有RESTful！
答案 0 :(得分：2)
只需让您的应用程序在其HTTP响应中添加一些内容，以区别于中间人抛出的响应。任何或所有这些都可行：
Application error: Domain name not found (404)）Content-Type标头，指示响应内容应解码为应用程序错误（例如，Content-Type: application/vnd.domain-finder.error+json）一旦实施了这样的方案，您的API客户端需要了解您选择的机制，如果他们想要对应用程序错误和基础架构错误做出不同的反应，那么只需清楚地记录它。
答案 1 :(得分：0)
我倾向于遵循＆＃34;做什么的RESTful，只要它有意义＆＃34;思路。
我们假设您有一个如下所示的API：
/api/v1/domains/<name>/
然后点击/api/v1/domain/exists.com/可以返回带有一些whois信息的200。
点击/api/v1/domain/doesnt.com/可能会返回404，其中包含购买选项的链接。
那可能会奏效。如果返回的内容遵循严格的格式（例如带有results密钥的JSON响应），那么您的API响应可以与您的代理区分开来。＆＃39;响应。
或者，您可以提供
/api/v1/domains/?search=maybe
/api/v1/domains/?lookup=maybe.com
现在略微不那么RESTful，但它仍然是自我描述的（在我看来）并没有那么糟糕。现在每个回复都可以是200，您的内容可以显示结果。