Discriminating between infrastructure and business logic when using HTTP status codes

问题

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.

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 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.

2. 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?

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!

回答1:

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:

• 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

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.

回答2:

I tend to follow the "do what's RESTful as long as it makes sense" line of thinking.

Let's say you have an API that looks like this:

/api/v1/domains/<name>/

Hitting /api/v1/domain/exists.com/ could then return a 200 with some whois information.

Hitting /api/v1/domain/doesnt.com/ could return a 404 with links to purchase options.

That would probably work. If the returned content follows a strict format (e.g. a JSON response with a results key) then your API's responses can be differentiated from your proxies' responses.

Alternatively, you could offer

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

This is now slightly less RESTful but it's still self-describing and (in my opinion) not that bad. Now every response can be a 200 and your content can reveal the results.

来源：https://stackoverflow.com/questions/23267329/discriminating-between-infrastructure-and-business-logic-when-using-http-status