RESTful 架构

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