为什么会出现 REST API？

REST（Representational State Transfer）API 的出现是为了解决分布式系统中资源访问和数据交互的复杂性问题。它的核心思想是通过标准化的、基于 HTTP 协议的轻量级方式，实现系统间的通信。以下是 REST API 出现的主要原因：

1. Web 技术发展需求：随着互联网的普及，Web 应用需要更高效、灵活的方式在客户端和服务器之间交换数据。传统的 SOAP 和 XML-RPC 等协议较为复杂，REST 提供了更简单、基于 HTTP 的解决方案。
2. 资源导向设计：REST 强调以资源为中心，使用 URL 表示资源，通过 HTTP 方法（如 GET、POST、PUT、DELETE）操作资源，符合 Web 的原生设计理念。
3. 跨平台和异构系统集成：REST API 使用标准 HTTP 协议和 JSON/XML 等通用格式，便于不同平台（Web、移动端、IoT 设备等）和语言的系统集成。
4. 性能和可扩展性：REST 的无状态性和缓存机制提高了系统性能和可扩展性，适合构建大规模分布式应用。

最早出现时间

REST 概念由 Roy Fielding 在 2000 年提出，具体出现在他的博士论文《Architectural Styles and the Design of Network-based Software Architectures》中。他在论文中定义了 REST 作为一种架构风格，用于指导基于网络的应用程序设计。REST API 的实际应用逐渐在 2000 年代初兴起，尤其是在 Web 2.0 时代（约 2004-2006 年），随着 Flickr、Twitter 和 Amazon Web Services 等平台的 API 采用 REST 风格，REST API 成为主流。

用在什么场景下？

REST API 广泛应用于各种需要系统间通信的场景，尤其是在以下领域：

1. Web 和移动应用：
   • 用于前后端分离架构，前端通过 REST API 从后端获取数据（如用户资料、文章列表）。
   • 移动应用通过 REST API 与服务器交互（如社交媒体 App 的动态加载）。
2. 微服务架构：
   • 微服务之间通过 REST API 通信，实现松耦合的模块化设计。
3. 第三方服务集成：
   • 开放平台（如支付网关、地图服务、社交媒体登录）通过 REST API 提供功能给开发者。
   • 例如：Stripe 的支付 API、Google Maps API。
4. 物联网（IoT）：
   • 智能设备通过 REST API 与云端通信，发送传感器数据或接收控制指令。
5. 企业级应用：
   • 用于企业内部系统集成，如 CRM、ERP 与其他业务系统的数据交互。
6. 内容管理系统（CMS）：
   • headless CMS 通过 REST API 提供内容，供不同前端（如网站、App）消费。
7. 自动化和 DevOps：
   • CI/CD 工具、云服务（如 AWS、Azure）通过 REST API 实现自动化操作。

 

为什么名字叫Representational State Transfer？

REST（Representational State Transfer）的名称源于其设计哲学的核心机制——通过资源表述（Representation）来传输（Transfer）状态（State）。这个命名由 Roy Fielding 在其 2000 年的博士论文中提出，是对其工作原理的高度抽象概括。

名称拆解与含义

词	含义	在 REST 中代表的概念
Representational（表述）	指“资源的表现形式”，如 JSON、XML、HTML 等	客户端通过某种格式接收资源的表现
State（状态）	指“资源在某一时刻的状态”	每次请求都可能代表资源的不同状态
Transfer（传输）	指“在客户端和服务器之间传输数据”	REST 的核心就是通过 HTTP 协议传输资源状态的表现形式

 

为什么叫 "Representational State Transfer"？

REST 之所以叫 “Representational State Transfer”，是因为它的设计核心在于：客户端与服务器通过资源的“表现形式”来传输资源的“状态”，实现无状态、统一接口、松耦合的网络通信。

 

命名背后的设计哲学

Fielding 的命名直指 REST 与传统 RPC（远程过程调用）的本质区别：

RPC 模式	REST 模式
关注“动作”（如 getUser()）	关注“资源”（如 /users/123）
传输过程参数	传输资源表述
服务端维护会话状态	无状态，依赖请求上下文

这种设计使 REST 天生适配 Web 的分布式、可扩展特性，成为现代 API 的基石。

 

1. 资源（Resource）

REST 将一切数据或服务抽象为 资源（如用户、订单），每个资源用 URI（统一资源标识符） 唯一标识（如 /users/123）。

2. 表述（Representation）

资源本身是抽象的，客户端与服务器交互的是资源的 表述（Representation），即资源在特定时刻的状态的具体表现形式。

• 示例：同一用户资源可以有不同表述

  • JSON 格式：{"id": 123, "name": "Alice"}

  • XML 格式：<user><id>123</id><name>Alice</name></user>

  • HTML 格式：<div>User: Alice</div>

3. 状态（State）

• 资源状态：资源在服务器端的实际数据（如用户年龄、订单状态）。

• 应用状态：客户端当前的操作进度（如用户浏览到订单列表的第 2 页）。
  关键点：REST 要求服务端 不保存客户端应用状态（无状态），客户端需在请求中携带必要信息（如分页参数 ?page=2）。

4. 传输（Transfer）

客户端通过 HTTP 方法（GET/POST/PUT/DELETE）操作资源的表述，实现 “状态”的传输：

• 客户端 GET /users/123 → 服务端返回用户表述（传输资源状态）

• 客户端修改表述后 PUT /users/123 → 服务端更新资源（传输新状态）

完整逻辑链：

客户端通过 HTTP 请求获取资源的表述（Representation），该表述携带了资源的当前状态（State），从而完成状态在客户端与服务端之间的转移（Transfer）。

简单类比：
想象一家餐厅（服务端），你（客户端）通过菜单（URI）点菜（GET 请求），服务员端上菜品（资源的表述：一盘具体的菜）。你吃完后要求加辣（修改表述），服务员根据新要求更新菜品（PUT 请求）—— 菜品的状态通过“加辣版菜”这一表述完成了转移。

注:当前文章会不定期进行更新。如果您对本文有更好的建议，有新资料推荐， 可以点击： 欢迎分享优秀网站 。