Code Copied

REST介绍

REST简介

REST(Representational State Transfer)是 Roy Fielding 博士在2000年提出来的一种软件设计风格。它是针对网络应用的设计和开发方式,可以降低开发的复杂性,提高系统的可伸缩性。目前在三种主流的Web服务实现方案中,因为REST模式与发杂的SOAP和XML-PRC相比更加简洁,越来越多的web服务开始采用REST风格设计和实现。

REST定义

REST即“表述性状态转移”,是一组架构约束条件和原则

需要注意的是,REST是设计风格而不是标准。REST通常基于HTTP(超文本传输协议,用来操作资源),URI(统一资源标识符,用来标识资源)和Hypertext(超文本,用来描述资源的内容与状态,我们可以用HTML、XML、JSON或者自定义格式的文本来描述任何一个资源)这些现有的广泛流行的协议和标准。

REST定义了一组体系架构原则,你可以根据这些原则设计以及系统资源为中心的Web服务。包括使用不同语言编写的客户端如何通过HTTP处理和传输状态。

Roy在他的论文中提出了一个RESTful应用应该具备的几点约束:

  • 每个资源都应该有一个唯一的标识
  • 使用标准的方法来更改资源的状态
  • Request和Response的自描述
  • 资源多重表述
  • 无状态的服务

当一个应用满足这几项原则时,这个应用才可称之为RESTful应用。

如果考虑使用它的Web服务的数量,REST近年来已经成为最主要的Web服务设计模式。事实上,REST对Web的影响非常大,由于其使用相当方便和简洁性,已经普遍取代了基于SOAP和WSDL的接口设计。

REST中的资源

REST中的资源所指的不是数据,而是数据和表现形式的组合。比如“最新访问的的10位会员”和”最活跃的10位会员“在数据上可能有重叠或者完全相同,而由于他们的表现形式不同,所以被归为不同的资源,这也就是为什么REST的全名是Representational State Transfer的原因。资源标识符就是URI,不管是图片,Word还是视频文件,甚至是一种虚拟的服务,也不管你是XML格式、txt格式还是其它文件格式,全部通过URI对资源进行唯一的标识。

对资源使一致的命名规则(naming scheme��最主要的好处就是你不需要提出自己的规则——而是依靠某个已被定义,在全球范围中几乎完美运行,并且能被绝大多数人理解的规则。像以下你构建的上一个应用(假设它不是采用RESTful方式构建的)中的任意一个高级对象(high-level object),那就很有可能看到许多从使用唯一标识中受益的用例。比如,如果你的应用中包含一个对顾客的抽象,那么我可以相当肯定,用户会希望将一个指向某个顾客的链接,能通过电子邮件发到同事那里,或则加入到浏览器的书签上,甚至写到纸上。更透彻地讲:如果在一个类似于Amazone的在线商城中,没有用唯一的ID(一个URI)标识它的每一件商品,可想而知这将是多么可怕的业务决策。

Web上有各种各样丰富的资源,浏览器是用户访问这些资源的媒介,通过浏览器将展示出资源的一种表现方式,或者一种表现状态。如果用户在页面中定向到其它资源的链接,则将访问该资源,并表现出它的状态。这意味着客户端应用程序随着每个资源表现状态的不同而发生状态转移,也即所谓的REST。

REST和HTTP

RESTful Web Service

HTTP协议时Web的标准之一,HTTP协议包含一些标准的操作方法,例如:GET, POST, PUT, Delete等,用这些方法能够实现对Web资源的CURD操作,下表列出了这些方法的操作定义。

HTTP方法 资源处理 说明
GET 读取资源(Read) 获取被请求URI(Request-URI)指定的信息(以实体的格式)。
POST 创建资源(Create) 在服务器上创建一个新的资源,并返回新资源的URI。
PUT 更新资源(Update) 指定URI资源存在则更新资源,指定URI资源不存在则创建一个新资源。
DELETE 删除资源(Delete) 删除请求URI指定的资源。

在REST应用中,默认通过HTTP协议,并且使用GET、POST、PUT和DELETE方法对资源进行操作,这样的设计风格和Web标准完全契合。

REST的最佳应用场景是公开服务,使用HTTP并遵循REST原则的Web服务,我们称之为RESTful Web Service。RESTful Web Service从以下三个方面进行资源定义:

  • 直观简短的资源地址:URI,比如:http://example.com/resources/
  • 传输的资源:Web Service接受与返回的互联网媒体类型,比如JSON,XML等
  • 对资源的操作:Web Service在该资源上所支持的一系列请求方法(比如:GET,POST,PUT或Delete)

下图展示了RESTful Web Service的执行流程

image

标准方法

接收URI的应用程序可以通过URI明确地做一些有意义的事情。如果你在公共汽车上看到一个URI,你可以将它输入浏览器的地址栏中并回车——但是你的浏览器如何知道需要对这个URI做些什么呢?

它知道如何去处理URI的原因在于所有的资源支持同样的接口,一套同样的方法(只要你乐意,也可以称为操作)集合。在HTTP中这被叫做动词(verb),这些方法的含义连同行为许诺都一起定义在HTTP规范之中。如果你是一名OO开发人员,就可以想象到RESTful HTTP方案中的所有资源都继承自类似于这样的一个类(采用类Java、C#的伪语法描述,请注意关键的方法):

class Resource
{
    Resource(URI u);
    Response Get();
    Response Post(Request r);
    Response Put(Request r);
    Response Delete();
}

由于所有资源使用了同样的接口,你可以依此使用GET方法检索一个表述(representation)——也就是对资源的描述。

因为规范中定义了GET的语义,所以可以肯定当你调用它的时候不需要对后果负责——这就是为什么可以“安全”地调用此方法。GET方法支持非常高效、成熟的缓存,所以在很多情况下,你甚至不需要向服务器发送请求。还可以肯定的是,GET方法具有幂等性[译注:指多个相同请求返回相同的结果]——如果你发送了一个GET请求没有得到结果,你可能不知道原因是请求未能到达目的地,还是响应在反馈的途中丢失了。

幂等性保证了你可以简单地再发送一次请求解决问题。幂等性同样适用于PUT(基本的含义是“更新资源数据,如果资源不存在的话,则根据此URI创建一个新的资源”)和DELETE(你完全可以一遍又一遍地操作它,直到得出结论——删除不存在的东西没有任何问题)方法。POST方法,通常表示“创建一个新资源”,也能被用于调用任意过程,因而它既不安全也不具有幂等性。

如果你采用RESTful的方式暴露应用功能(如果你乐意,也可以称为服务功能),那这条原则和它的约束同样也适用于你。如果你已经习惯于另外的设计方式,则很难去接受这条原则——毕竟,你很可能认为你的应用包含了超出这些操作表达范围的逻辑。请允许我花费一些时间来让你相信不存在这样的情况。

举例

来看下面这个简单的采购方案例子:

image

可以看到,例子中定义了两个服务程序(没有包含任何实现细节)。这些服务程序的接口都是为了完成任务(正是我们讨论的OrderManagement和CustomerManagement服务)而定制的。
如果客户端程序试图使用这些服务,那它必须针对这些特定接口进行编码——不可能在这些接口定义之前,使用客户程序去有目的地和接口协作。这些接口定义了服务程序的应用协议(application protocol)。

在RESTful HTTP方式中,你将通过组成HTTP应用协议的通用接口访问服务程序。你可能会想出像这样的方式:

image

可以看到,服务程序中的特定操作被映射成为标准的HTTP方法。

小结

  • HTTP协议和URI是Web的标准,同时也是组成REST的核心
  • 在Web中,一切可访问对象都是资源,资源可以用URI描述,URI就是资源本身
  • RESTful Web Service用于操作资源,通过HTTP的标准方法实现对资源的CURD操作

参考链接

http://www.infoq.com/cn/articles/rest-introduction

http://zh.wikipedia.org/wiki/REST