理解 RESTFul 架构

REST 全称 Representational State Transfer(表述性状态转移), 十一组架构约束条件和原则. 如果一个架构符合 REST 的约束条件, 那么可以称为 RESTFul 架构

要理解 REST 原则, 就要从资源的定义, 获取, 表述, 关联, 状态变迁等角度入手

资源与 URI
统一资源接口
资源的表述
资源的链接
状态的转移

资源与 URI

任何事物, 只要有被引用到的必要, 他就是一个资源.

要让一个资源可以被识别, 需要添加一个唯一标识, 在 Web 中这个唯一标识就是 URI(Uniform Resource Identifier).

URI 既可以看成资源的地址, 也可以看成资源的名称.

如果一些信息没有使用 URI 来标识, 说明他不是一个资源

URI 的设计应该遵循可寻址原则, 具有自描述性, 需要在形式上给人以直觉上的关联

URI 设计上的一些技巧

使用 _ 或 - 提高 URI 的可读性
使用 / 表示资源的层级关系
使用 ? 过滤资源

统一资源接口

RESTFul 结构应该遵循统一接口原则, 统一接口包含了一组受限的预定义操作, 不论什么样的资源, 都是通过使用相同接口进行资源访问. 接口应该使用标准 HTTP 方法如 GET, PUT, POST, 并遵循这些方法的语义

POST 和 PUT 用于创建资源时的区别: 所创建的资源的 URI 是否由客户端决定.

资源的表述

客户端通过 HTTP 方法获取资源的表述, 而不是资源本身.

所谓资源的表述, 即是资源的展现, 而非其本质. 以文本为例, 可以通过 JSON, STRING 等形式表述出来, 而通过客户端获取的即是 JSON 形式的表述, 或 STRING 形式的表述.

客户端通过 HTTP 内容协商, 即 Accept 头请求一种特定个事的表述, 服务器则通过 Content-Type 通知客户端资源的表述形式

资源的连接

REST 使用 HTTP 方法操作资源, 在表述格式中添加链接来引导客户端, 这种具有连接的特性称为连通

状态的转移

无状态通信原则: 服务端不应该保存客户端的状态

应用状态与资源状态

应该区分应用状态和资源状态, 客户端负责维护应用状态, 服务端维护资源状态. 客户端与服务端的交互应当是无状态的, 并且在每一次请求中包含处理该请求所需要的一切信息. 服务端不需要在请求间保留应用状态, 只有在接收到实际请求的时候, 服务端才会关注应用状态. 这种无状态通信原则, 使得服务端和中介能够理解独立的请求和相应. 多次请求中, 同一客户端也不再需要依赖同一服务器, 方便实现高可扩展和高可用性的服务端.