如何正确发送406状态码？
我正在开发一个 RESTful API 服务，最初只会以 JSON 格式接受和响应。我想遵循标准，如果请求者的 Accept 标头与 JSON 不同，我想用 406 HTTP 状态代码进行响应，以通知请求者我无法以其他格式输出数据。
根据 W3，我“应该包含一个包含列表的实体可用的实体特征和位置，用户或用户代理可以从中选择最合适的” 在我的回复中。
我该怎么做，因为上面的解释并没有告诉我太多。提到的实体是什么？
有什么想法/建议吗？
编辑
最初我认为可能是Content-Type标头中的逗号分隔列表，但重新思考后也许我应该做浏览器做的同样的事情并使用Accept< /strong> 标题？这实际上更有意义，但我找不到任何信息来支持这一点。
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.
According to W3 I "SHOULD include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate" in my response.
How do I do that, because the above explanation doesn't tell me much. What is the mentioned entity?
Any ideas/suggestions?
EDIT
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这里有三个问题：
首先，RFC 2616 的注释旨在解决 URI 方案，其中不同类型的响应可在各种 URI 上使用，例如“/path/to/thing.xml”与“/path/to/thing.xml”。 json”。这并不总是一种流行的选择，但如果你能做到这一点，那就这样做，并在“实体”中包含指向每个链接的超链接；也就是说，在响应的正文中。由于 RFC 没有强制要求此类链接的 Content-Type 或处理模型，因此您需要自行决定如何返回它们，但带有
标记的 HTML 很常见且有用。如果您不想在单独的 URI 中公开多种类型，而只想在原始 URI 中公开一种类型，那么使用 406 和一个简单说明资源可以发出哪些类型的实体进行响应是完全可以的。
其次，请注意，大多数网络浏览器在 Accept 标头中发送
*/*（具有低质量值），该标头应与任何 Content-Type 匹配。此外，规范还指出“...如果不存在 Accept 标头字段，则假定客户端接受所有媒体类型。”因此，您应该筹集 406 的情况很少见。第三，不要发出与响应实体的 Content-Type 不同的 Content-Type 响应标头。它不应该用于列出可接受的类型。您也不应该发出名为“Accept”的响应标头； “Accept”标头仅适用于请求；请参阅http://www.w3.org/Protocols/rfc2616/ rfc2616-sec14.html#sec14.1
Three issues here:
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.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.
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.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