我正在开发一个 RESTful API 服务，它最初只会以 JSON 格式接受和响应。我想遵循标准，如果请求者的 Accept 标头与 JSON 不同，我想用 406 HTTP 状态代码进行响应，以通知请求者我不能以其他格式输出数据。
根据W3，我“应该包含一个实体，其中包含可用实体特征和位置的列表，用户或用户代理可以从中选择最合适的一个” .
我该怎么做，因为上面的解释并没有告诉我太多。提到的实体是什么？
有什么想法/建议吗？
编辑
最初我认为这可能是 Content-Type 标头中的逗号分隔列表，但在重新考虑之后，也许我应该做浏览器做的同样的事情并使用 Accept 标头？这实际上更有意义，但我找不到任何信息来支持这一点。
【问题讨论】：
标签： web-services rest http-headers http-status-codes
这里有三个问题：
首先，来自 RFC 2616 的注释旨在解决 URI 方案，其中在各种 URI 上提供不同类型的响应，例如“/path/to/thing.xml”与“/path/to/thing.json” ”。这并不总是一个受欢迎的选择，但如果你能做到这一点，那就这样做并在“实体”中包含指向每个链接的超链接；也就是说，在响应的正文中。由于 RFC 没有为此类链接强制要求 Content-Type 或处理模型，因此您可以自行决定如何返回它们，但带有 <a> 标签的 HTML 是常见且有用的。
如果您不想在单独的 URI 中公开多种类型，而只想在原始 URI 中公开一种类型，那么使用 406 和一个简单地说明资源可以发出哪些类型的实体进行响应是完全可以的。
其次，请注意大多数 Web 浏览器在 Accept 标头中发送 */*（具有低质量值），该标头应与任何 Content-Type 匹配。此外，规范说“......如果不存在 Accept 头字段，则假定客户端接受所有媒体类型。”所以你应该提高 406 的情况很少见。
第三，不要发出除了响应实体的 Content-Type 之外的任何内容的 Content-Type 响应标头。它应该不用于列出可接受的类型。您还应该不发出名为“Accept”的响应标头； “接受”标头仅用于请求；见http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1
【讨论】：
This service only delivers application/json
Accept 和 Content-Type 标头“正确”地做到这一点（尽管它可能有点 OTT）。我也知道浏览器倾向于发送 */* 在这种情况下将使用默认输出格式（在这种情况下为 JSON）。