Dbqb_Study/zhangbo/第七天学习笔记.txt

REST与RESTful架构学习总结
REST是一组架构约束和原则，RESTful则是符合这些约束的架构风格，核心是利用Web现有标准实现高效、可扩展的资源交互。
一、核心概念梳理
1. REST本质：并非新技术，而是基于HTTP等Web标准的架构原则集合，由HTTP规范编写者Roy Fielding在博士论文中提出，目标是构建功能强、性能优、易通信的网络应用架构。
2. RESTful定义：遵循REST约束（如统一接口、无状态通信等）的架构即为RESTful架构，核心围绕“资源”展开交互。
二、关键核心原则（围绕资源展开）
 1. 资源与URI：唯一标识资源
资源：任何需被引用的事物（实体或抽象概念，如用户信息、订单、优惠套餐），需通过唯一URI标识。
URI设计技巧：用_/-提升可读性，/表示层级关系，?过滤资源，,/;表示同级关系；URI仅表资源名称，不包含操作（如避免/getUser/1这类格式）。

2. 统一资源接口：标准化操作
采用HTTP标准方法（GET、POST、PUT、DELETE）操作资源，遵循方法语义：
  GET：安全且幂等，用于获取资源；
  POST：不安全且不幂等，用于创建资源、部分更新等；
  PUT：不安全但幂等，用于客户端指定URI创建或全量更新资源；
  DELETE：不安全但幂等，用于删除资源。
配套HTTP状态码（如200成功、201创建、404未找到）实现语义化通信，避免依赖响应体传递错误信息。

3. 资源的表述：多格式交互
客户端获取的是资源的“表述”（非资源本身），支持多种格式（JSON、XML、HTML等）。
通过HTTP内容协商：客户端用Accept头指定格式，服务端用Content-Type头返回实际格式；不支持的格式返回406状态码。
不建议在URI中带版本号或格式后缀（如.json），优先用请求头区分。

4. 资源的链接：超媒体引导
核心特性“超媒体即应用状态引擎”，通过表述中的链接（如响应头Link、响应体url字段）引导客户端交互，提升资源连通性，而非仅关注URI设计。

5. 状态的转移：无状态通信
服务端不保存客户端应用状态，每次请求需包含所有处理信息（无状态通信）；客户端维护应用状态，服务端维护资源状态。
应用状态通过服务端提供的超媒体链接实现转移，客户端无需依赖固定服务端节点，提升扩展性。