对REST架构风格的理解

2019独角兽企业重金招聘Python工程师标准>>>

Web是一个分布式信息系统，为超文本文件和其他对象（资源）提供访问接口和访问机制。REST是Web自身的架构风格，REST是HTTP/1.1协议等Web规范的设计指导原则，HTTP/1.1协议正是为实现REST风格的架构而设计的。

以搭建系统的角色来思考这个问题：在web中，为了获取我们所需要的分布在不同地域的超媒体资源，我们该如何设计这个系统？显然，我们需要的是一个大型分布式超媒体系统的应用层解决方案。首先我们需要为数据设定唯一的标识，因此我们将数据抽象为资源，并为每个资源设定ID(URI)，以此为资源接口来操作每个资源。具体如何来操作资源呢？我们又为所有的资源引入一套统一的操作方法（HTTP动词）。这样，当我们用这种方式来定义我们自己的资源时，web中的其它人就能方便的获取这些资源。获取资源时，我们可能需要的是资源的不同呈现方式，因此需要对资源进行表述，使其表现为我们需要的形式，于是又引入了HTTP Header来传递元数据（基于表现层实现资源的状态转移）。

软件架构是对软件系统的抽象，软件架构风格又是对软件架构的抽象。一个软件架构由不同元素构成，元素之间有各种各样的约束，而软件架构风格就是指一组协作的架构约束。当我们谈到某个系统是某种架构风格时，就代表了这个系统的架构背后有一系列架构约束。架构风格就是将一组架构约束组合起来，再给它一个名字，因此可以这样理解向一种架构风格中添加或减少一个约束，就形成了一种新的架构风格。我们学习架构风格，其实就是要了解各种架构约束，了解他们会带来什么，他们组合起来又意味着什么。

REST 本身是设计风格而不是标准，RESTful风格的架构级约束条件有5个：
1.客户/服务模型，通信只能由客户端单方面发起，表现为请求-响应的形式。客户端关注用户接口，服务端关注业务逻辑的处理，数据的生成。
2.无状态：并不是说客户端应用不能有状态，而是指服务端不应该保存客户端状态。通信必须在本质上是无状态的，从客户到服务器的每个请求都必须包含理解该请求所必需的所有信息，不能利用任何存储在服务器端的上下文，会话状态因此要全部保存在客户端。
    应用状态与资源状态：客户端负责维护应用状态，而服务端维护资源状态。服务端不需要在请求间保留应用状态，只有在接受到实际请求的时候，服务端才会关注应用状态。这种无状态通信原则，使得服务端和中介能够理解独立的请求和响应。 在多次请求中，同一客户端也不再需要依赖于同一服务器，方便实现高可扩展和高可用性的服务端。
3.缓存：要求一个请求的响应中的数据被隐式地或显式地标记为可缓存的或不可缓存的，以此来控制客户端缓存
4.统一接口：包括4个接口架构约束
    资源的识别：每个资源都拥有一个资源标识。每个资源的资源标识可以用来唯一地标明该资源。--URI
    通过表述来操作资源：这里说的是资源的自描述性。一个REST系统所返回的资源需要能够描述自身，并提供足够的用于操作该资源的信息，比如如何对资源进行添加，删除以及修改等操作。也就是说，一个典型的REST服务不需要额外的文档对如何操作资源进行说明。--Header
    自描述的信息：在REST系统中所传递的消息需要能够提供自身如何被处理的足够信息。例如该消息所使用的MIME类型，是否可以被缓存等。--Header
    超媒体作为应用状态引擎：即客户只可以通过服务端所返回各结果中所包含的信息来得到下一步操作所需要的信息，如到底是向哪个URL发送请求等。换句话说：是链接的思想。也就是说，一个典型的REST服务不需要额外的文档标示通过哪些URL访问特定类型的资源，而是通过服务端返回的响应来标示到底能在该资源上执行什么样的操作。一个REST服务的客户端也不需要知道任何有关哪里有什么样的资源这种信息。
5.分层：只关注应用层
6.按需代码：客户端知道如何访问资源，但是不知道如何处理资源，此时客户端可以向远程服务器请求处理资源的代码，在本地执行。典型的例子就是 JavaScript，浏览器从服务器上下载 JS 代码，在浏览器中执行。

从实现的结果来看，REST 谈论一件非常重要的事，如何正确地使用 Web标准，例如，HTTP 和 URI。
1、用URL定位资源，用HTTP（GET,POST,DELETE,DETC）描述操作。
2、看URL就知道要什么，看http method就知道干什么，看http status code就知道结果如何

转载于:https://my.oschina.net/codespring/blog/1785830