MIME 给 REST 的采用带来了问题？

随着 REST（和 REST/HTTP）被人们越来越多地用于除了运行Web 服务器之外的更多工作，我们看到越来越多的人将现实世界的经验带入到这一个更广阔的社区（网络和REST 的世界）。在这种背景下， Benjamin Carlyle 提出了 MIME 是否阻碍了 REST 的采用的问题。

我认为 HTTP 的一个重大缺点是它依赖于 MIME 标准及相关的 IANA（Internet 号分配机构）注册库对多媒体类型进行识别。该注册库是一个瓶颈，因为它对于那些仅限于个别企业或域的那些多媒体类型的定义无能为力。以计算机为中心的环境比以人为中心的环境对语义的依赖性更大。为使计算机有效地挖掘信息以及多媒体类型能够被个性化地标识，多媒体类型信息中的任何唯一的格式都应该标准化。随着计算机在分布式计算环境中的地位越来越重要，加上独特计算环境的数目的增长，多媒体类型的数量也随之增长。

正如 Benjamin 所指出的，问题是对各式各样的 MIME 类型的全盘采用是极其困难的，而且不能扩展。如果没能理解某多媒体类型是什么以及它怎么工作，仅仅要达成如“为什么需要某种特定类型的多媒体”这样的协议都是非常困难的。

在 Web 之外通过实验的方法定义和发展这些标准的能力对于健康采用 REST 风格以及相关的超出 Web 范围的风格是至关重要的。

随后 Benjamin 提出了一些替代方法。第一个应该是使用统一资源名称（URN，Uniform Resource Name），特别当它们现在已经提供分散的注册表。但是它又指出这个做法也有问题。 “首先是 HTTP 不允许它们在合适的 HTTP 头中使用；第二个是当 URN 被读取时，不能进一步被解释；第三是 URN 不能作为 MIME 类型而被参数化。” MIME 类型提供了跨越不同类型进行一致性和合规性定义的强大支持，而仅用 URN 就很难做到这点。他继续对 HTTP 作一些的修改的建议，从而可能对使用 URN 替换 MIME 类型有所帮助，例如：

对 HTTP 进行修改可能是解决这些问题的方法，让其包含对多媒体类型的 URI 语法的支持，还需要一个协议使得处理器可以了解一个多媒体类型是否继承自另一类型.[ ……] 可以选择在对某一个 URI 的 GET 操作的响应中使用 HTTP 头，也可以为多媒体类型的描述指定一个新的多媒体类型。使用链接头的显而易见的做法可能是形如这样的链接： rel=&rel=“inherits”。然而，这个方法有些局限。一个实际的描述多媒体类型的多媒体类型可能使用一小段 XML 文档或简单的人工可读的微格式（译注：是一种对 Web 网页进行语义注解的方法，参考微格式），而且更加通用且经得起时间的考验。

当然，如他所言，向后兼容性在 Web 的世界是非常重要的，所以，要做任何修改都必须要仔细考虑这个方面。然而，Benjamin 还真提供了另一种解决方法：一个遵循 MIME 语法分散的注册表。

URN 的替代方法是仅将 DNS 系统作为多媒体类型标识符的一部分。比如在 MIME 中注册一个“dns”子树。这个子树使得企业 / 组织能够安全地维护一组从应用 dns.com.example 开始的标识符，根本不需要 IANA 的协作。任何出现在该 DNS 树下的企业 / 组织都可以这么做。

这样就在尽可能不影响 HTTP 的情况下解决了向后兼容性的问题。它似乎同时还保留了 MIME 语法的优势，如继承。但是它仍然存在负面影响：

也许对这种方式对强列的反驳意见就是它失去了对标准文档的发现能力。URL 可以很容易地找到他所指向的规约文档，而这种混杂版的 DNS 和 MIME 还需要更多帮助才能具有这个能力。也许有必要某种机制把诸如此类的 MIME 标识符翻译成合适的 URL，从而能够很方便地找到它（URL）所引用的文档（如 robots.txt）及企业 URL 结构。

Benjamin 还提出了这些方法的一些变体，不过他总结到：

它伤透了我的心。我不想每次在公司里发布一种多媒体类型时都要联系 IANA。我喜欢 URL，但是它需要一个直接明了的方式去发现重要的继承关系。我不喜欢破坏 HTTP 的向后兼容性，而且没有更好的协议去支持 REST 的工作。该何去何从呢？

因此，就像文章中说的那样，目前的 MIME 的方式是有限制的？或者有其他可用的替代方法吗？或许 MIME 使用的问题还没有 MIME 协议作为新类型控制的方式时的问题那么多。

查看英文原文： Is MIME a problem for REST?