REST

REST-产生背景

REST这个词，是Roy Thomas Fielding在他2000年的博士论文中提出的。在Fielding 的论文中，前三章先在批判性继承前人研究成果的基础上，建立起来一整套研究和评价软件架构的方法论。然后在第四章中，研究了 Web 这样一个分布式系统对于软件架构设计提出了哪些需求。在第五章中，Fielding 将第四章 Web 提出的需求具体化为一些架构约束，通过逐步添加各种架构约束，推导出来了 REST 这种新的架构风格。并指出，REST是为运行在互联网环境的分布式超媒体系统量身定制的。

REST-定义

REST（Representational State Transfer），即表现层状态转移。

REST是一种用来设计Web Service的软件架构风格，目的是便于Web Service的客户端（Web Service的使用者）和服务器（Web Service的创建者）传递信息。

架构风格： 一种研究和评价软件架构设计的方法，它是比架构更加抽象的概念。一种架构风格是由一组相互协作的架构约束来定义的。架构约束是指软件的运行环境施加在架构设计之上的约束。

URL定位资源，用HTTP动词描述操作。

REST-深入解读

• 资源（Resource）

  REST的名称"表现层状态转化"中，省略了主语。“表现层"其实指的是"资源”（Resources）的"表现层"。

  资源是一种看待服务器的方式，即，将服务器看作是由很多离散的资源组成。一个资源可以由一个或多个 URI 来标识。URI 既是资源的名称，也是资源在 Web 上的地址。URI不应该有动词，不应包含版本号（不同的版本，可以理解成同一种资源的不同表现形式，所以应该采用同一个URI）。

• 表现层（Representation）

  "资源"具体呈现出来的形式。比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现。

• 状态转化（State Transfer）

  状态转化过程：通过点击超媒体中的链接，客户端和服务器进行交互，从而获取相关资源，并将之呈现在浏览器上。

  状态转化实现：通过HTTP动词，实现客户端和服务器间的交互。

• 统一接口（Uniform Interface）

  REST 要求，必须通过统一的接口来对资源执行各种操作。对于每个资源只能执行一组有限的操作。

• 超文本驱动（Hypertext Driven）

  “超文本驱动”又名“将超媒体作为应用状态的引擎”（Hypermedia As The Engine Of Application State，来自 Fielding 博士论文中的一句话，缩写为 HATEOAS）。

REST-架构约束

• 客户 - 服务器

  通信只能由客户端单方面发起，表现为请求 - 响应的形式。

• 无状态（Stateless）

  通信的会话状态（Session State）应该全部由客户端负责维护。

• 缓存（Cache）

  响应内容可以在通信链的某处被缓存，以改善网络效率。

• 统一接口（Uniform Interface）

  通信链的组件之间通过统一的接口相互通信，以提高交互的可见性。

• 分层系统（Layered System）

  通过限制组件的行为（即，每个组件只能“看到”与其交互的紧邻层），将架构分解为若干等级的层。

• 按需代码（Code-On-Demand，可选）

  支持通过下载并执行一些代码（例如 Java Applet、Flash 或 JavaScript），对客户端的功能进行扩展。

REST-特征

• 面向资源（Resource Oriented）
• 可寻址（Addressability）
• 连通性（Connectedness）
• 无状态（Statelessness）
• 统一接口（Uniform Interface）
• 超文本驱动（Hypertext Driven）

这 6 个特征是 REST 架构设计优秀程度的判断标准。其中，面向资源是 REST 最明显的特征，即，REST 架构设计是以资源抽象为核心展开的。可寻址说的是：每一个资源在 Web 之上都有自己的地址。连通性说的是：应该尽量避免设计孤立的资源，除了设计资源本身，还需要设计资源之间的关联关系，并且通过超链接将资源关联起来。无状态、统一接口是 REST 的两种架构约束，超文本驱动是 REST 的一个关键词。

REST-优缺点

• 优点

  • 简单易理解

    整个REST架构基于熟知概念构建。客户端和服务器间交互使用熟悉的HTTP协议，加密和数据传输完整性也是依赖于众所周知的安全套接字层（SSL）加密和数据层安全性（TLS）

  • 可伸缩性

    充分利用好通信链各个位置的 HTTP 缓存组件，可以带来更好的可伸缩性。其实很多时候，在 Web 前端做性能优化，产生的效果不亚于仅仅在服务器端做性能优化，但是 HTTP 协议层面的缓存常常被一些资深的架构师完全忽略掉。

  • 松耦合

    统一接口 + 超文本驱动，带来了最大限度的松耦合。允许服务器端和客户端程序在很大范围内，相对独立地进化。对于设计面向企业内网的 API 来说，松耦合并不是一个很重要的设计关注点。但是对于设计面向互联网的 API 来说，松耦合变成了一个必选项，不仅在设计时应该关注，而且应该放在最优先位置。

• 缺点

  • 由于使用了HTTP，HTTP的许多限制同样会变成REST架构风格的缺点。

  • REST对uri进行了限制，只用于定义资源，导致设计uri变得复杂了。

REST-和其他分布式架构的对比

从架构风格的抽象高度来看，常见的分布式应用架构风格有三种：

• 分布式对象（Distributed Objects，简称 DO）

  架构实例有 CORBA/RMI/EJB/DCOM/.NET Remoting 等等

• 远程过程调用（Remote Procedure Call，简称 RPC）

  架构实例有 SOAP/XML-RPC/Hessian/Flash AMF/DWR 等等

• 表述性状态转移（Representational State Transfer，简称 REST）

  架构实例有 HTTP/WebDAV

DO 和 RPC 这两种架构风格在企业应用中非常普遍，而 REST 则是 Web 应用的架构风格。

REST 与 DO 的差别在于：

• REST 支持抽象（即建模）的工具是资源，DO 支持抽象的工具是对象。在不同的编程语言中，对象的定义有很大差别，所以 DO 风格的架构通常都是与某种编程语言绑定的。跨语言交互即使能实现，实现起来也会非常复杂。而 REST 中的资源，则完全中立于开发平台和编程语言，可以使用任何编程语言来实现。
• DO 中没有统一接口的概念。不同的 API，接口设计风格可以完全不同。DO 也不支持操作语义对于中间组件的可见性。
• DO 中没有使用超文本，响应的内容中只包含对象本身。REST 使用了超文本，可以实现更大粒度的交互，交互的效率比 DO 更高。
• REST 支持数据流和管道，DO 不支持数据流和管道。
• DO 风格通常会带来客户端与服务器端的紧耦合。在三种架构风格之中，DO 风格的耦合度是最大的，而 REST 的风格耦合度是最小的。REST 松耦合的源泉来自于统一接口 + 超文本驱动。

REST 与 RPC 的差别在于：

• REST 支持抽象的工具是资源，RPC 支持抽象的工具是过程。REST 风格的架构建模是以名词为核心的，RPC 风格的架构建模是以动词为核心的。简单类比一下，REST 是面向对象编程，RPC 则是面向过程编程。
• RPC 中没有统一接口的概念。不同的 API，接口设计风格可以完全不同。RPC 也不支持操作语义对于中间组件的可见性。
• RPC 中没有使用超文本，响应的内容中只包含消息本身。REST 使用了超文本，可以实现更大粒度的交互，交互的效率比 RPC 更高。
• REST 支持数据流和管道，RPC 不支持数据流和管道。
• 因为使用了平台中立的消息，RPC 风格的耦合度比 DO 风格要小一些，但是 RPC 风格也常常会带来客户端与服务器端的紧耦合。支持统一接口 + 超文本驱动的 REST 风格，可以达到最小的耦合度。

RESTful API

RESTful API 也就是RESTful web service，即web服务开发中，基于REST的体系结构风格和通信方法。

REST 就是为设计 web service 而产生的，其应用就是 RESTful API。

常见问题

幂等性(Idempotent)

• 定义：

  多个调用某个请求与调用一次该请求产生的效果相同时，该REST API称为幂等。

• 幂等方法：

  只有POSTAPI不是幂等的。

  通常情况下（不是一定），POST用来在服务器上创建新的资源，当调用N次某个相同的POST请求时，服务器会得到N个不同的新的资源，因此不是幂等的。

• 得到

PUT vs POST

	PUT	POST
功能	如果URI对应资源不存在，则PUT执行创建操作 如果URI对应资源已存在，则PUT将对整个资源执行替换操作	POST将请求中包含的实体添加到URL对应资源
幂等性	幂等	非幂等
资源更新	PUT替换整个资源。如果请求更新部分资源，请使用PATCH。	当您想在资源集合下添加子资源时，请使用POST。
缓存性	因为PUT是幂等的，所以其对应响应可缓存	此方法的响应不可缓存，除非响应包含合适的Cache-Control或Expires头字段。
不过，303(请参阅其他)响应可用于指示用户代理检索可缓存资源。
使用习惯	一般用于UPDATE（更新整个资源）	一般用于CREATE（添加新资源）

---

参考文献

https://www.zhihu.com/question/28557115 通俗理解RESTful API - 知乎

https://restfulapi.net/ RESTful API 教程

http://www.cnblogs.com/artech/p/restful-web-api-01.html 我说理解的RESTful1 - 博客园

https://www.cnblogs.com/artech/p/3506553.html 我说理解的RESTful2 - 博客园

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm REST - Roy Fielding的论文

https://www.infoq.cn/article/understanding-restful-style 理解本真的REST架构风格 - InfoQ

http://www.ruanyifeng.com/blog/2011/09/restful.html 理解RESTful架构 - 阮一峰

https://searchmicroservices.techtarget.com/definition/REST-representational-state-transfer REST优缺点

https://blog.csdn.net/qq_21383435/article/details/80032375 REST优缺点

https://searchmicroservices.techtarget.com/definition/RESTful-API RESTful API - 定义