问题标签 [content-negotiation]

我想知道缓存如何与基于内容协商的 API 一起使用。由于要获取 XML 或 JSON 中的资源，因此 URI 将是相同的，例如：

该服务根据 Accept 类型标头返回 JSON / XML。缓存有多智能？

例如：

• 如果一个客户端使用 Accept 类型请求返回 XML。
• 响应由 Web 服务器缓存 1 分钟。
• 第二个客户端使用 Accept 类型请求相同的资源以返回 JSON

缓存检查是否接受/内容类型？或者这是否会导致 JSON 请求者获取 XML 数据，因为那是服务器缓存的内容？我希望这是一件如此明显的事情，它已经得到了照顾，否则，在 URI 中包含 .xml / .json 不是一个相当大的论点吗？

我想我的问题基本上是，我可以在仍然使用标准缓存技术的同时安全地使用内容协商吗？

我试图让我的 Rails 应用程序以正确的内容类型为 application/xhtml+xml 提供 XHTML 内容。理想情况下，内容协商使 IE 用户也有机会使用该网站。

鉴于 Rails 生成的所有 HTML 都标记为 XHTML 1.0 Transitional，我有点惊讶于没有明显的选项可以让 Rails 将标记作为 XHTML。我发现了这个http://blog.codahale.com/2006/05/23/rails-plugin-xhtml_content_type/，但它似乎适用于 1.1.2，我无法让它在 2.3.8 下正常工作。

我在这里错过了什么吗？

如果客户端以不支持的媒体类型向 HTTP 服务器发送数据，服务器会以“ 415 unsupported media type ”状态回复。但是如何告诉客户端支持哪些媒体类型呢？是否有标准或至少推荐的方法？还是只是将其作为文本写入响应正文？

我们使用 Accept 标头和 withFormat 方法在我们的服务中使用内容协商......我们面临的问题是，如果 Accept 标头的类型不受我们的服务支持，我们希望返回 406 http 状态。 ...任何人都可以给我们一些关于我们将如何去做的想法吗？

对于最近的一个项目，我们希望为我们的响应支持 XML 和另一种格式。

但是，我们无法控制 Accept 标头。因此我们配置了一个 ContentNegotiatingViewResolver 来使用请求参数：

然而，现在我想知道是否可以转而使用 @ResponseBody 和 HttpMessageConverter 实现来简化我需要维护的代码量。

但是，是否有类似的方法来确保将 reqeust 参数用于内容协商，而不是 Accept 标头？

我喜欢 JAX-RS（特别是 Jersey）的自动 HTTP 内容协商，即它能够通过“Accept”和/或“Content-Type”标头路由我的资源。但是我发现有时在发生冲突时它并没有给我足够的控制权。

例如，考虑以下端点：

我会在 Firefox 和 Chrome 之间得到不同的结果。Firefox 将映射到 HTML 端点，而 Chrome 将在我导航到每个端点 URL 时触发 XML 端点。它们之间的区别在于其 Accept 标头中列出的 MIME 类型的顺序。Chrome 发送以下内容：

与 Firefox 相比，它首先列出 HTML：

当所有的权重相同时，它会匹配第一个条目，这似乎是合乎逻辑的。但就我而言，我得到的结果与我想要的不同，因此最好确定一种更好的打破平局的方法。

我的问题：没有将标头信息注入这些方法并自己执行媒体类型处理，有没有办法在出现平局时“调整权重”？例如，我可以告诉它总是用 HTML 胜过 XML 吗？我的 RESTful 客户端对他们想要返回的类型非常明确，但浏览器对 Accept 标头的草率是出了名的。（我个人认为他们应该将 HTML 的权重略高于 XML，因为这是用户所期望的，但为时已晚。）

或者，我可以在某个集中位置只执行一次我自己的自定义内容协商吗？我不反对手动写出这个逻辑，但如果这意味着将它应用到我的资源的每一个实例上，我就不反对了。JAX-RS 是否有一些在管道中添加过滤器以在路由请求之前调整请求的概念？

当浏览器的 Accept 请求标头显示如下内容时：

这是否意味着application/xml,application/xhtml+xml和text/html所有的质量参数都是0.9?

或者这是否意味着application/xml并且application/xhtml+xml具有默认值 ( q=1) 并且text/html具有q=0.9参数？

我假设是前者，但希望有人更明确地知道。

我正在使用 JSONP 在 Spring MVC 中调用控制器服务。我有一个自定义过滤器，它返回包含在回调中的结果。我使用了这个例子，http://jpgmr.wordpress.com/2010/07/28/tutorial-implementing-a-servlet-filter-for-jsonp-callback-with-springs-delegatingfilterproxy/。我也在使用 ContentNegotiatingViewResolver 但我的结果在回调中不断返回 XML。为什么会一直这样？

servlet-context.xml

我在哪里可以找到以下 HTTP 标头的所有可能的内容符号？

• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language

基于以下问题REST Content-Type: 它应该基于扩展还是接受标头中的信息？，我知道自定义 URI 或指定 Accept Headers 是 REST-ish Web 服务确定客户端响应格式的“可接受”（双关语）方法。

但是，很多大牌似乎都在他们的 API 中使用了自定义 URI 方法。一种方式相对于另一种方式的优势是什么？