1. REST简述
1. 架构风格, 而非标准
REST（Representational State Transfer，表述性！！！状态传递）是由Roy Thomas Fielding博士在他的论文Architectural Styles and the Design of Network-based Software Architectures中提出的一个术语。
REST本身只是为分布式超媒体系统设计的一种架构风格，而不是标准！！！。
REST的基本元素为资源（resource）、表征（representation）和行为（action）。
资源即对象，一个资源通常意味着一个附带类型和关联数据、支持的操作方法以及与其他对象的关系的对象，它们是持有状态的事物，即REST中的S（State）。
REST组件通过使用“表征”来捕获资源的当前或预期状态并在组件之间传输该表征从而对资源执行操作。表征是一个字节序列，由数据、描述数据的元数据以及偶尔描述元数据的元数据组成（通常用于验证消息的完整性），表征还有一些其他常用但不太精确的名称，如文档、文件和HTTP消息实体等。表征的数据格式称为媒体类型（media type），常用的有JSON或XML。
API客户端不能直接访问资源，它们需要执行“动作”（action）来改变资源的状态，于是资源的状态从一种形式“转移”（Transfer）为另一种形式。
资源可以分组为集合（collection），每个集合只包含单一类型的资源，并且各资源间是无序的。当然，资源也可以不属于任何集合，它们称为单体资源。事实上，集合本身也是资源，它可以部署于全局级别，位于API的顶层，也可以包含于某个资源中，表现为“子集合”。集合、资源、子集合及子资源间的关系如图3-1所示。
图3-1 集合、资源和子资源:
2. 架构和规范
基于Web的架构！！！ 实际上就是各种规范！！！的集合！！！，比如HTTP是一种规范，客户端服务器模式！！！ 是另一种规范。
每当我们在原有规范的基础上增加新的规范时，就会形成新的架构。而REST正是这样一种架构，它结合了一系列规范，形成了一种新的基于Web的架构风格。
3. B/S架构和规范
传统的Web应用大多是B/S架构，涉及如下规范。
3.1. 客户端-服务端规范
（1）客户端-服务器：这种规范的提出，改善了用户接口跨多个平台的可移植性，并且通过简化服务器组件，改善了系统的可伸缩性。最为关键的是通过分离用户接口和数据存储，使得不同的用户终端共享相同的数据成为可能。
3.2. 无状态性
（2）无状态性：无状态性是在客户端-服务器规范的基础上添加的又一层规范，它要求通信必须在本质上是无状态的！！！，即从客户端到服务器的每个request！！！ 都必须包含理解该request必需的所有信息。这个规范改善了系统的可见性（无状态性使得客户端和服务器端不必保存！！！对方的详细信息，服务器只需要处理当前的request，而不必了解所有request的历史）、可靠性（无状态性减少了服务器从局部错误中恢复的任务量）、可伸缩性（无状态性使得服务器端可以很容易释放资源，因为服务器端不必在多个request中保存状态）。同时，这种规范的缺点也是显而易见的，不能将状态数据保存在服务器上，导致增加了在一系列request中发送重复数据的开销，严重降低了效率！！！。
3.3. 客户端缓存
（3）缓存：为了改善无状态性带来的网络的低效性，客户端！！！缓存规范！！！ 出现。缓存规范允许隐式或显式！！！ 地标记一个response中的数据！！！，赋予了客户端缓存response数据的功能，这样就可以为以后的request共用缓存的数据消除部分或全部交互，提高了网络效率。但是客户端缓存了信息，所以客户端数据与服务器数据不一致的可能性增加，从而降低了可靠性！！！。
B/S架构的优点是部署非常方便，在用户体验方面却不很理想。为了改善这种状况，REST规范出现。
4. REST架构和规范
REST规范在原有B/S架构的基础上增加！！！了三个新规范：统一接口、分层系统和按需代码。
4.1. 统一接口
（1）统一接口：REST架构风格的核心特征就是强调组件之间有一个统一的接口，表现为在REST世界里，网络上的所有事物都被抽象为资源！！！，REST通过通用！！！的链接器接口！！！ 对资源进行操作。
这样设计的好处是保证系统提供的服务都是解耦的！！！，可极大简化系统，改善系统的交互性和可重用性。
4.2. 分层系统
（2）分层系统：分层系统规则的加入提高了各种层次之间的独立性，为整个系统的复杂性设置了边界，通过封装遗留的服务，使新的服务器免受遗留客户端的影响，也提高了系统的可伸缩性。
4.3. 按需代码
（3）按需代码：REST允许对客户端的功能进行扩展。比如，通过下载并执行applet或脚本形式的代码来扩展客户端的功能。但这在改善系统可扩展性的同时降低了可见性，所以它只是REST的一个可选约束。
5. REST的设计准则
REST架构是针对Web应用！！！而设计的，其目的是为了降低开发的复杂性，提高系统的可伸缩性。REST提出了如下设计准则。
（1）网络上的所有事物都被抽象为资源（Resource）。
（2）每个资源都对应唯一的资源标识符（Resource Identifier）。
（3）通过通用的连接器接口（Generic Connector Interface）对资源进行操作。
（4）对资源的各种操作都不会改变资源标识符。
（5）所有操作都是无状态的（Stateless）。
5.1. 资源
REST中的资源指的不是数据，而是数据！！！和表现形式！！！ 的组合，比如“最新访问的10位会员”和“最活跃的10位会员”在数据上可能有重叠或者完全相同，而它们由于表现形式不同，被归为不同的资源，这也就是为什么REST的全名是Representational State Transfer。
5.2. 资源标识符
资源标识符就是URI（Uniform Resource Identifier），不管是图片、Word还是视频文件，甚至只是一种虚拟的服务，也不管是XML、TXT还是其他文件格式，全部通过URI对资源进行唯一标识。
5.3. HTTP规范和RESTful的URI
REST是基于HTTP！！！ 的，任何对资源的操作行为都通过HTTP来实现。以往的Web开发大多数用的是HTTP中的GET和POST方法，很少使用其他方法，这实际上是对HTTP的片面理解造成的。
HTTP不仅仅是一个简单的运载数据的协议，还是一个具有丰富内涵的网络软件的协议，它不仅能对互联网资源进行唯一定位，还能告诉我们如何对该资源进行操作。HTTP把对一个资源的操作限制在4种方法（GET、POST、PUT和DELETE）中，这正是对资源CRUD操作的实现。
由于资源和URI是一一对应的，在执行这些操作时URI没有变化，和以往的Web开发有很大的区别，所以极大地简化了Web开发，也使得URI！！！ 可以被设计成能更直观地反映资源的结构！！！。这种URI的设计被称作RESTful的URI，为开发人员引入了一种新的思维方式：通过URL来设计系统结构。
当然，这种设计方式对于一些特定情况也是不适用的，也就是说不是所有URI都适用于RESTful。
5.4. 无状态
REST之所以可以提高系统的可伸缩性，就是因为它要求所有操作都是无状态的。没有了上下文（Context）的约束，做分布式和集群时就更为简单，也可以让系统更为有效地利用缓冲池（Pool），并且由于服务器端不需要记录客户端的一系列访问，也就减少了服务器端的性能损耗。
Kubernetes API也符合RESTful规范，下面对其进行介绍。