接口 RESTful 中的超媒体:REST 架构的灵魂驱动

在 RESTful 架构中,** 超媒体(Hypermedia)** 是一个核心概念,它体现了 REST 的 “表述性状态转移(Representational State Transfer)” 的本质,也是区分 “真 RESTful API” 与 “伪 RESTful API” 的重要特征。而理解超媒体,需先明晰 REST 架构的六大约束,它们是 RESTful 设计的基石,超媒体则是这些约束的具象化体现。

一、REST 的六大约束

REST(Representational State Transfer)由 Roy Fielding 在 2000 年提出,其架构风格通过六大约束定义了分布式系统的设计原则,这些约束相互关联,共同确保系统的可扩展性、松耦合性和可维护性。

  1. 客户端 - 服务器(Client-Server):将用户界面(客户端)与数据存储(服务器)分离,二者通过统一接口通信。客户端可独立演化,不依赖服务器实现;服务器也能独立扩展,不影响客户端。例如客户端通过 HTTP 请求获取服务器资源(如GET /users),服务器返回 JSON/XML 格式的数据 。
  2. 无状态(Stateless):所有请求必须包含理解请求所需的全部信息,服务器不存储客户端的上下文状态,会话状态由客户端维护(如通过 Cookie、JWT 令牌)。该约束简化了服务器实现,提高可靠性,同时支持横向扩展。若服务器在内存中存储用户登录状态,导致请求必须路由到同一服务器实例,则违背了这一约束。
  3. 缓存(Cacheable):响应必须显式标记为可缓存或不可缓存,可缓存的响应能被中间层(如 CDN、代理服务器)缓存,减少对源服务器的请求,从而提高性能、降低延迟并减轻服务器负载。典型实现是使用 HTTP 缓存头(如Cache-Control、ETag)控制缓存策略 ,如HTTP/1.1 200 OK Cache-Control: max-age=3600 ETag: "123456"。
  4. 统一接口(Uniform Interface):包含资源标识(通过 URI 唯一标识资源,如/users/123)、资源操作(通过标准 HTTP 方法 GET、POST、PUT、DELETE 操作资源)、自描述消息(请求 / 响应包含足够元数据)和超媒体驱动(响应中包含链接,引导客户端后续操作,即 HATEOAS)。该约束解耦了客户端与服务器,简化系统架构,促进跨语言、跨平台集成。
  5. 分层系统(Layered System):系统架构分为多层(如客户端层、负载均衡层、API 网关层、业务逻辑层、数据层),每层仅能与相邻层交互。这提高了系统可扩展性,支持渐进式部署。在微服务架构中,API 网关作为中间层处理路由、认证,后方连接多个微服务,就是分层系统的典型实现。
  6. 按需代码(Code-On-Demand,可选):服务器可通过响应提供可执行代码(如 JavaScript),扩展客户端功能,动态增强客户端能力,减少客户端开发成本,例如浏览器通过

你可能感兴趣的:(DotNet,restful,架构,后端)