REST介绍

概述 
    REST是英文Representational State Transfer的缩写，中文翻译：表述性状态转移。 

    他是由Roy Thomas Fielding博士在他的论文 《Architectural Styles and the Design of Network-based Software Architectures》中提出的一个术语。 

    REST本身只是为分布式超媒体系统设计的一种架构风格，而不是标准。 

    基于Web的架构，实际上就是各种规范的集合，这些规范共同组成了Web架构。比如Http协议，比如客户端服务器模式，这些都是规范。每当我们在原有规 范的基础上增加新的规范，  就会形成新的架构。而REST正是这样一种架构，他结合了一系列的规范，而形成了一种新的基于Web的架构风格。 
传统的Web应用大都是B/S架构，它包括了如下一些规范： 

1. 客户－服务器 

    这种规范的提出，改善了用户接口跨多个平台的可移植性，并且通过简化服务器组件，改善了系统的可伸缩性。最为关键的是通过分离用户接口和数据存储这两个关注点，使得不同用户终端享受相同数据成为了可能。 

2. 无状态性 

    无状态性是在客户－服务器约束的基础上添加的又一层规范。他要求通信必须在本质上是无状态的，即从客户到服务器的每个request都必须包含理解该 request所必须的所有信息。这个规范改善了系统的可见性（无状态性使得客户端和服务器端不必保存对方的详细信息，服务器只需要处理当前 request，而不必了解所有的request历史），可靠性（无状态性减少了服务器从局部错误中恢复的任务量），可伸缩性（无状态性使得服务器端可以 很容易的释放资源，因为服务器端不必在多个request中保存状态）。同时，这种规范的缺点也是显而易见得，由于不能将状态数据保存在服务器上的共享上 下文中，因此增加了在一系列request中发送重复数据的开销,严重的降低了效率。 

3.缓存 

为 了改善无状态性带来的网络的低效性，我们填加了缓存约束。缓存约束允许隐式或显式地标记一个response中的数据，这样就赋予了客户端缓存 response数据的功能，这样就可以为以后的request共用缓存的数据，部分或全部的消除一部分交互，增加了网络的效率。但是用于客户端缓存了信 息，也就同时增加了客户端与服务器数据不一致的可能，从而降低了可靠性。 

B/S架构的优点是其部署非常方便，但在用户体验方面却不是很理想。为了改善这种情况， 
我们引入了REST。 
REST在原有的架构上增加了三个新规范：统一接口，分层系统和按需代码。 

1.统一接口 
    REST 架构风格的核心特征就是强调组件之间有一个统一的接口，这表现在REST世界里，网络上所有的事物都被抽象为资源，而REST就是通过通用的链接器接口对 资源进行操作。这样设计的好处是保证系统提供的服务都是解耦的，极大的简化了系统，从而改善了系统的交互性和可重用性。并且REST针对Web的常见情况 做了优化，使得REST接口被设计为可以高效的转移大粒度的超媒体数据，这也就导致了REST接口对其它的架构并不是最优的。 

2.分层系统 
    分层系统规则的加入提高了各种层次之间的独立性，为整个系统的复杂性设置了边界，通过封装遗留的服务，使新的服务器免受遗留客户端的影响，这也就提高了系统的可伸缩性。 

3.按需代码 
    REST允许对客户端功能进行扩展。比如，通过下载并执行applet或脚本形式的代码，来扩展客户端功能。但这在改善系统可扩展性的同时，也降低了可见性。所以它只是REST的一个可选的约束。 

REST的设计准则 
    REST架构是针对Web应用而设计的，其目的是为了降低开发的复杂性，提高系统的可伸缩性。REST提出了如下设计准则： 

   1. 网络上的所有事物都被抽象为资源（resource）； 
   2. 每个资源对应一个唯一的资源标识符（resource identifier）； 
   3.通过通用的连接器接口（generic connector interface）对资源进行操作； 
   4. 对资源的各种操作不会改变资源标识符； 
   5. 所有的操作都是无状态的（stateless）。 

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

REST是基于Http协议的，任何对资源的操作行为都是通过Http协议来实现。以往的Web开发大 多数用的都是Http协议中的GET和 POST方法，对其他方法很少使用，这实际上是因为对Http协议认识片面的理解造成的。Http不仅仅是一个简单的运载数据的协议，而是一个具有丰富内 涵的网络软件的协议。他不仅仅能对互联网资源进行唯一定位，而且还能告诉我们如何对该资源进行操作。Http把对一个资源的操作限制在4个方法以内： GET, POST,PUT和DELETE，这正是对资源CRUD操作的实现。由于资源和URI是一一对应的，执行这些操作的时候URI是没有变化的，这和以往的 Web开发有很大的区别。正由于这一点，极大的简化了Web开发，也使得URI可以被设计成更为直观的反映资源的结构，这种URI的设计被称作 RESTful的URI。这位开发人员引入了一种新的思维方式：通过URL来设计系统结构。当然了，这种设计方式对一些特定情况也是不适用的，也就是说不 是所有的URI都可以RESTful的。 

    REST 之所以可以提高系统的可伸缩性，就是因为它要求所有的操作都是无状态的。由于没有了上下文(Context)的约束，做分布式和集群的时候就更为简单，也 可以让系统更为有效的利用缓冲池(Pool）。并且由于服务器端不需要记录客户端的一系列访问，也减少了服务器端的性能。  

使用REST架构 
    对于开发人员来说，关心的是如何使用REST架构，这里我们来简单谈谈这个问题。REST不仅仅是一种崭新的架构，它带来的更是一种全新的Web开发过程 中的思维方式：通过URL来设计系统结构。在REST中，所有的URL都对应着资源，只要URL的设计是良好的，那么其呈现的系统结构也就是良好的。这点 和TDD (Test Driven Development)很相似，他是通过测试用例来设计系统的接口，每一个测试用例都表示一系列用户的需求。开发人员不需要一开始就编写功能，而只需要 把需要实现的功能通过测试用例的形式表现出来即可。这个和REST中通过URL设计系统结构的方式类似，我们只需要根据需求设计出合理地URL，这些 URL不一定非要链接到指定的页面或者完成一些行为，只要它们能够直观的表现出系统的用户接口。根据这些URL，我们就可以方便的设计系统结构。从 REST架构的概念上来看，所有能够被抽象成资源的东西都可以被指定为一个URL，而开发人员所需要做的工作就是如何能把用户需求抽象为资源，以及如何抽 象的精确。因为对资源抽象的越为精确，对REST的应用来说就越好。这个和传统MVC开发模式中基于Action的思想差别就非常大。设计良好的URL， 不但对于开发人员来说可以更明确的认识系统结构，对使用者来说也方便记忆和识别资源，因为URL足够简单和有意义。按照以往的设计模式，很多URL后面都 是一堆参数，对于使用者来说也是很不方便的。 

    既然REST这么好用，那么是不是所有的Web应用都能采取此种架构呢？答案是否定的。我们知道，直到现在为止，MVC(Model-View- Controller) 模式依然是Web开发最普遍的模式，绝大多数的公司和开发人员都采取此种架构来开发Web应用，并且其思维方式也停留于此。MVC模式由数据，视图和控制 器构成，通过事件(Event)触发Controller来改变Model和View。加上Webwork,Struts等开源框架的加入，MVC开发模 式已经相当成熟，其思想根本就是基于Action来驱动。从开发人员角度上来说，贸然接受一个新的架构会带来风险，其中的不确定因素太多。并且REST新 的思维方式是把所有用户需求抽象为资源，这在实际开发中是比较难做到的，因为并不是所有的用户需求都能被抽象为资源，这样也就是说不是整个系统的结构都能 通过REST的来表现。所以在开发中，我们需要根据以上2点来在REST和MVC中做出选择。我们认为比较好的办法是混用REST和MVC，因为这适合绝 大多数的Web应用开发，开发人员只需要对比较容易能够抽象为资源的用户需求采取REST的开发模式，而对其它需求采取MVC开发即可。这里需要提到的就 是ROR(Ruby on Rails)框架，这是一个基于Ruby语言的越来越流行的Web开发框架，它极大的提高了Web开发的速度。更为重要的是，ROR(从1.2版本起)框 架是第一个引入REST做为核心思想的Web开发框架，它提供了对REST最好的支持，也是当今最成功的应用REST的Web开发框架。实际上，ROR的 REST实现就是REST和MVC混用，开发人员采用ROR框架，可以更快更好的构建Web应用。 

对开发人员来说，REST不仅仅在Web开发上贡献了自己的力量，同时也让我们学到了如何把软件工程原则系统地应用于对一个真实软件的设计和评估上。

 

 

 

 

简单理解：

（一）  首先REST只是一种风格 ，不是一种标准
（二）  REST是以资源为中心 的
（三）  REST充分利用或者说极端依赖HTTP协议

 

一．对于今天正在吸引如此多注意力的最纯粹形式的 REST Web 服务，其具体实现应该遵循以下基本设计原则：

1.1．显式地使用不同的 HTTP 请求方法
1.2．无状态
1.3．公开目录结构式的 URI(通过逻辑URI定位资源)。

 

1.1．显式地使用不同的 HTTP 请求方法

    我们在 Web 应用中处理来自客户端的请求时，通常只考虑 GET 和 POST 这两种 HTTP 请求方法。实际上，HTTP 还有 HEAD、PUT、DELETE 等请求方法。而在 REST 架构中，用不同的 HTTP 请求方法来处理对资源的 CRUD（创建、读取、更新和删除）操作：

    若要在服务器上创建资源，应该使用 POST 方法。 
    若要检索某个资源，应该使用 GET 方法。 
    若要更改资源状态或对其进行更新，应该使用 PUT 方法。 
    若要删除某个资源，应该使用 DELETE 方法。

 

经过这样的一番扩展，我们对一个资源的 CRUD 操作就可以通过同一个 URI 完成了：

[url]http://www.example.com/photo/logo[/url]（读取）--->
[GET] [url]http://www.example.com/photo/logo[/url]

 

[url]http://www.example.com/photo/logo/create[/url]（创建）--->
[POST] [url]http://www.example.com/photo/logo[/url]

 

[url]http://www.example.com/photo/logo/update[/url]（更新） --->
[PUT] [url]http://www.example.com/photo/logo[/url]

 

[url]http://www.example.com/photo/logo/delete[/url]（删除） --->
[DELETE] [url]http://www.example.com/photo/logo[/url]

 

从而进一步规范了资源标识的使用。

通过 REST 架构，Web 应用程序可以用一致的接口（URI）暴露资源给外部世界，并对资源提供语义一致的操作服务。这对于以资源为中心的 Web 应用来说非常重要。

 

1.2．无状态

 

在 REST 的定义中，一个 Web 应用总是使用固定的 URI 向外部世界呈现一个资源。
它认为Web是由一系列的抽象资源组成，这些抽象的资源具有不同的具体表现形式。
譬如，定义一个资源为photo，含义是照片，它的表现形式可以是一个图片，也可以是一个.xml的文件，其中包含一些描述该照片的元素，或是一个html文件。 并且这些具体的表现可以分布在不同的物理位置上。

1.3．通过逻辑URI定位资源

实现这种级别的可用性的方法之一是定义目录结构式的 URI。
此类 URI 具有层次结构，其根为单个路径，从根开始分支的是公开服务的主要方面的子路径。 根据此定义，URI 并不只是斜杠分隔的字符串，而是具有在节点上连接在一起的下级和上级分支的树。 例如，在一个收集photo的相册中，您可能定义类似如下的结构化 URI 集合：

 

http://www.example.com/photo/topics/{topic}

 

如：http://www.example.com/photo/topics/home

 

根 / photo之下有一个 /topics 节点。 该节点之下有一系列主题名称，例如生日照片，聚会照片等等，每个主题名称指向某个讨论线。 在此结构中，只需在 {topic}输入某个内容即可容易地收集讨论线程。

在某些情况下，指向资源的路径尤其适合于目录式结构。 例如，以按日期进行组织的资源为例，这种资源非常适合于使用层次结构语法。 
此示例非常直观，因为它基于规则：

 

http://www.example.com/photo/2010/02/22/{topic}

 

第一个路径片段是四个数字的年份，第二个路径片断是两个数字的月份，第三个片段是两个数字的日期。这就是我们追求的简单级别。 在语法的空隙中填入路径部分就大功告成了，因为存在用于组合 URI 的明确模式：
http://www.example.com/photo/{year}/{day}/{month}/{topic}

从而不需要我们去这样去传递信息：http://www.example.com/photo?year=xxxx&day=xxx$month=xxx&topic=xxxx

二．Restful web service的优点：

 

2.1 HTTP头中可见的统一接口和资源地址

通过对于HTTP Head 的解析，我们便可以了解到当前所请求的资源和请求的方式。
这样做对于一些代理服务器的设置，将带来很高的处理效率。
REST 系统中所有的动作和要访问的资源都可以从HTTP和URI中得到，这使得代理服务器、缓存服务器和网关很好地协调工作。而RPC模型的SOAP 要访问的资源仅从 URI无法得知，要调用的方法也无法从HTTP中得知，它们都隐藏在 SOAP 消息中。
同样的，在REST系统中的代理服务器还可以通过 HTTP 的动作 (GET 、 POST)来进行控制。

2.2 返回一般的XML格式内容

一般情况下，一个RESTful Web Service将比一个传统SOAP RPC Web Service占用更少的传输带宽。

 

 

Xml代码  

1. POST/Order HTTP/1.1    
2. Host:[url]www.northwindtraders.com[/url]    
3. Content-Type:text/xml    
4. Content-Length:nnnn    
5.      
6. <UpdatePO>    
7.       <orderID>098</orderID>    
8.       <customerNumber>999</customerNumber>    
9.       <item>89</item>    
10.       <quantity>3000</quantity>    
11. </UpdatePO>     

 

 

Xml代码  

1. POST/Order HTTP/1.1    
2. Host:[url]www.northwindtraders.com[/url]    
3. Content-Type:text/xml    
4. Content-Length:nnnn    
5. SOAPAction:"urn:northwindtraders.com:PO#UpdatePO"    
6.      
7. <SOAP-ENV:Envelope    
8. xmlns:xsi="[url]http://www.3w.org/1999/XMLSchema/instance[/url]"    
9. xmlns:SOAP-ENV="[url]http://schemas.xmlsoap.org/soap/envelope[/url]"    
10. xsi:schemaLocation="[url]http://www.northwindtraders.com/schema/NPOSchema.xsd[/url]">    
11. <SOAP-ENV:Body xsi:type="NorthwindBody">    
12.     <UpdatePO>    
13.       <orderID>098</orderID>    
14.       <customerNumber>999</customerNumber>    
15.       <item>89</item>    
16.       <quantity>3000</quantity>    
17.     </UpdatePO>    
18. </SOAP-ENV:Body>    
19. </SOAP-ENV:Envelope>     

 

2.3 安全机制

REST使用了简单有效的安全模型。REST中很容易隐藏某个资源，只需不发布它的URI；而在资源上也很容易使用一些安全策略，比如可以在每个 URI 针对 4个通用接口设置权限；再者，以资源为中心的 Web服务是防火墙友好的，因为 GET的 意思就是GET， PUT 的意思就是PUT，管理员可以通过堵塞非GET请求把资源设置为只读的，而现在的基于RPC 模型的 SOAP 一律工作在 HTTP 的 POST上。而使用 SOAP RPC模型，要访问的对象名称藏在方法的参数中，因此需要创建新的安全模型。

转载：http://pengranxiang.iteye.com/blog/604202