定制媒体类型的扩增符合RESTful吗？

作者 Dilip Krishnan 译者 马国耀 发布于 2010年1月13日

领域

架构 & 设计,

运维 & 基础架构,

企业架构

主题

SOA ,

REST ,

版本化

Subbu Allamaraju在博客中重温了REST社区中的久辩不衰的话题（标准媒体类型和定制媒体类型的比较）并试图寻找使用他们的最佳实践。开篇他就提出了媒体类型使用相关的两分观点。

• 观点1：Web服务必须要使用标准媒体类型才符合RESTful。
• 观点2：定制媒体类型如同契约，对于维护交互可视性是至关重要的。

Subbu认为，若严格参考的话，观点1是来自Roy Fielding的论文中的一句话，“使用像application/vnd.example.myway+xml这样的媒体类型不符合RESTful”。而他认为理解这些媒体类型在实际使用时产生的影响要比从字面上听从论文的谕旨更为重要。然而，有人回复说，对论文的这样理解本身也是有争议的。

另一方面，他说，观点2通过使用定制媒体类型带来协议一级的消息可视性。

[…] 例如，假设一个表象使用application/xml去描述一个订单或影集，谁能知道它到底是哪个呢？而如果Web服务使用以下这样的媒体类型， application/vnd.example.po或application/vnd.example.album，那么任何人都能够理解该表象的语义，而根本不需要对表象体进行解析。按照这种思路，媒体类型是一种消息语义标识符，消息接收者可使用该媒体类型触发处理代码。

“那么，怎样才是正确的做法呢？”，他问到，然后他提出了自己的观点，希望能够找到一种较民主的最佳实践。

• 如果发送者使用标准的可扩展格式（如XML或JSON）描述表象，那么就使用标准的媒体类型，如application/xml 和application/json。
• 如果消息格式新发明的，那么就创建新的媒体类型。
• 如果只是寻找某种方式来传输XML或JSON消息的应用层语义，那么使用别的手段（如，XML命名空间和规范）。
• 如果目标是版本控制，则使用URI中的版本标识。

通过一个类Java语言的例子，他断言，尽管你可以从消息里面看到请求是如何处理的，但这却破坏了可视性。

就处理XML和JSON消息而言，形如application/xml和application/json的媒体类型已经足够了。[…] 基于URI的方式必须穿越整个协议栈。为了“架构纯粹性”或“ RESTful约定”而忽视真实世界的互操作性最终将引火自焚。

Subbu想通过该博文展示的解决方法是架构纯性和真实互操作性之间的合理平衡点吗？请一定看看原博文并加入你的观点。

---

查看英文原文：Is Proliferation Of Custom Media Types RESTFul?

译者 马国耀 关注企业级应用相关的开发、架构及思想的发展。尤其对Java EE、SOA、ESB和Cloud Computing等领域持有浓厚兴趣。

• 更早的 >