协议: 与其他系统交换结构化信息时所要遵循的一套格式、过程与规则
SOAP : 企业应用中所用的一种流利的协议
REST : 一种架构设计风格, 非常适合于面向移动设备的 Web Service
4.1.1 简单对象访问协议(SOAP)
简单对象访问协议(Simple Object Access Protocol, SOAP) 是个轻量级协议, 用于通过可扩展标记语言(Extensible Markup Language, XML) 实现系统间的结构化数据交换.
SOAP 消息构成了 Web Service 栈的基础, 很多企业建立的服务层都以 SOAP 作为面向服务架构(Service-Oriented Architecture, SOA) 的基石, 可以服务于防火墙内外的客户端. 虽然 SOAP 结点间的消息传输通常都是单向的, 不过协议本身是支持双向通信的. SOAP 结点是逻辑上的处理单元, 可以发出、接收、处理或是中继 SOAP 消息.
SOAP 消息中包含信封, 信封中包含头和体, 如图 4-1 所示. 头是可选的, 如图 4-1 中的虚线对象所示, 其中包含服务级的信息, 通常是认证与会话管理数据. 体是消息的主要内容, 包含消息接收者所要的处理的信息. SOAP 可以使用各种传输层, 比如说 HTTP、E-Mail 及异步队列等. 这样, SOAP 就成为很多交互问题的解决方案, 不过它是在移动设备爆发之前设计的
消息体的内容与结构取决于接收系统. 一个体可以包含多个子元素, 每个元素都可以有命名空间. 每个元素包含接收者需要执行的操作以及必要的参数值. 下述代码片段展示了一个示例 SOAP 体:
后面看不下去了
4.1.2 表述性状态转移
表述性状态转移(Representational State Transfer, REST) 是由 Roy Fielding 于 2000 年作为其博士论文的一部分而提出的, 他是 RFC 超文本传输协议的主要作者. 虽然人们经常将 REST 看作标准或协议, 不过它实际上并不是: REST 是一种架构设计风格, 可以应用到 Web Service. 虽然 REST 是与 HTTP 1.1 同时发展起来的, 也经常与该协议发生关联, 不过它并不仅仅限于 HTTP 这一种应用层协议. REST 设计风格最大规模的实现就是万维网, 实现了 REST 风格接口的服务通常叫做 RESTful Service.
REST 的一项中心议题就是资源的概念, 资源具有全局标识符. 统一资源标识符(Uniform Resource Identifier, URI) 这一概念将 REST 与其他架构风格区分开来. 可以将资源看作独立于表示的任何东西. 比如, /user/accounts 可能是获取账户资源的 JSON 列表的一个端点. 此外, /user/account/123 可能是获取号码为 123 的这一账户资源特定镜像表示的一个端点.
REST 强调模式设计, 从资源的角度来实现, 而不像 SOAP 那样根据动作或服务来实现. 可以将资源标识符看作完整的句子: 有主语(比如/user/account/123) 和谓语(比如, 请求中使用的 HTTP 方法 - POST、GET、PUT 或 DELETE). 这样, REST 就可以实现机器与人类可读了.
RESTful 架构还有两个关键属性: 无状态与可缓存. 无状态交互要求请求包含所有必要的信息(通常情况下这些信息可能位于会话中) 来理解传输上下文. 这个请求传输的信息开销抵消了 REST 响应负载的一些好处, 不过通常情况下要比其他服务模式更加轻量级. 此外, 客户端可以更加轻松地缓存响应, 因为每个资源都有全局唯一的标识符. 诸如图片等静态资源可以使用内容分发网络(Content Deliverty Network, CDN) 进行托管, 因为它们可以缓存到广泛的服务器网络, 并且对请求作出快速响应. RESTful 服务中的端点可以返回不同的数据类型. 比如, 有些端点可能会以 JSON 格式的数据返回资源表示, 有些则可能会返回一张图片.
4.1.3 选择一种方式
基于 SOAP 的服务现在依然部署在很多企业中, 特别是那些使用着更加流行的套装软件解决方案(如 ERP 软件)的企业. SOAP 与 REST 尝试着通过不同的方式来解决相同的问题. 虽然没有一种协议是适合于所有场景的完美解决方案, 不过对于移动优化的服务层来说, REST 风格的服务架构是最佳设计.
一个错误的假定是 SOAP 要比 REST 更加安全. 之所以会出现这种假设是因为整个 SOAP 中包含了具体的安全方法, 名字叫做 WS-Security. 然而, 创建 WS-Security 的主要原因在于 SOAP 规范是独立于传输的, 我们无法对传输层的安全做出任何假设. 正如任何的安全应用一样, 安全必须被设计到架构中, 而且要遵循恰当的原则.
在移动世界中, 另一个不成立的假定是远程设备是可靠的. 在将 SOAP 用于网络中已知应用服务器之间的通信时, 这个假定可能是正确的. 不过对于移动设备来说(很容易被盗用), 这个假定就不正确了. 需要假定远程设备是不可靠的.
与其他数据协议一样, 安全需要良好的设计和原则, 这会贯穿于开发的生命周期中: REST 也不例外. 在设计 REST 的安全时一定要考虑到应用数据. 你必须仔细考虑清楚传输的数据, 确保只传递最少量的数据就能让应用的功能正常使用.
在使用 REST 时可能会出现个人身份信息暴露(Personally Identifiable Information,PII) 的问题, 在使用 HTTP 或 SOAP 时也面临着相同的问题. 除非绝对必要或是收益大于风险, 否则绝对不要将 PII 发送给移动设备. 虽然这稍微偏离了 REST 风格的约束, 不过来自于设备的请求应该利用服务器会话中的信息, 以验证任何请求负载的语义正确性.
如果实现得比较好, 那么 REST 风格的架构将是向移动信道发送资源的最佳方式. 除了本身的好处外, REST 服务还提供了如下最佳组合:
- 开发者熟知及生产力
- 性能
- 网络效率
- 解决安全问题
- 健壮
- 接口灵活除此之外, 一项最佳实践就是将所有的外部服务调用合并成为单个以 REST 风格构建的移动门面, 并以 JSON 格式传递资源, 这将在 4.2 节 "负载" 中进行介绍
