4

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

乍一看，HTTP 与响应代码相结合似乎是明智的GET。200404

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

  1. 404并且200可以由实际阻止请求的中间代理返回。这可能是由于代理配置错误，甚至是咖啡店 Wifi 等外部基础设施使用了糟糕的基于表单的身份验证。

  2. 客户端可能正在使用损坏的 URL。这可能通过弃用或（再次）通过错误配置而发生。但是，我们可以通过 对抗前者301。

区分已成功满足客户对该请求的意图的响应和通过异常行为提供的响应的当前最佳实践是什么？

通过响应主体隧道响应可以消除该问题，因为我们可以确保这些对于我们的服务是唯一的。但是，似乎不是很 RESTful！

4

2 回答 2

2

只需让您的应用程序在其 HTTP 响应中添加一些内容，以将它们与中介抛出的响应区分开来。任何或所有这些都可以工作：

  • 响应内容中可识别为您的应用程序内容的错误信息（例如，Application error: Domain name not found (404)）
  • 响应中的Content-Type标头，指示应将响应内容解码为应用程序错误（例如，Content-Type: application/vnd.domain-finder.error+json）
  • 响应中的自定义标头，指示它是应用程序错误

一旦您实施了这样的方案，您的 API 客户端将需要了解您选择的机制，如果他们想要对应用程序错误和基础设施错误做出不同的反应，因此只需清楚地记录它。

于 2014-04-24T23:27:27.270 回答
0

我倾向于遵循“只要有意义就做 RESTful”的思路。

假设您有一个如下所示的 API：

/api/v1/domains/<name>/

然后点击/api/v1/domain/exists.com/可以返回带有一些 whois 信息的 200。

点击/api/v1/domain/doesnt.com/可能会返回带有购买选项链接的 404。

那可能会奏效。如果返回的内容遵循严格的格式（例如带有results密钥的 JSON 响应），那么您的 API 响应可以与代理的响应区分开来。

或者，您可以提供

/api/v1/domains/?search=maybe
/api/v1/domains/?lookup=maybe.com

这现在稍微不那么 RESTful，但它仍然是自我描述的并且（在我看来）还不错。现在每个响应都可以是 200，您的内容可以显示结果。

于 2014-04-24T11:30:20.197 回答