Internet 比 REST 更基本吗？

正当一些人认为争论已经陷入僵局或已结束的时候， Ganesh Prasad 又提出是存在一些比 REST 更基本（并更好）的东西，这无疑是给争论来了个火上浇油。正如他所讲，这个争论已经来来回回进行了好几轮了：

尽管我喜欢 REST，也把它当作是 SOA 的一个很优雅的模型，但每天都听到它比基于 SOAP 的 Web Services 模型怎么怎么好，确实有些厌烦。事实上，厌烦到我要学同样的方式对 REST 支持者做这种令人不舒服的姿态。

然后，他列举了一些 REST 支持者们用来做论据的核心思想：

REST 充分利用了现有最具伸缩性的应用（Web）的特性，不是吗？REST 与 Web 根本不冲突，它们一起工作的很好，不是吗？HTTP 是一个应用协议，而不止是一个传输协议，不是吗？URI 是定位资源的最自然的方式，HTTP 的标准动词是暴露使用资源可以做什么的最自然方式，超文本链接也是把这些连接起来以使整个系统成为一个状态机的最自然途径，难道不是吗？

然而，在他的观点里，随着 Internet 的成熟并更加具有扩展性，它比 REST 的扩展性更好也更具弹性。使用 Internet 模型（“它只是在智能网络中负责节点之间的消息传递”）会使你：

……Internet 的哲学是“傻瓜网络，智能端点”（当然请记住，这个网络不是真“傻”，而是故意只做些弹性包裹传递而把聪明藏了起来）。而被 Internet 用来传送包裹的协议，当然就是 Internet 协议（IP）。

而当你要添加新功能的时候，它简单得就像：

只用创建你自己的端对端协议并使用 IP 包承载你的消息有效负荷完成节点间的通信。你不用向任何“中间人”咨询或协商。事实上根本没有什么中间环节。

当 Ganesh 谈到 TCP 在 Internet 中的角色时（UDP 再一次被遗忘在历史的垃圾箱中），低级的的通信协议和更高级的应用协议栈的区别就显得清楚了：

TCP 在端点被解释。这就是为什么计算机上的网络软件都叫做 TCP 协议栈的原因。每一个连接到 IP 网络的计算机都可以叫做端点，只要一个 IP 地址就可以定位。端点负责处理 IP 消息的内部信息，而 Internet（即 IP 网络）完全不知道什么是 sockets 和端口号。这些概念都是由在它之上的协议创建和使用的。Internet 具有的扩展性和层次架构使得在不影响弹性包路由能力的基础上可以进行一个更复杂的网络抽象操作。

当然这个讨论和一直有关于 REST，SOA，WS-* 和面向消息的架构的讨论有些相似，因为达到松散耦合和伸缩性的核心原理是一样的：在服务端点后隐藏尽可能多的东西。为了证明 Internet 在变更需求时是多么的具有弹性和灵活，Ganesh 谈到了 IPSec，并问（修辞性地）是否添加了 IPSec 就对 Internet 做了大的改动：

……他们只是创建了另一个称为 ESP（Encapsulating Security Payload）的端到端协议和能够解释协议的端点。即他们在 TCP 和 IP 之间添加了一层新的协议。

在进一步参考“即使在电信领域Internet 也打败了电信网络”的时候，Ganesh 继续解释了为什么 REST（和 Web）并不比其他的分布式计算架构更优越。

Internet 是一个分散创新的平台。（见鬼，你们这些在大家面前晃来晃去的 REST 支持者们用的万维网就是一个在 Internet 上创新的例子。HTTP 不就是一个端到端的协议，不是吗？）

但 WS-* 哪里去了？到目前为止只讨论了 Internet VS REST（事实上是 Web），而没有 Web Services 或 SOAP。然而，在 SOAP-RPC 被遗忘了一阵儿之后，Ganesh 清楚地表示他对 SOAP 消息的定义是“带有 WS-Addressing 头的 SOAP 消息”，因为就像一个 IP 包，WS-Addressing 的使用同样给了你的消息能够独立路由的能力。然后他通过一些漂亮的图帮助阐述了这种关联性。

现在想象一个消息传输架构，它只能路由 SOAP 消息……我们如何进行创新并在此之上建立更高级的功能呢？唉，当然是学 Internet 的模型啦。为每一个新功能创建一个协议并把协议数据嵌入到 SOAP 消息里面（尤其是 SOAP 的头部）。不需要把它们放在 TCP 协议栈里，因为可靠性传输，安全，事务等等都是正交无关的。可以把它们放到 SOAP 的头部作为同一层存在…

通过这种方式，我们最后得出的一点是“一个松散耦合的服务生态系统需要象管道一样随意装配”。当然这并不足以创建基于 SOA 的应用（象其他有些人一样，Ganesh 好像把 SOA 和），这时 XML 成了救世主。Web Services 画上了等号

那么现在请使用一种 XML 模式定义语言和你选择的词汇（为银行，保险或航空业）来定义文档契约，把对应的 XML 文档象我们谈到过的一样嵌入到 SOAP 消息体中，并保证消息的生产者和消费者都只依赖于那些文档契约。这样就可以了！松散耦合的组件！面向服务的架构！

假如真的象在现实世界的标准中真的那么简单，你得到的也只是一些一般的要点。但如果真的那么容易，有一个明显的问题就是：为什么我们还没有做到呢？Ganesh 认为这背后有六个原因：

1. 现有的 SOAP-RPC：“即使在今天，还有一种思潮说使用 WSDL 就意味着 RPC ，但我对于被包装的 document/literal 风格感到满意，它让我们远离了喧嚣的 RPC encoding”。
2. 除了 HTTP 之外，SOAP 缺少绑定相关的标准
3. 需要穿越防火墙的隧道，这和 SOAP/HTTP 缺省绑定有关。“我们需要为 SOAP 自己指定一个端口，并使防火墙对此端口开放。不要因为我们喜欢 80 端口就一直使用 HTTP。”
4. “集中消息代理软件提供商还在假装接受 SOAP/WS-* 的远景（‘我们在标准委员会里！’），但其实他们还在以中间件谋生，而不是端点软件。”
5. 业界还在被未开放源码的 WS-* 协议栈所统治。
6. 事实上，很多重要的 WS-* 规范（事务、安全、可靠性等）最近才成熟（不论是被使用的，还是开发了 5 年的）。

最后，他相信 SOA 只有两种可行的途径，就是 REST 和“采用智能端点的 SOAP 消息传输处理”，而其中 REST 并不占明显的优势。

查看英文原文： http://www.infoq.com/news/2007/12/rest-ws-payback - - - - - -

译者简介：戴垚，2000 年计算机硕士毕业后一直从事软件开发管理工作，目前在一家大型外企担任开发部门经理。关心软件技术和相关工具的动态，深信技术的使用应以创造价值为根本。目前致力于 SOA 的研究，希望能对业已复杂的企业环境有所帮助。参与 InfoQ 中文站内容建设，请邮件至 china-editorial@infoq.com 。