REST 表征状态转移

"REST"（Re presentational S tate Transfer）表征状态转移

实际上是"HTT"（H ypert ext Transfer）的进一步抽象

资源（Resource）：譬如你现在正在阅读一篇名为《REST 设计风格》的文章，这篇文章的内容本身（你可以将其理解为其蕴含的信息、数据）我们称之为"资源"。无论你是购买的书籍、是在浏览器看的网页、是打印出来看的文稿、是在电脑屏幕上阅读抑或是手机上浏览，尽管呈现的样子各不相同，但其中的信息是不变的，你所阅读的仍是同一份"资源"。
表征（Representation）：当你通过电脑浏览器阅读此文章时，浏览器向服务端发出请求"我需要这个资源的 HTML 格式"，服务端向浏览器返回的这个 HTML 就被称之为"表征"，你可能通过其他方式拿到本文的 PDF、Markdown、RSS 等其他形式的版本，它们也同样是一个资源的多种表征。可见"表征"这个概念是指信息与用户交互时的表示形式，这与我们软件分层架构中常说的"表示层"（Presentation Layer）的语义其实是一致的。
状态（State）：当你读完了这篇文章，想看后面是什么内容时，你向服务器发出请求"给我下一篇文章"。但是"下一篇"是个相对概念，必须依赖"当前你正在阅读的文章是哪一篇"才能正确回应，这类在特定语境中才能产生的上下文信息即被称为"状态"。我们所说的有状态（Stateful）抑或是无状态（Stateless），都是只相对于服务端来说的，服务器要完成"取下一篇"的请求，要么自己记住用户的状态：这个用户现在阅读的是哪一篇文章，这称为有状态；要么客户端来记住状态，在请求的时候明确告诉服务器：我正在阅读某某文章，现在要读它的下一篇，这称为无状态。
转移（Transfer）：无论状态是由服务端还是客户端来提供的，"取下一篇文章"这个行为逻辑必然只能由服务端来提供，因为只有服务端拥有该资源及其表征形式。服务器通过某种方式，把"用户当前阅读的文章"转变成"下一篇文章"，这就被称为"表征状态转移"。

六大原则：

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

服务端与客户端分离（Client-Server）
无状态（Stateless）
可缓存（Cacheability）
分层系统（Layered System）
统一接口（Uniform Interface）
按需代码 （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）可通过自定义协议提升性能。