REST 表征状态转移

《Architectural Styles and the Design of Network-based Software Architectures》

https://www.infoq.cn/minibook/web-based-apps-archit-design

https://icyfenix.cn/architect-perspective/general-architecture/api-style/rest.html

“REST”（Representational State Transfer）表征状态转移

       实际上是“HTT”（Hypertext Transfer）的进一步抽象

• 资源（Resource）：譬如你现在正在阅读一篇名为《REST 设计风格》的文章，这篇文章的内容本身（你可以将其理解为其蕴含的信息、数据）我们称之为“资源”。无论你是购买的书籍、是在浏览器看的网页、是打印出来看的文稿、是在电脑屏幕上阅读抑或是手机上浏览，尽管呈现的样子各不相同，但其中的信息是不变的，你所阅读的仍是同一份“资源”。

• 表征（Representation）：当你通过电脑浏览器阅读此文章时，浏览器向服务端发出请求“我需要这个资源的 HTML 格式”，服务端向浏览器返回的这个 HTML 就被称之为“表征”，你可能通过其他方式拿到本文的 PDF、Markdown、RSS 等其他形式的版本，它们也同样是一个资源的多种表征。可见“表征”这个概念是指信息与用户交互时的表示形式，这与我们软件分层架构中常说的“表示层”（Presentation Layer）的语义其实是一致的。

• 状态（State）：当你读完了这篇文章，想看后面是什么内容时，你向服务器发出请求“给我下一篇文章”。但是“下一篇”是个相对概念，必须依赖“当前你正在阅读的文章是哪一篇”才能正确回应，这类在特定语境中才能产生的上下文信息即被称为“状态”。我们所说的有状态（Stateful）抑或是无状态（Stateless），都是只相对于服务端来说的，服务器要完成“取下一篇”的请求，要么自己记住用户的状态：这个用户现在阅读的是哪一篇文章，这称为有状态；要么客户端来记住状态，在请求的时候明确告诉服务器：我正在阅读某某文章，现在要读它的下一篇，这称为无状态。

• 转移（Transfer）：无论状态是由服务端还是客户端来提供的，“取下一篇文章”这个行为逻辑必然只能由服务端来提供，因为只有服务端拥有该资源及其表征形式。服务器通过某种方式，把“用户当前阅读的文章”转变成“下一篇文章”，这就被称为“表征状态转移”。

六大原则：

一套理想的、完全满足 REST 风格的系统应该满足以下六大原则：

1. 服务端与客户端分离（Client-Server）

2. 无状态（Stateless）

3. 可缓存（Cacheability）

4. 分层系统（Layered System）

5. 统一接口（Uniform Interface）

6. 按需代码（Code-On-Demand）

基本思想：

REST 的基本思想是面向资源来抽象问题，它与此前流行的编程思想——面向过程的编程在抽象主体上有本质的差别。在 REST 提出以前，人们设计分布式系统服务的唯一方案就只有 RPC，RPC 是将本地的方法调用思路迁移到远程方法调用上，开发者是围绕着“远程方法”去设计两个系统间交互的，譬如 CORBA、RMI、DCOM，等等。这样做的坏处不仅是“如何在异构系统间表示一个方法”、“如何获得接口能够提供的方法清单”都成了需要专门协议去解决的问题（RPC 的三大基本问题之一），更在于服务的每个方法都是完全独立的，服务使用者必须逐个学习才能正确地使用它们。

面向资源：

面向资源编程思想（Resource-Oriented Programming）是以资源为核心设计软件架构的思维方式，其核心是将数据（资源）作为编程的基本单位，通过标准化的接口实现数据操作。 ‌12

核心原则

• ‌资源抽象‌：将数据或信息抽象为可操作的“资源”，例如用户信息、订单数据等，所有操作围绕这些资源展开。 
• ‌统一接口规范‌：通常采用HTTP协议的标准方法（如GET/POST/PUT/DELETE）映射到资源的增删改查（CRUD）操作，确保接口一致性。 ‌
• ‌无状态设计‌：通过URI定位资源，操作不依赖客户端状态，服务端通过请求参数判断上下文。 ‌

与传统编程思想的差异

• ‌面向对象/过程‌：传统编程以功能或过程为中心设计逻辑，代码耦合度高；资源编程以数据为中心，降低系统复杂性。 ‌
• ‌传输协议依赖‌：REST架构强依赖HTTP协议，而传统架构（如RPC）可通过自定义协议提升性能。