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 想通过该博文展示的解决方法是架构纯性和真实互操作性之间的合理平衡点吗？请一定看看原博文并加入你的观点。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论