对REST的一些理解

    昨天学习REST，发现有篇文章写的真心不错，看了一遍，并没有完全理解，将一些感觉比较重要的做个记录。  文章链接：REST简介

定义

    Representational State Transfer (REST) is a software architecture style consisting of guidelines and best practices for creating scalable web services. REST is a coordinated set of constraints applied to the design of components in a distributed hypermedia system that can lead to a more performant and maintainable architecture.

    简单解释一下（个人理解，不一定准确）：
    1、REST：Representational State Transfer，表现状态传送。
    2、REST是一种软件架构风格，是构建可扩展的web services的最佳实践和指导方针。
    3、REST是软件构建的一组约束，目标是为了创建具有良好扩展性的分布式系统。

约束

    REST提出一系列架构级约束，摘录如下：
    1、使用客户/服务器模型。客户和服务器之间通过一个统一的接口来互相通讯。
    2、层次化的系统。在一个REST系统中，客户端并不会固定地与一个服务器打交道。
    3、无状态。在一个REST系统中，服务端并不会保存有关客户的任何状态。也就是说，客户端自身负责用户状态的维持，并在每次发送请求时都需要提供足够的信息。
    4、可缓存。REST系统需要能够恰当地缓存请求，以尽量减少服务端和客户端之间的信息传输，以提高性能。
    5、统一的接口。一个REST系统需要使用一个统一的接口来完成子系统之间以及服务与用户之间的交互。这使得REST系统中的各个子系统可以独自完成演化。
    （1）每个资源都拥有一个资源标识。每个资源的资源标识可以用来唯一地标明该资源。
    （2）消息的自描述性。在REST系统中所传递的消息需要能够提供自身如何被处理的足够信息。例如该消息所使用的MIME类型，是否可以被缓存等。
    （3）资源的自描述性。一个REST系统所返回的资源需要能够描述自身，并提供足够的用于操作该资源的信息，如如何对资源进行添加，删除以及修改等操作。也就是说，一个典型的REST服务不需要额外的文档对如何操作资源进行说明。
    （4）HATEOAS。即客户只可以通过服务端所返回各结果中所包含的信息来得到下一步操作所需要的信息，如到底是向哪个URL发送请求等。也就是说，一个典型的REST服务不需要额外的文档标示通过哪些URL访问特定类型的资源，而是通过服务端返回的响应来标示到底能在该资源上执行什么样的操作。一个REST服务的客户端也不需要知道任何有关哪里有什么样的资源这种信息。

个人理解

    1、为什么需要REST？为了支撑高并发的访问，单机应用肯定不行，需要分布式系统，如何构建具有良好扩展性的分布式系统呢？就需要REST。
    2、是什么？不是新技术，技术都是老的，但使用技术的方法有很多种。REST就是告诉你，按我说的法来做，可以构建一个更具扩展性的分布式系统。
    3、无状态。以前的软件构建时，用户状态（如登录信息）都存在服务器上，也就是session中，单机应用时没问题，但要集群时，session同步就是个大问题。现在统一约定，服务器不存状态，那相关状态信息怎么办？客户端每次访问时传过来，也就是说，客户端自身负责用户状态的维持，并在每次发送请求时都需要提供足够的信息。或许，这就是REST的字面义，表现状态传送。
    4、设计思路转变。传统软件构建时，是考虑一个请求时，服务器内部进行什么样的逻辑处理。REST是站在资源的角度去考虑问题，提供什么样的资源，以及可以对资源进行那些操作。有点类似于面向过程编程和面向对象编程的思路转换。

 

部分摘录

    前四条约束中除了无状态这条约束较为特别之外，其它三条约束在基于HTTP的Web服务中都很常见，也较容易达成。而无状态约束在其它类型的Web服务中并不十分常见，因此如何避免违反该约束是在实现REST服务时最常讨论的话题。其不仅仅会影响到很多功能的设计，更是REST系统扩展性的关键。

    前面的四个约束实际上都较为容易达成。唯一需要注意的无非是是否某些技术实现违反了这些约束。而第五条约束，统一接口，可以说是REST服务设计的核心所在，也是决定REST服务设计的成败之处。

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

    我们可以通过使用大部分HTTP标准所提供的功能来提高消息的自描述性......在一个基于HTTP的REST系统中，如何准确地使用HTTP协议是一项非常重要的内容。

    URL和ID：URL用来指向资源所在的地址，而ID则表示该资源在该类型资源中的ID。

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

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