如今,Web 开发者的可选技术相当之多;从简化的数据库访问技术,到易用的中间件服务包装技术,以及各种有趣的客户端软件等等,一应俱全。所有这些产品和工具,都是为了帮助 Web 开发者用最快的速度开发出最好的 Web 应用。
然而,拥有大量可选软件方案以及为 Web 应用的特定部分选用特定方案,都是具有挑战的事;而且,现在 Web 开发者必须持续跟踪各种不断变化着的标准与方法。
举个例子,Web 服务技术就有 SOAP(Simple Object Access Protocol,简单对象访问协议)和 REST(Representational State Transfer,表示性状态转移)这两种方案。它们都是有效的方案,但在具体场合下采用哪种方案好,这要取决于 Web 开发者。
目前,大部分 Web 开发者似乎都了解 REST——一种采用标准 URI 进行调用的方案。REST 很容易理解,而且只要是支持 HTTP/HTTPS 的客户端 / 服务器就支持它。你可以用 HTTP GET 方法来执行命令。所以,开发者们感受到的 REST 的优势是:开发简单、只需依托现有 Web 基础设施、以及学习成本低。
然而,SOAP 作为一种古老的 Web 服务技术,短期内还不会退出历史舞台。而且,随着 SOAP 1.2 的出现,SOAP 印象中的一些缺点已得到改进,采纳率和易用程度也都得到提高。另需注意的是,从 W3C SOAP 1.2 版开始,SOAP 这一缩写不再代表 Simple Object Access Protocol(简单对象访问协议),而是仅仅作为协议名称而已。
相对 REST 而言,SOAP 1.2 多出一些开销,不过这些开销也带来了一些好处。首先,SOAP 在三个方面离不开 XML(Extensible Markup Language,可扩展标记语言):SOAP 信封(envelope)是基于 XML 的,它定义了消息里有什么以及如何处理它;一套用于数据类型的编码规则;过程调用和响应的规划。SOAP 信封由传输协议(HTTP/HTTPS)发出,RPC(Remote Procedure Call,远程过程调用)得到执行,然后一个 XML 文档随 SOAP 信封返回。
需要注意的是,基于“通用”传输协议是 SOAP 的一个优点。REST 目前基于 HTTP/HTTPS;而 SOAP 可支持任何传输协议,从 HTTP/HTTPS 到 SMTP(Simple Mail Transfer Protocol,简单邮件传送协议),甚至 JMS(Java Messaging Service,Java 消息传递服务)。不过,由于 XML 较为冗长且解析费时,因此采用 XML 也成为一个弊端。
不过,对 Web 开发者来说的好消息是,目前上述两种方案都是行之有效的方案。REST 和 SOAP 都能解决许多 Web 方面的问题与挑战,而且在许多情况下,它们各自都能满足开发者的要求,也就是说可互换使用。
但很多人不知道,这两种技术可以混合搭配使用。REST 很好理解,且极易上手;不过由于它缺乏标准,因此只被看作是一种架构方法。与之相比,SOAP 是一个工业标准,它具备良好定义的协议,以及一套良好确立的规则,在大型和小型系统中均有采用。
因此,REST 的适用场合包括:
- 有限的带宽和资源 别忘了返回的结构可以采用(由开发者定义的)任何格式。另外,由于 REST 采用标准的 _GET_、PUT、_POST_ 和 _DELETE_ 动词,因此可被任何浏览器所支持。除此以外,REST 还可以使用为目前大多数浏览器支持的 _XMLHttpRequest_ 对象,这为 AJAX 增色不少。
- 完全无状态的操作 对于那些需多步执行的操作,REST 并非最佳选择,采用 SOAP 更合适。但是,如果你需要无状态的 CRUD(Create/Read/Update/Delete,创建 / 读取 / 更新 / 删除)操作,那么应采用 REST。
- 缓存考虑 若要利用无状态操作的特性,使得信息可被缓存,那么 REST 是很好的选择。
以上已经覆盖很多方案了,那么,为什么还要考虑 SOAP 呢?正如前述,SOAP 比较成熟而且是经过良好定义的,具有完整的规范。而 REST 只不过是一种方法,对开发未作任何规约;因此,假如你遇到以下场合,那么 SOAP 是最佳选择:
- 异步处理与调用 如果你的应用需要确保可靠性与安全性,那么请采用 SOAP。SOAP 1.2 为确保这种操作补充定义了 WSRM(WS-Reliable Messaging)等标准。
- 形式化契约 若提供者 / 消费者双方必须就交换格式取得一致,那么采用 SOAP 更合适。SOAP 1.2 为这种交互提供了严格的规范。
- 有状态的操作 如果应用需要上下文信息与对话状态管理,那么应采用 SOAP。SOAP 1.2 为此补充定义了 WS-Security、WS-Transactions 和 WS-Coordination 等标准。相比之下,REST 方法要求开发者自己来实现这些框架性工作。
正如你所看到的,REST 和 SOAP 各自有其用武之地。它们在安全性和传输层等方面有着自己的潜在问题,不过它们都能完成任务,而且在许多情况下,它们都丰富了 Web 的技术手段。因此,就这一论题,其实最好的原则就是灵活性原则;因为至少在现今的 Web 开发中,无论面对何种问题,Web 开发者们总有办法运用好这两种技术中的一种。
关于作者
Mike Rozlog 是 Embarcadero 科技公司的高级产品主管。他的主要工作是确保 Embarcadero 公司推出开发工具满足全世界开发者们的期望。他的大部分时间被致力于从技术和业务两个方面来介绍讲解 Embarcadero 的产品与服务,其听众是遍布全球分析师及其他听众。Mike 曾工作于 CodeGear,一个于 2008 年被 Embarcadero 收购的开发工具团队。之前,他为 Borland 公司工作了八年,担任过包括首席技术架构师在内的许多职位。作为一名知名作者,Mike 出版了很多书。他最近的作品 _《Mastering JBuilder》_ 已由 John Wiley & Sons 出版。
给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。
评论