REST技术调研,三种流行的WEB服务架构

SOAP RPC over HTTP

面向服务的架构(面向消息)。简单对象访问协议（SOAP，全写为 Simple Object Access Protocol）是一种标准化的通讯规范，主要用于 Web 服务（web service）中。SOAP 的出现是为了简化网页服务器（Web Server）在从 XML 数据库中提取数据时，无需花时间去格式化页面，并能够让不同应用程序之间透过 HTTP 通讯协定，以 XML 格式互相交换彼此的数据，使其与编程语言、平台和硬件无关。

XML RPC over HTTP

远程过程调用 (面向方法)。这种远程过程调用使用 HTTP 作为传输协议，XML 作为传送信息的编码格式。XML-RPC 的定义尽可能的保持了简单，但同时能够传送、处理、返回复杂的数据结构。XML-RPC 是工作在 Internet 上的远程过程调用协议。一个 XML-RPC 消息就是一个请求体为 XML 的 HTTP POST 请求，被调用的方法在服务器端执行并将执行结果以 XML 格式编码后返回。

REST over HTTP

面向资源。

REST设计原则

显式地使用 HTTP 方法

基于 REST 的 Web 服务的主要特征之一是以遵循 RFC 2616 定义的协议的方式显式使用 HTTP 方法。例如，HTTP GET 被定义为数据产生方法，旨在由客户端应用程序用于检索资源以从 Web 服务器获取数据，或者执行某个查询并预期 Web 服务器将查找某一组匹配资源然后使用该资源进行响应。

REST 要求开发人员显式地使用 HTTP 方法，并且使用方式与协议定义一致。 这个基本 REST 设计原则建立了创建、读取、更

新和删除（create, read, update, and delete，CRUD）操作与 HTTP 方法之间的一对一映射。 根据此映射： • 若要在服务器上创建资源，应该使用 POST 方法。 • 若要检索某个资源，应该使用 GET 方法。

• 若要更改资源状态或对其进行更新，应该使用 PUT 方法。 • 若要删除某个资源，应该使用 DELETE 方法。

无状态设计

REST Web 服务需要扩展以满足日益提高的性能要求。 具有负载平衡和故障转移功能、代理和网关的服务器集群通常以形成服务拓扑的方式进行组织，从而允许根据需要将请求从一个服务器路由到另一个服务器，以减少 Web 服务调用的总体响应时间。 要使用中间服务器扩大规模，REST Web 服务需要发送完整、独立的请求；也就是说，发送的请求包括所有需要满足的数据，以便中间服务器中的组件能够进行转发、路由和负载平衡，而不需要在请求之间 在本地保存任何状态。

完整、独立的请求不要求服务器在处理请求时检索任何类型的应用程序上下文或状态。 REST Web 服务应用程序（或客户端）

在 HTTP Header 和请求正文中包括服务器端组件生成响应所需要的所有参数、上下文和数据。 这种意义上的无状态可以改进 Web 服务性能，并简化服务器端组件的设计和实现，因为服务器上没有状态，从而消除了与外部应用程序同步会话数据的需要。

服务器

1.生成响应，其中包括指向其他资源的链接，以使得应用程序可以在相关资源之间导航。 此类响应嵌入了链接。 类似地，如果请求是针对父或容器资源，则基于 REST 的典型响应还可能包括指向父资源的子资源或从属资源的链接，以便这些资源保持连接在一起。

2.生成响应，其中指明了是否可缓存，以通过减少针对重复资源的请求数量或通过完全消除某些请求来改进性能。 服务器通过包

括 Cache-Control 和 Last-Modified（日期值）HTTP 响应 Header 实现此目的。

客户端应用程序

1.使用 Cache-Control 响应 Header 确定是否缓存资源（创建资源的本地副本）。 客户端还读取 Last-Modified 响应 Header，

并在 If-Modified-Since Header 中发回日期值，以向服务器询问资源是否已更改。 这称为条件 GET (Conditional GET)，两个 Header 同时进行，因为服务器的响应为标准 304 代码 (Not Modified)，如果请求的资源自从该时间以后尚未更改，则省略实际的资源。 HTTP 响应代码 304 意味着客户端可以安全地将资源表示形式的缓存本地副本作为最新版本使用，从而实际上跳过了后续 GET 请求，直到资源更改为止。

2.发 送可独立于其他请求得到服务的完整请求。 这要求客户端充分利用 Web 服务接口指定的 HTTP Header，并在请求正文

中发送完整的资源表示形式。 客户端发送的请求极少对先前的请求、某个会话在服务器上的存在性、服务器向请求添加上下文的能力或请求之间保留的应用程序状态做出假设。

客户端应用程序与服务之间的这种协作对于基于 REST 的 Web 服务中的无状态性极为重要。 它通过节省带宽和最小化服务器

端应用程序状态改进了性能。

有状态设计

在 Java Platform, Enterprise Edition (Java EE) 环境中，有状态的服务需要大量的预先考虑，以高效地存储会话数据和支持整个 Java EE 容器集群中的会话数据同步。 在此类环境中，存在一个 Servlet/JavaServer Pages (JSP) 和 Enterprise JavaBeans (EJB) 开发人员非常熟悉的问题，他们经常在会话复制过程中艰难地查找引发 java.io.NotSerializableException 的根源。 无论该异常是由 Servlet 容器在 HttpSession 复制过程中引发的，还是由 EJB 容器在有状态的 EJB 复制过程中引发的，这都是个问题，会耗费开发人员几天的时间，尝试在构成服务器状态并且有时非常复杂的对象图表中查明没有实现 Serializable 的对象。 此外，会话同步增加了开销，从而影响服务器性能。

另一方面，无状态的服务器端组件不那么复杂，很容易跨进行负载平衡的服务器进行设计、编写和分布。 无状态的服务不仅性

能更好，而且还将大部分状态维护职责转移给客户端应用程序。 在基于 REST 的 Web 服务中，服务器负责生成响应，并提供使客户端能够独自维护应用程序状态的接口。

下图演示了一个有状态的服务，某个应用程序可能向其请求多页结果集中的下一个页面，并假设该服务跟踪应用程序在结果集中

导航时的离开位置。 在这个有状态的设计中，该服务递增并在某个位置存储 previousPage 变量，以便能够响应针对下一个页面的请求。

公开目录结构式的 URI

URI 具有层次结构，其根为单个路径，从根开始分支的是公开服务的主要方面的子路径。 根据此定义，URI 并不只是斜杠分隔

的字符串，而是具有在节点上连接在一起的下级和上级分支的树。 例如，在一个收集从 Java 到报纸的各种主题的讨论线程服务中，您可能定义类似如下的结构化 URI 集合：

http://www.myservice.org/discussion/topics/{topic}

根 /discussion 之下有一个 /topics 节点。 该节点之下有一系列主题名称，例如闲谈、技术等等，每个主题名称指向某个讨论

线程。 在此结构中，只需在 /topics/ 后面输入某个内容即可容易地收集讨论线程。

在某些情况下，指向资源的路径尤其适合于目录式结构。 例如，以按日期进行组织的资源为例，这种资源非常适合于使用层次

结构语法。

例如：http://www.myservice.org/discussion/2008/12/10/{topic}

在考虑基于 REST 的 Web 服务的 URI 结构时，需要指出的一些附加指导原则包括：

1.隐藏服务器端脚本技术文件扩展名（.jsp、.php、.asp）——如果有的话，以便您能够移植到其他脚本技术而不用更改 URI。 2.将所有内容保持小写。

3.将空格替换为连字符或下划线（其中一种或另一种）。

4.尽可能多地避免查询字符串。

5.如果请求 URI 用于部分路径，与使用 404 Not Found 代码不同，应该始终提供缺省页面或资源作为响应。

URI 还应该是静态的，以便在资源发生更改或服务的实现发生更改时，链接保持不变。 这可以实现书签功能。 URI 中编码的资源之间的关系与在存储资源的位置表示资源关系的方式无关也是非常重要的。

Rest实现

JAX-RS(Java API for RESTful Web Services (JSR-311) )为 在 Java 上构建 RESTful 风格的 web services 提供了一组标准

API。这组API基本上由一组注解(annotations)和相关的类和接口组成的。

JAX-RS提供了一些标注将一个资源类，一个POJO Java类，封装为Web资源。标注包括： @Path，标注资源类或者方法的相对路径

@GET，@PUT，@POST，@DELETE，标注方法是HTTP请求的类型。 @Produces，标注返回的MIME媒体类型 @Consumes，标注可接受请求的MIME媒体类型

@PathParam，@QueryParam，@HeaderParam，@CookieParam，@MatrixParam，@FormParam,分别标注方法的参数来自于HTTP请求的不同位置，例如@PathParam来自于URL的路径，@QueryParam来自于URL的查询参数，@HeaderParam来自于HTTP请求的头信息，@CookieParam来自于HTTP请求的Cookie。

基于JAX-RS实现的框架有CXF，Jersey，Restlet，RESTEasy等。现在SpingMVC也已经支持REST了。