如何正确发送406状态代码？ [英] How to properly send 406 status code?

问题描述

我正在开发一个RESTful API服务，最初只接受JSON格式的响应。我想遵循标准，如果请求者的接受标题与JSON不同，我想用406 HTTP状态代码响应通知请求者我不能以其他格式输出数据。

I'm developing a RESTful API service which initially will only be accepting and responding in JSON format. I want to follow standards and in case of requester's Accept header was different than JSON I want to respond with 406 HTTP status code to inform the requester I cannot output data in other format.

根据 W3 我应该包含一个实体，其中包含可用实体特征和位置的列表，用户或用户代理可以从中选择最合适的。

我该怎么做，因为上面的解释并没有告诉我多少。什么是提到的实体？

How do I do that, because the above explanation doesn't tell me much. What is the mentioned entity?

任何想法/建议？

编辑

最初我认为可能是 Content-Type中逗号分隔的列表标题，但重新思考后我可能会做同样的事情浏览器并使用接受标题？这实际上更有意义，但我找不到任何支持这一点的信息。

Initially I thought that maybe could be a comma separated list in Content-Type header but after rethinking maybe I should do the same thing browsers do and use Accept header? This makes much more sense actually, but I cannot find any information to support this.

推荐答案

这里有三个问题：

首先，来自RFC 2616的注释旨在解决URI方案，其中不同类型的响应在各种URI处可用，例如/path/to/thing.xmlvs /path/to/thing.json。这并不总是一个受欢迎的选择，但如果你能做到这一点，那么这样做并在实体中包含每个超链接的超链接;也就是说，在回应的主体中。由于RFC没有为此类链接强制使用内容类型或处理模型，因此您可以自行决定如何返回这些链接，但HTML <* c $ c>< a> 标签是常见且有用的。

First, the note from RFC 2616 is meant to address URI schemes where responses of different types are made available at various URI's, such as "/path/to/thing.xml" vs "/path/to/thing.json". That's not always a popular choice, but if you can do that, do so and include hyperlinks to each one in the "entity"; that is, in the body of the response. Since the RFC doesn't mandate a Content-Type or processing model for such links, you're on your own regarding how to return them, but HTML with <a> tags is common and useful.

如果您不想在单独的URI上公开多个类型，但只想在原始URI上公开一种类型，那么它就完美了很好地响应406和一个简单说明资源可以发出哪种类型的实体。

If you don't want to expose multiple types at separate URI's, but just want to expose one type at the original URI, then it's perfectly fine to respond with 406 and an entity that simply says which types the resource can emit.

其次，请注意大多数网络浏览器发送 * / * Accept标头中的（质量值较低），应与任何Content-Type匹配。此外，规范说......如果不存在Accept头字段，则假定客户端接受所有媒体类型。所以你应该筹集406的情况很少见。

Second, note that most web browsers send */* in the Accept header (with a low quality value), which should match any Content-Type. In addition, the spec says "...if no Accept header field is present, then it is assumed that the client accepts all media types." So the cases where you should be raising 406 are rare.

第三，不要发出Content-Type响应头，它不是Content-Type的内容类型响应实体。 不应该用于列出可接受的类型。您还应该不发出名为'Accept'的响应标头; 'Accept'标题仅用于请求;请参阅 http://www.w3.org/Protocols/rfc2616/ rfc2616-sec14.html＃sec14.1

Third, don't emit a Content-Type response header that is anything other than the Content-Type of the response entity. It should not be used to list acceptable types. You should also not emit a response header named 'Accept'; the 'Accept' header is for requests only; see http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1

这篇关于如何正确发送406状态代码？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！