- REST其实是一种组织Web服务的架构，而并不是我们想象的那样是实现Web服务的一种新的技术，更没有要求一定要使用HTTP。其目标是为了创建具有良好扩展性的分布式系统。
- 作为一种架构，其提出了一系列架构级约束。这些约束有：
- 使用客户/服务器模型。客户和服务器之间通过一个统一的接口来互相通讯。
- 层次化的系统。在一个REST系统中，客户端并不会固定地与一个服务器打交道。
- 无状态。在一个REST系统中，服务端并不会保存有关客户的任何状态。也就是说，客户端自身负责用户状态的维持，并在每次发送请求时都需要提供足够的信息。
- 可缓存。REST系统需要能够恰当地缓存请求，以尽量减少服务端和客户端之间的信息传输，以提高性能。
- 统一的接口。一个REST系统需要使用一个统一的接口来完成子系统之间以及服务与用户之间的交互。这使得REST系统中的各个子系统可以独自完成演化。
如果一个系统满足了上面所列出的五条约束，那么该系统就被称为是RESTful的。
- 无状态约束在其它类型的Web服务中并不十分常见，因此如何避免违反该约束是在实现REST服务时最常讨论的话题。其不仅仅会影响到很多功能的设计，更是REST系统扩展性的关键。
- 资源是REST系统的核心概念。所有的设计都会以资源为中心，包括如何对资源进行添加，更新，查找以及修改等。而资源本身则拥有一系列状态。在每次对资源进行添加 ，删除或修改的时候，资源就将从一个状态转移到另外一个状态。
- 统一接口这个约束包含了四个子约束：
- 每个资源都拥有一个资源标识。每个资源的资源标识可以用来唯一地标明该资源。
- 消息的自描述性。在REST系统中所传递的消息需要能够提供自身如何被处理的足够信息。例如该消息所使用的MIME类型，是否可以被缓存等。（消息格式）
- 资源的自描述性。一个REST系统所返回的资源需要能够描述自身，并提供足够的用于操作该资源的信息，如如何对资源进行添加，删除以及修改等操作。也就是说，一个典型的REST服务不需要额外的文档对如何操作资源进行说明。属性都清晰地描述了自身所表达的含义。（属性都清晰地描述了自身所表达的含义，例如：通过brands属性表示了该分类中的著名品牌，并通过hot_searches标示了在该分类中的热搜关键字）
- HATEOAS。即客户只可以通过服务端所返回各结果中所包含的信息来得到下一步操作所需要的信息，如到底是向哪个URL发送请求等。也就是说，一个典型的REST服务不需要额外的文档标示通过哪些URL访问特定类型的资源，而是通过服务端返回的响应来标示到底能在该资源上执行什么样的操作。一个REST服务的客户端也不需要知道任何有关哪里有什么样的资源这种信息。
- 发送GET /api ，返回的响应中将标示出REST API的版本以及所有可以访问的资源等信息。
- 资源的状态转移：在一个REST系统中，购物车将被抽象为一个资源，而“将商品放入购物车”这个操作将被解释为对购物车这个资源的更新：更新购物车，以使特定商品包含在购物车内。
- 我们对某个操作不要再关注它所执行的动作，而是关心它所操作的宾语。通常情况下，该宾语就会是REST系统中的资源。
- 但是有时候，一个动作可能并不存在着它所操作的宾语。在这种情况下，我们就需要考虑该动作产生或消除了哪个实体，或者哪个实体的状态发生了变化。这个发生了变化的实体实际上就是一种资源。例如对于登陆这一行为，其实际上在服务端创建了一个会话实例。该会话实例中则包含了登陆IP，登陆时间，以及登陆时所用的凭证等。再比如对于用户更改密码这种行为，其所操作的资源就是用户资料。
- 那么如何判断我们为REST服务所定义的资源是否合理呢？一般情况下，我都使用下面的一些判断方法：
首先，我们需要考虑对该资源的CRUD是否有意义，从而验证资源的定义是否合理。就以刚刚说到的列表的分页显示为例，我们可以想象一下如何对分页进行添加和删除？一旦删除了该分页，那么属于该分页中的各个商品也应该被删除么？而且删除了分页X的数据后，原本X + 1分页的数据将展示在X分页中。很显然，将商品的分页定义为资源并不合理。
其次，我们需要检查资源是否需要除CRUD之外的动词来操作。该方法用来检查资源中是否还有子资源没有被抽象。如果该资源还需要额外的动词，那么我们就需要考虑这些操作到底引起了什么样的状态变化，进而抽象出该资源的子资源。
除此之外，我们还需要检查这些资源是否是被整体使用，创建和删除。该方法用来探测是否一个子资源应该是一个主资源。如果在删除一个资源的时候，其子资源还可以被其它资源重用，那么该子资源实际上具有较高的重用性，应该是一个主资源。
- 单数 VS. 复数 ：如果一个URL所对应的资源是使用复数表示的，那么该类型的资源可能有多个。对该URL发送Get请求可能返回该资源的一个列表。反之，如果一个URL所对应的资源是使用单数表示的，那么该类型的资源将只有一个，因此对该URL发送Get请求将只返回该资源的一个实例。
- 在判断到底是使用请求参数还是相对路径时，我们一般分为下面几步。
首先，可选参数一般都应置于请求参数中。仍以egoods中的手机为例。在选择手机时，用户可以选择品牌以及颜色。如果将品牌和颜色都定义在相对URL中，那么具有特定品牌和颜色的手机将可以通过两个不同的URL访问：/api/mobiles/brand/{brand}/color/{color}以及/api/mobiles/color/{color}/brand/{brand}。就用户而言，其并无法了解这两个URL所表示的是同一类资源还是不同类型的资源。当然，您可以说，我们只用/api/mobiles/brand/{brand}/color/{color}。但是该URL将无法处理用户仅仅选择了颜色，却没有选择品牌的情况。
其次，不是所有字符都可以在URL中被使用，如汉字，标点。为了处理这种情况，包含这些字符的筛选条件需要置于请求参数中。
最后，如果该特征下包含子资源，那么它自身也就是一个资源，因此需要以相对路径的方式展现它。例如在egoods网站中，每件商品所属于的分类仅仅是它的一个特征。但是一个分类更包含了属于它的各个品牌以及热搜关键字等众多信息。因此它其实是一个资源，需要在URI路径中表示它。
总的来说，既然使用HTTP来构建REST系统，那么我们就需要遵守URL各组成中的含义：URL中的相对路径将用来标示“What I want”，也既对应着资源；而请求参数则用来标示“How I want”，即查看资源的方式。
- POST动词会在目标URI之下创建一个新的子资源。PUT则是根据请求创建或修改特定位置的资源。此时向服务端发送的请求的目标URI需要包含所处理资源的ID：
- 独立认证：每次发用户名和密码。代理认证：发送至代理，然后代理抹去状态信息。