1. REST的由来
REST即表述性状态传递（英文：Representational State Transfer，简称REST）是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。
上世纪90年代面对高速发展的互联网规模，HTTP1.0需要进一步改进。Roy Fielding 着手制定HTTP1.1的标准及后续扩展工作。HTTP1.1重视降低WEB系统开发的复杂性(通过增强HTTP的请求头和响应头），提高系统的可扩展性（通过更容易的缓存指令）以及其他性能优化工作（比如长连接和多个请求和响应可以重叠等）。
Roy Fielding在制定HTTP时有一个愿景：Web世界的应用程序应随着不断的超连接跳转来实现应用系统状态迁移，所以HTTP应该是一个应用协议，而不是一个纯粹的超文本传输协议。
这就是REST的由来。当我们在谈论REST的时候，表示我们在谈论Web世界的应用一种基于HTTP的架构风格。
2. REST的构成
2.1. 资源
在restful中资源是核心抽象，任何会被互联网组件访问的信息都是资源，并用一个URL/URN来标识。
举例来说，获取某网站的2017年10月1号的天气信息，该网站可以命名改信息为http://www.somesite.com/weather/2017/10/1或者 http://www.somesite.com/weather?year=2017&month=10&day=1。客户端浏览器能用GET方法合法的获取该资源。
如果天气采集人员要创建2017年10月1号的天气信息，则用POST方法提交表单给http://www.somesite.com/weather完成创建资源工作。
http://www.somesite.com/weather并没有制定哪一天的天气信息，但它确实资源，这体现资源的抽象性。
2.2. 资源的表述
资源的表述是指资源的表现形式，这些形式由请求方和资源提供方通过HTTP协商指定。包括以下内容：
2.2.1. MIME(Multipurpose Internet Mail Extensions)
MIME是多用途互联网邮件扩展类型，它是一个互联网标准，扩展了电子邮件标准，使其能够支持：
非ASCII字符文本；非文本格式附件（二进制、声音、图像等）；由多部分（multiple parts）组成的消息体；包含非ASCII字符的头信息（Header information）。
比如下图，客户端表示能接受json（首选），text（次选）以及任意格式（再次选）；服务器端返回json内容给客户端：
2.2.2. 缓存约定
所以的资源操作包括读取和更新操作，对于不频繁更新的数据数据多数可以进行缓存。这种换成越靠近客户端，用户体验越好，即提高了整体系统的可用性。
HTTP采取多层缓存机制，系统可以定义自己的缓存策略。（此处是否需要讲公共缓存，私有缓存，运行机制？）
其中代理服务器和缓存服务器应该只对公共缓存表述进行缓存，浏览器缓存对公共和私有的缓存表述都能进行缓存。通常代理服务器的缓存行为是用户所属组织支持的，不属于应用系统的行为。
2.3. 资源的自描述
资源的自描述是指：资源的表述里面应该包括资源当前状态的描述，以及对该资源或相关资源进一步操作的超链接。
2.3.1. 资源的当前状态
资源的当前状态由以下几项共同组成：
- 属于该资源的信息项目的值，比如订单的编号，创建日期。
- 相关资源的链接，比如订单的客户链接以及订单明细链接。
- 表示资源将来会迁移到某种可能状态的链接，比如迁移到完成状态的链接:/order/1/completeness POST
- 对应该资源与其他资源相关联的任何业务规则的求值结果，比如订单统计表：/order/statistics/year/2017 GET
下图是一个订单状态的json表述：
2.3.2. 操作资源的统一接口
HTTP的初衷是应用层协议，HTTP是REST风格的。HTTP的动作提供了操作字体的统一接口。
| 动作 | 接口作用 | 重复操作效果 |
|---|---|---|
| POST | 创建资源 | 不幂等 |
| PUT | 整体更新资源 | 幂等 |
| PATCH | 部分更新资源 | 不幂等 |
| DELETE | 删除资源 | 幂等 |
| GET | 获取资源 | 幂等 |
幂等 表示动作的重复执行不会再产生副作用（引起资源状态变化），比如删除一个资源后再次删除也不会产生作用，同时系统也不应该返回错误信息，而是总是返回成功。
RPC或者SOAP风格的架构下HTTP是作为传输协议使用。
2.3.3. 请求的无状态
REST的无状态是指客户端请求服务器时，应提供足够的信息以让服务器能理解并提供服务。无状态的好处包括：
- 改善可见性（监视系统不必为了确定一个请求的全部性质而去查看请求之外的其他请求）
- 改善可靠性（减轻了从局部故障中恢复的任务量）
- 改善可伸缩性（服务端不必在多个请求直接保存状态，从而允许服务器迅速释放资源）
缺点：
- 由于服务器不能保持会话状态数据，则会造成在每一次请求中发送大量重复的数据，可能会降低网络性能。
下图是请求有状态和无状态的对比例子：
2.4. HATEOAS
HATEOAS(The Hypermedia As The Engine Of Application Statue)，中文意思是“将超媒体作为应用状态的引擎”，这是REST的最高目标(也叫主要架构约束）。
HATEOAS包括两个概念：
- 应用状态由应用（系统）中的各资源状态组成，资源状态的变化导致应用状态的变化。
- 通过在资源表述中添加状态迁移的超链接引导客户端改变资源状态。
比如：销售订单在创建后，客户端通过GET操作获取一个订单信息，然后请求“审批订单”链接使订单变成“已审批“状态。客户端再请求”执行订单“完成订单。这就是一个简单工作流程。
3. REST与分布式事物
分布式系统中事物是一个重要话题，遗憾的是REST作为一种系统风格，并没有约定对事物管理进行规定。事物是服务器端的事情，不论采用何种事物处理方式都要避免对客户使用rest服务的影响。
4. REST的典型应用案例
1. GitHub Developer API
比如API：列出pull的评论
GET /repos/:owner/:repo/pulls/:number/reviews
官网： https://developer.github.com/v3/pulls/reviews/
2. LinkIn 开发者中心
比如API：获取当前用户的信息
GET /v1/people/~?
官网:https://developer.linkedin.com/zh-cn/docs/rest-api