当 Accept 标头不存在时如何执行内容协商答案

【问题标题】：How to perform Content Negotiation when the Accept header is not present当 Accept 标头不存在时如何执行内容协商
【发布时间】：2015-03-05 01:17:59
【问题描述】：

我一直在研究standards-based application framework called Maki，它旨在将网络上的“资源”隔离到单个 URL。但是，我发现许多 HTTP 客户端没有提供足够的信息，尤其是在 Content Negotiation 的上下文中。

例如，a podcast hosted using this framework 期望在/shows 上提供“Shows”集合，它会根据传入的请求以适当格式的内容进行响应。例如，accessing the page with a web browser 呈现剧集的 HTML 列表，而当客户端指定需要 XML 时，相同的 URL 将返回 Atom 提要：

$ curl -H "Accept: application/xml" https://decentralize.fm/shows
<?xml version="1.0" encoding="utf-8" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:cc="http://web.resource.org/cc/" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:media="http://search.yahoo.com/mrss/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <channel>
  ...
  </channel>
</rss>

但是，我注意到许多（大多数！）HTTP 客户端（包括 iTunes）上的标头不发送 Accept 标头，在这种特殊情况下期望 XML 响应。这是为什么呢？

除了提供一个新 URL 以提供同一资源的 XML 格式版本之外，还有哪些替代方法可以确定如何格式化响应？

【问题讨论】：

标签： rest http rss atom-feed web-standards

【解决方案1】：

我要构建的核心概念，我观点的焦点，是“了解你的观众”的格言。您的基本响应（您最后的结果）应该是您的主要受众所期望的内容，无论您想要提供什么。因此，如果访问此 URL 的最大群体是 iTunes 客户端，则您需要提供适合 iTunes 的格式。请记住，您的主要受众决定了您应该提供什么，而不是相反。你并没有真正得到选择你的观众是谁的奢侈。您只能将您的内容放在那里并符合他们的要求。

其次，您可以/应该根据需要使用 Accept 标头。当然还有通过用户代理进行浏览器检测的老派粗略方法。另一件需要考虑的事情是，如果您尝试根据接受标头为同一个客户端提供多种内容类型，那么您实际上是在破坏客户端缓存，因为缓存是由 URL 决定的。

【讨论】：