Rest

Web 服务编程,REST 与 SOAP的比较 REST 简介 在开始我们的正式讨论之前,让我们简单看一下 REST 的定义。 REST (Representational State Transfer) 是 Roy Fielding 提出的一个描述互联系统架构风格的名词。为什么称为 REST？Web 本质上由各种各样的资源组成,资源由 URI 唯一标识。浏览器 (或者任何其它类似于浏览器的应用程序) 将展示出该资源的一种表现方式,或者一种表现状态。如果用户在该页面中定向到指向其它资源的链接,则将访问该资源,并表现出它的状态。这意味着客户端应用程序随着每个资源表现状态的不同而发生状态转移,也即所谓 REST。 关于 REST 本身,本文就不再这里过多地讨论,读者可以参考 developerWorks 上其它介绍 REST 的文章。本文的重点在于通过 REST 与 SOAP Web 服务的对比,帮助读者更深刻理解 REST 架构风格的特点,优势。 应用场景介绍 (在线用户管理) 本文将借助于一个应用场景,通过基于 REST 和 SOAP Web 服务的不同实现,来对两者进行对比。该应用场景的业务逻辑会尽量保持简单且易于理解,以有助于把我们的重心放在 REST 和 SOAP Web 服务技术特质对比上。 需求描述 这是一个在线的用户管理模块,负责用户信息的创建,修改,删除,查询。用户的信息主要包括: 用户名 (唯一标志在系统中的用户) 头衔 公司 EMAIL 描述 需求用例图如下: 图 1. 需求用例图 如图 1 所示,客户端 1 (Client1) 与客户端 2 (Client2) 对于信息的存取具有不同的权限,客户端 1 可以执行所有的操作,而客户端 2 只被允许执行用户查询 (Query User) 与用户列表查询 (Query User List) 。关于这一点,我们在对 REST Web 服务与 SOAP Web 服务安全控制对比时会具体谈到。下面我们将分别向您介绍如何使用 REST 和 SOAP 架构实现 Web 服务。 ...

基于REST的Web服务基础 代表性状态传输 (Representational State Transfer，REST) 在Web领域已经得到了广泛的接受，是基于SOAP和Web服务描述语言 (Web Services Description Language，WSDL) 的Web服务的更为简单的替代方法。接口设计方面这一转变的关键证据是主流Web 2.0服务提供者 (包括Yahoo、Google和Facebook) 对REST的采用，这些提供者弃用或放弃了基于SOAP和WSDL的接口，而采用了更易于使用、面向资源的模型来公开其服务。在本文中，Alex Rodriguez将向您介绍REST的基本原理。 基础 REST定义了一组体系架构原则，您可以根据这些原则设计以系统资源为中心的Web服务，包括使用不同语言编写的客户端如何通过HTTP处理和传输资源状态。如果考虑使用它的Web服务的数量，REST近年来已经成为最主要的Web服务设计模型。事实上，REST对Web的影响非常大，由于其使用相当方便，已经普遍地取代了基于SOAP和WSDL的接口设计。 REST这个概念于2000年由Roy Fielding在就读加州大学欧文分校期间在学术论文"Architectural Styles and the Design of Network-based Software Architectures"首次提出，他的论文中对使用Web服务作为分布式计算平台的一系列软件体系结构原则进行了分析，而其中提出的REST概念并没有获得现在这么多关注。多年以后的今天，REST的主要框架已经开始出现，但仍然在开发中，因为它已经被广泛接纳到各个平台中，例如通过JSR-311成为了Java? 6不可或缺的部分。 本文认为，对于今天正在吸引如此多注意力的最纯粹形式的REST Web服务，其具体实现应该遵循四个基本设计原则: ·显式地使用HTTP方法。 ·无状态。 ·公开目录结构式的URI。 ·传输XML、JavaScript Object Notation(JSON)，或同时传输这两者。 下面几个部分将详述这四个原则，并提供技术原理解释，说明为什么这些原则对REST Web服务设计人员非常重要。 显式地使用HTTP方法 基于REST的Web服务的主要特征之一是以遵循RFC 2616定义的协议的方式显式使用HTTP方法。例如，HTTP GET被定义为数据产生方法，旨在由客户端应用程序用于检索资源以从Web服务器获取数据，或者执行某个查询并预期Web服务器将查找某一组匹配资源然后使用该资源进行响应。 REST要求开发人员显式地使用HTTP方法，并且使用方式与协议定义一致。这个基本REST设计原则建立了创建、读取、更新和删除 (create, read, update, and delete，CRUD) 操作与HTTP方法之间的一对一映射。根据此映射: ·若要在服务器上创建资源，应该使用POST方法。 ·若要检索某个资源，应该使用GET方法。 ·若要更改资源状态或对其进行更新，应该使用PUT方法。 ·若要删除某个资源，应该使用DELETE方法。 许多Web API中所固有的一个令人遗憾的设计缺陷在于将HTTP方法用于非预期用途。例如，HTTP GET请求中的请求URI通常标识一个特定的资源。或者，请求URI中的查询字符串包括一组参数，这些参数定义服务器用于查找一组匹配资源的搜索条件。至少，HTTP/1.1 RFC是这样描述GET方法的。但是在许多情况下，不优雅的Web API使用HTTP GET来触发服务器上的事务性操作——例如，向数据库添加记录。在这些情况下，GET请求URI属于不正确使用，或者至少不是以基于REST的方式使用。如果Web API使用GET调用远程过程，则应该类似如下: GET /adduser?name=Robert HTTP/1.1 这不是非常优雅的设计，因为上面的Web方法支持通过HTTP GET进行状态更改操作。换句话说，该HTTP GET请求具有副作用。如果处理成功，则该请求的结果是向基础数据存储区添加一个新用户——在此例中为Robert。这里的问题主要在语义上。Web服务器旨在通过检索与请求URI中的路径 (或查询条件) 匹配的资源，并在响应中返回这些资源或其表示形式，从而响应HTTP GET请求，而不是向数据库添加记录。从该协议方法的预期用途的角度看，然后再从与HTTP/1.1兼容的Web服务器的角度看，以这种方式使用GET是不一致的。 除了语义之外，GET的其他问题在于，为了触发数据库中的记录的删除、修改或添加，或者以某种方式更改服务器端状态，它请求Web缓存工具 (爬网程序) 和搜索引擎简单地通过对某个链接进行爬网处理，从而意外地做出服务器端更改。克服此常见问题的简单方法是将请求URI上的参数名称和值转移到XML标记中。这样产生的标记是要创建的实体的XML表示形式，可以在HTTP POST的正文中进行发送，此HTTP POST的请求URI是该实体的预期父实体 (请参见清单1和2) : ...