使用HTTP状态代码时区分基础架构和业务逻辑 [英] Discriminating between infrastructure and business logic when using HTTP status codes

问题描述

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

We are trying to build a REST interface that allows users to test the existence of a specific resource. Let's assume we're selling domain names: the user needs to determine if the domain is available.

HTTP GET 结合 200 和 404 响应代码乍一看似乎很明智。

An HTTP GET combined with 200 and 404 response codes seems sensible at first glance.

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

The problem we have is discriminating between a request successfully served by our lookup service, and a request served under exceptional behaviour from other components. For example:

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

1. 404 and 200 can be returned by intermediary proxies that actually block the request. This can be due to proxy misconfiguration, or even external infrastructure such as coffee shop Wifi using poor forms-based authentication.

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

Clients could be using broken URLs. This could occur through deprecation or (again) by misconfiguration. We could combat the former through 301, however.

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

What is the current best practice for discriminating between responses that have been successfully fulfilled against the client's intention for that request, and responses served through exceptional behaviour?

问题通过以下方式消除：通过响应机构进行隧道响应，因为我们可以确保这些响应对我们的服务是独一无二的。但是，似乎没有RESTful！

The problem is eliminated by tunnelling responses through the response body, as we can ensure these are unique to our service. However, doesn't seem very RESTful!

推荐答案

只需让您的应用程序在其HTTP响应中添加一些内容，以区别于中介机构提出的回应。任何或所有这些都可行：

Simply have your application add some content to its HTTP responses that will distinguish them from the responses thrown by intermediaries. Any or all of these would work:

• 有关响应内容中可识别为应用程序内容的错误的信息（例如，申请错误：未找到域名（404））


• A Content-Type 响应中的标头，指示响应内容应解码为应用程序错误（例如， Content-Type：application / vnd.domain-finder.error + json ）


• 响应中的自定义标头表示它是应用程序错误

• Information about the error in the response content that is recognizable as your application's content (for example, Application error: Domain name not found (404))
• A Content-Type header in the response that indicates that the response content should be decoded as an application error (for example, Content-Type: application/vnd.domain-finder.error+json)
• A custom header in the response that indicates it is an application error

一旦你实现这样的方案，你的API客户端需要知道你选择的机制，如果他们想要对应用程序错误和基础设施错误作出不同的反应，那么只需清楚地记录它。

Once you implement a scheme like this, your API clients will need to be aware of the mechanism you choose if they want to react differently to application errors versus infrastructure errors, so just document it clearly.

这篇关于使用HTTP状态代码时区分基础架构和业务逻辑的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！