REST简介

REST的定义

REST其实是一种组织Web服务的架构，而并不是我们想象的那样是实现Web服务的一种新的技术，更没有要求一定要使用HTTP。其目标是为了创建具有良好扩展性的分布式系统。

反过来，作为一种架构，其提出了一系列架构级约束。这些约束有：

1. 使用客户/服务器模型。客户和服务器之间通过一个统一的接口来互相通讯。

2. 层次化的系统。在一个REST系统中，客户端并不会固定地与一个服务器打交道。

3. 无状态。在一个REST系统中，服务端并不会保存有关客户的任何状态。也就是说，客户端自身负责用户状态的维持，并在每次发送请求时都需要提供足够的信息。

4. 可缓存。REST系统需要能够恰当地缓存请求，以尽量减少服务端和客户端之间的信息传输，以提高性能。

5. 统一的接口。一个REST系统需要使用一个统一的接口来完成子系统之间以及服务与用户之间的交互。这使得REST系统中的各个子系统可以独自完成演化。

资源和状态

资源是REST系统的核心概念。所有的设计都会以资源为中心，包括如何对资源进行添加，更新，查找以及修改等。而资源本身则拥有一系列状态。在每次对资源进行添加 ，删除或修改的时候，资源就将从一个状态转移到另外一个状态。

统一接口约束

1. 每个资源都拥有一个资源标识。每个资源的资源标识可以用来唯一地标明该资源。

2. 消息的自描述性。在REST系统中所传递的消息需要能够提供自身如何被处理的足够信息。例如该消息所使用的MIME类型，是否可以被缓存等。

3. 资源的自描述性。一个REST系统所返回的资源需要能够描述自身，并提供足够的用于操作该资源的信息，如如何对资源进行添加，删除以及修改等操作。也就是说，一个典型的REST服务不需要额外的文档对如何操作资源进行说明。

4. HATEOAS。即客户只可以通过服务端所返回各结果中所包含的信息来得到下一步操作所需要的信息，如到底是向哪个URL发送请求等。也就是说，一个典型的REST服务不需要额外的文档标示通过哪些URL访问特定类型的资源，而是通过服务端返回的响应来标示到底能在该资源上执行什么样的操作。一个REST服务的客户端也不需要知道任何有关哪里有什么样的资源这种信息。

对于网络应用来说，资源标识就是URI。而在一个基于HTTP的系统中，最自然的资源标示便是URL。在表示单个资源的时候，这个URL常常会包含着资源在该类资源中的ID。

资源识别

在通常的软件开发过程中，我们常常需要分析达成某个目标所需要使用的业务逻辑，并为业务逻辑的执行提供一系列运行接口。在一些Web服务中，这些接口常常表达了某个动作，如将商品放入购物车，提交订单等。这一系列动作组合在一起就可以组成完成目标所需要执行的业务逻辑。在需要调用这些接口的时候，软件开发人员需要向这些接口所在的URL发送一个请求，从而驱使服务执行该动作。

而在REST服务中，我们所提供的各个接口则需要是一系列资源，而业务逻辑需要通过对资源的操作来完成。也就是说，REST服务中的API将不再以执行了什么动作为中心，而是以资源为中心。一些对资源的通用操作有添加，取得，修改，删除，以及对符合特定条件的资源进行列表操作。

这种描述方法的确有别于很多Web服务那样以动作为中心。而与之对应的则是系统设计步骤的改变：我们将不再首先是别完成业务逻辑所需的各动作，而是支持业务逻辑所需要的各资源。那么我们应该如何抽象出这些资源呢？首先，我们对某个操作不要再关注它所执行的动作，而是关心它所操作的宾语。通常情况下，该宾语就会是REST系统中的资源。

在抽象资源的过程中，我们需要按照自顶向下的方式，即首先辨识出系统中的最主要资源，然后再辨识这些主要资源的子资源，并依次进行迭代。

对主资源的抽取主要通过分析业务逻辑来完成。在得到功能需求以后，我们首先要分析这些业务逻辑所操作的宾语。这些宾语可能有两种情况：主资源或者其它资源的子资源。主资源实际上就是能够独立存在的一系列资源。而子资源则需要依附于主资源之上才能表达实际的意义。同时各个子资源也可能拥有自身的子资源。

判断一个资源是否是子资源的一个方法就是看它是否能独立地表示其具体含义。例如对于一个egoods上所销售的商品，其名称，价格，简介等属性可以清晰地描述该商品到底是什么，到底如何销售。因此这些商品实际上是一个主资源。但是每种商品所支持的邮递服务需要是一个子资源：一个商品可以支持多种邮递服务。这些邮递服务根据派送距离等需要不同的价格，也提供了不同的邮递速度。由于这些邮递服务与商家和邮递服务公司所达成的服务价格有关，并且会由于商品重量的变化而变化，因此这些邮递服务并不能为其它商家所提供的邮递服务作为参考，因此其应该作为该商品的一个子资源。

那么如何判断我们为REST服务所定义的资源是否合理呢？

一般情况下，我都使用下面的一些判断方法：

首先，我们需要考虑对该资源的CRUD是否有意义，从而验证资源的定义是否合理。就以刚刚说到的列表的分页显示为例，我们可以想象一下如何对分页进行添加和删除？一旦删除了该分页，那么属于该分页中的各个商品也应该被删除么？而且删除了分页X的数据后，原本X + 1分页的数据将展示在X分页中。很显然，将商品的分页定义为资源并不合理。

其次，我们需要检查资源是否需要除CRUD之外的动词来操作。该方法用来检查资源中是否还有子资源没有被抽象。如果该资源还需要额外的动词，那么我们就需要考虑这些操作到底引起了什么样的状态变化，进而抽象出该资源的子资源。

除此之外，我们还需要检查这些资源是否是被整体使用，创建和删除。该方法用来探测是否一个子资源应该是一个主资源。如果在删除一个资源的时候，其子资源还可以被其它资源重用，那么该子资源实际上具有较高的重用性，应该是一个主资源。

资源的URL设计

在前面已经提到过，统一接口约束中的第一条子约束就是每个资源都拥有一个资源标识。在正确地辨识出了一个资源之后，我们就需要为这些资源分配其所对应的URI。一个资源所对应的URI可能有多种表示方式，如到底是用单数还是复数表示资源等。因此在一个基于HTTP的REST系统中，如何组织针对各个资源的URL实际上是最重要的一部分。毕竟一个明确的，有意义并且稳定的API接口实际上是对服务对用户的一种承诺。

在HTTP中，一个URL主要由以下几个部分组成：

协议。即HTTP以及HTTPS。
主机名和端口。如www.egoods.com:8421
资源的相对路径。如/api/categories。
请求参数。即由问号开始的由键值对组成的字符串：?page=1&page_size=20