You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
30 lines
2.4 KiB
30 lines
2.4 KiB
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. 状态的转移：无状态通信
|
|
服务端不保存客户端应用状态，每次请求需包含所有处理信息（无状态通信）；客户端维护应用状态，服务端维护资源状态。
|
|
应用状态通过服务端提供的超媒体链接实现转移，客户端无需依赖固定服务端节点，提升扩展性。
|
|
|