REST全称是Representational State Transfer, 意思是表述(表征)性状态转移.REST是一组架构约束条件和原则. REST本身并没有创造新的技术, 组件和服务, 而隐藏在RESTful背后的理念就是使用WEB的现有特征和能力, 更好的使用现有Web标准中的一些准则和约束.
分别从资源的定义, 获取, 表述, 关联, 状态变迁等角度
资源与URI
统一资源接口
资源的表述
资源的链接
状态的转移
资源与URI
任何事物, 只要有被引用到的必要, 他就是一个资源, 资源可以是实体, 也可以只是一个抽象概念.
- 某用户的手机号
- 某用户的个人信息
- 最多用户订购的GPRS套餐
- 两个产品之间的依赖关系
- 某手机号的潜在价值
要让一个资源可以识别, 需要有一个唯一标识符, 在Web中这个唯一标识就是URI(Uniform Resource Identifier)
URI既可以看成资源的地址, 也可以看成是资源的名称. 如果某些信息没有使用URI来表示, 那他就是一个资源, 只能算是一些信息而已. URI的设计应该遵循可寻址性原则, 具有自描述性, 需要在形式上给人直觉上的关联.
增加_或-分隔符分割一些单词, 让URI看起来更人性化
使用/来表示资源的层级关系
使用?用来过滤
, 或 ; 可以表示同级资源的关系
统一的资源接口
RESTful架构应该遵循统一接口原则, 统一接口包含了一组受限的预定义的操作, 不论什么样的资源, 都是通过使用相同的接口进行资源的访问. 接口应该使用标准的HTTP方法和GET, PUT和POST, 并遵循这些方法的语义
资源的表述
客户端取的只是资源的表述, 资源在外界的具体呈现, 可以有多种表述(或称为表现, 表述)形式, 在客户端和服务端之间传输的也是资源的表述, 而不是资源的本身.
资源的表述包括数据和描述的元数据, 例如, HTTP头"Content-Type"就是这样一个数据属性.
客户端已Accept头请求格式的表述, 服务端则通过Content-Type告诉客户端资源的表述形式.
application/json, text/html
在URL里面带上版本号
- http://api.example.com/1.0/foo
- http://api.example.com/1.2/foo
- http://api.example.com/2.0/foo
通过Accept头部来区分,
- Accept: vnd.example-com.foo+json; version=1.0
- Accept: vnd.example-com.foo+json; version=1.2
- Accept: vnd.example-com.foo+json; version=2.0