rest - 如何在不存在 Accept header 时执行内容协商

Question

我一直在研究 standards-based application framework called Maki ，旨在将 Web 上的“资源”隔离到单个 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)的 header 不发送 Accept header ，在这种特殊情况下期望 XML 响应。这是为什么？

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

Answer 1

我构建的核心概念，即我的观点重点，是格言“了解您的受众”。你的基本 react (你的最后手段)应该是你的主要受众期望的内容，不管你想提供什么。因此，如果访问此 URL 的最大群体是 itunes 客户，则您需要提供 itunes 友好的格式。请记住，您的主要受众决定了您应该提供什么，而不是相反。你并没有真正选择你的听众是谁的奢侈。您只能将您的内容放在那里并符合他们的要求。

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