RESTful学习文档

简介

REST (Respresentational State Transfer) ，表现层状态转换，一种万维网软件架构风格，目的是便于不同软件/程序在网络中相互传递信息。表现层状态转移时根基于超文本传输协议

之上而确定的一组约束和属性,是一种设计提供万维网络服务的<u>软件构建风格</u>。

符合或兼容于这种架构风格(简称为REST或RESTful)的网络服务，允许客户端发出以统一资源标识符访问和操作网络资源请求，而与预先定义好的无状态操作集一致化。因此表现层状态是以本身所定义的操作集，来访问网络上的资源。

REST模式相比于复杂的SOAP和XML-RPC相比更加简洁。

要点及标准

REST是设计风格而不是标准。REST通常基于HTTP、URL、XML以及HTML这些现有的广泛流行的协议和标准。

资源是由URI来指定。
对资源的操作包括获取、创建、修改和删除，这些操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。
通过操作资源的表现形式来操作资源。
资源的表现形式则是XML或者HTML，取决于读者是机器人还是人、是消费Web服务的客户软件还是Web浏览器。当让也可以是任何其他的格式，例如JSON

可重新表达的状态迁移的特征

Uniform Interface:统一接口

以资源为基础

每个资源都可以通过URI访问到。

也就是一个个可以认知的资源，比如文档、音乐、视频等信息，都可以通过唯一的URI确定。
通过重表达的客户端可以管理原资源

就是我们通过客户端可以修改原资源的状态
返回信息足够描述自己

这样重表达的客户端可以指导如何处理
超媒体应用状态的引擎

处理以超媒体为基础的状态变化

Stateless:无状态

Cacheable: 可缓存

Client-Server: 客户服务器分离模式，任何一个客户端与服务端都是可替换的

Layered System: 分层的系统，客户端不知道他联系的是不是客户端

Cache on Demand (可选): 服务器可以将能力扩展客户端，如果客户端可以执行的话。这个功能是可选的。

REST架构的限制条件

客户端-服务器

客户端-服务器结构限制的目的是将客户端和服务器端的关注点分离。将用户界面所关注的逻辑和数据存储所关注的逻辑分离开来有助于提高用户界面的跨平台可移植性。通过简化服务器模块也有助于服务器模块的可扩展性

无状态

服务器不能保存客户端的信息；每一次客户端发送的请求中，要包含所有的必须的状态信息，会话信息由客户端保存，服务器端根具这些状态信息来处理请求
服务器可以将绘画切换到一个新状态的时候发送请求信息
当客户端可以切换到一个新状态的时候发送请求信息
当一个或者多个请求被法发送之后，客户端就处于一个状态变迁过程中。每一个应用的状态描述可以被客户端用来初始化下一次的状态变迁

缓存

如同万维网一样，客户端和中间的通讯传递者可以将回复缓存起来，回复必须明确的或者间接的表明本身是否可以进行缓存，这可以预防客户端在将来进行请求的时候得到陈旧或者不恰当的数据。管理良好的缓存机制可以减少客户端-服务器之间的交互，甚至完全避免客户端

统一接口

这是RESTful系统设计的基本出发点。它简化了系统架构，减少了耦合性，可以让所有模块各自独立的进行改进。包括以下四个限制

请求中包含资源的ID

请求中包含了各种独立资源的标识，例如，在Web服务中的URI。资源本身和发送客户端的标识是独立的。例如，服务器可以将自身的数据库信息以HTML、XML或者JSON的方式发送给客户端，但是这些可能都不是服务器的内部记录方式
资源通过标识来操作

当客户端拥有一个资源的标识，包括附带的元数据，则他就有足够的信息来删除这个资源
消息的自我描述性

每个消息都包含足够的信息来描述如何处理这个信息。例如，媒体类型就可以确定需要什么样的分析器来分析媒体数据
用超媒体驱动应用状态

同用户访问Web服务器的Home页面类似，当一个REST客户端访问了最初的REST应用的URI之后，REST客户端应该可以使用服务器提供的连接，动态的发现所有的可用的资源和可执行的操作。随着访问的进行，服务器在响应中提供文字超链接，以便客户端可以得到当前可用的操作。客户端无需用确定的编码的方式记录下服务器端所提供的动态应用的结构信息

分层系统

客户端一般不知道是否直接连接到了最终的服务器，或者是路径上的中间服务器。中间服务器可以通过负载均衡和共享缓存的机制提高系统可扩展性，这样可以便于安全策略的部署

按需代码（Code-On-Demand,可选）

服务器可以通过发送可执行代码给客户端的方式临时性的扩展功能或者定制功能

关于状态

注意区分应用的状态和连接协议的状态。HTTP连接是无状态的，而REST传输会包含应用的所有状态信息，因此可以大幅降低对HTTP连接重复请求资源的消耗

应用于Web服务

符合REST设计风格的WebAPI 称为RESTfulAPI。它从以下三个方面对资源进行定义：

直观简短的资源地址：URI，比如：http://example.com/resources。
传输的资源：Web服务接受与返回的互联网类型，比如：JSON，XML，YAML等
对资源的操作：Web服务器在该资源上支持的一系列的请求方法（比如POST，GET，PUT或者DELETE）

下表列出了在实现RESTful API时HTTP请求方法的典型用途

资源	GET	PUT	POST	DELETE
一组资源URI，比如http://example.com/resources	列出URI，以及资源族中每个资源的详细信息	使用给定的一组资源替换当前整租资源	在本组资源中创建/追加一个新的资源。该操作往往返回新资源的URL。	删除整组资源
单个资源的URI，比如http://example.com/resources/123	获取制定的资源的详细信息，格式可以自选一个合适的网络媒体	替换/创建指定的资源。并将其追加到相应的资源组中	把指定的资源当作一个资源组，并在其下创建/追加一个新的元素，使其隶属于当前资源	删除指定的元素

PUT和DELETE方法是幂等方法。GET 方法是安全方法（不会对服务器有修改，当然也是幂等）

不像基于SOAP的Web服务，RESTful Web服务并没有正式的标准。因为REST是一种架构，SOAP只是一个协议。虽然REST不是一个标准，但是大部分RESTful Web服务实现会使用HTTP，URI，JSON和XML等各种标准

实现举例

例如，一个简单的网络商店应用：

列举所有商品：

GET http://www.store.com/products
呈现某一件商品：

GET http://www.store.com/products/12345

下单购买：

POST http://www.store.com/orders
<purchase-order>
 <item> ... </item>
</purchase-order>

REST的优点

可更高效利用缓存来提高响应速度
通讯本身的无状态性可以让不同的服务器的处理一系列请求中的不同请求，提高服务器的扩展性
浏览器即可作为客户端，简化软件需求
相对于其他叠加在HTTP协议之上的机制，REST的软件依赖性更小
不需要额外的资源发现机制
在软件技术演进中的长期的兼容性更好

RESTful文档