昨天学习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是站在资源的角度去考虑问题，提供什么样的资源，以及可以对资源进行那些操作。有点类似于面向过程编程和面向对象编程的思路转换。

对REST的一些理解