使用REST风格架构您须要知道的一些事

• 1. REST的由来
• 2. REST的构成
  • 2.1. 资源
  • 2.2. 资源的表述
    • 2.2.1. MIME(Multipurpose Internet Mail Extensions)
    • 2.2.2. 缓存约定
  • 2.3. 资源的自描述
    • 2.3.1. 资源的当前状态
    • 2.3.2. 操做资源的统一接口
    • 2.3.3. 请求的无状态
  • 2.4. HATEOAS
• 3. REST与分布式事物
• 4. REST的典型应用案例
• 5. REST vs RPC
• 6. 总结

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. 资源的当前状态

资源的当前状态由如下几项共同组成：

1. 属于该资源的信息项目的值，好比订单的编号，建立日期。
2. 相关资源的连接，好比订单的客户连接以及订单明细连接。
3. 表示资源未来会迁移到某种可能状态的连接，好比迁移到完成状态的连接:/order/1/completeness POST
4. 对应该资源与其余资源相关联的任何业务规则的求值结果，好比订单统计表：/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的无状态是指客户端请求服务器时，应提供足够的信息以让服务器能理解并提供服务。无状态的好处包括：

1. 改善可见性（监视系统没必要为了肯定一个请求的所有性质而去查看请求以外的其余请求）
2. 改善可靠性（减轻了从局部故障中恢复的任务量）
3. 改善可伸缩性（服务端没必要在多个请求直接保存状态，从而容许服务器迅速释放资源）

缺点：

1. 因为服务器不能保持会话状态数据，则会形成在每一次请求中发送大量重复的数据，可能会下降网络性能。

下图是请求有状态和无状态的对比例子：

2.4. HATEOAS

HATEOAS(The Hypermedia As The Engine Of Application Statue)，中文意思是“将超媒体做为应用状态的引擎”，这是REST的最高目标(也叫主要架构约束）。

HATEOAS包括两个概念：

1. 应用状态由应用（系统）中的各资源状态组成，资源状态的变化致使应用状态的变化。
2. 经过在资源表述中添加状态迁移的超连接引导客户端改变资源状态。

好比：销售订单在建立后，客户端经过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

5. REST vs RPC

REST式的Web服务和RPC式的Web服务在接口定义上的区别是，REST使用HTTP通用方法做为统一接口的标准词汇，REST式的Web服务所提供的方法信息都在HTTP方法里，而RPC式的web服务所提供的方法信息在SOAP/HTTP信封里（其封装的格式一般是HTTP或者是SOAP），每一个RPC式的web服务都会公布一套符合本身商业逻辑的方法词汇。

RPC的典型案例

1. 百度lbs服务API

好比API: 行政区划区域检索，之因此是rpc，是因为：

1. 在参数中指定了资源格式MIME（此例是json），就是说资源表述由百度官方自定义协议解释。
2. 返回状态和错误信息封装在返回结果中，说明对于错误处理也由百度官方自定义协议解释。
3. 返回结果关心的是知足当前接口数据，若是想进一步了解街道信息，客户端须根据获取街道信息API定义获取。

http://api.map.baidu.com/place/v2/search?query=ATM机&tag=银行&region=北京&output=json&ak=您的ak GET

若是通过rest风格改造，行政区划区域检索API的返回结果能够是以下形式：

注：百度lbs不是面向应用状态迁移设计，所以采用rpc也是合适的。

2.Saleforce SOAP API

Saleforce提供了SOAP（简单对象访问协议） API,SOAP 经过发布WSDL（网络服务描述语言）文件来描述服务器提供的API的输入参数结构和返回数据结构以及可能的异常信息。客户端经过WSDL生成客户端调用代码（SOAP语言无关，可跨开发语言调用），就能调用远程的服务API。

下图表示表示了Saleforce的提供的API的WSDL：

注：Saleforce也提供了REST的API。

如下是两者的主要区别：

	REST	RPC
HTTP协议地位	应用协议	传输协议或者不用
传输协议	HTTP	HTTP或者TCP
消息序列化类型	MIME	MIME或者自定义协议
传输性能	中	高
服务处理性能	中	高
接口特色	通用（HTTP动做）	自定义接口动做
应用协议	HTTP	自定义
应用状态迁移方式	资源状态变化	业务数据状态变化
缓存扩展性	强	自定义
客户端耦协力度（协议）	弱	强
客户端代码执行	按需提供（JS,CSS,HTML等）	默认不支持
客户端的库支持	不须要	最好有，且和服务同步升级
防火墙穿透力	强	默认不支持
公网组件支持度	现成支持，包括（反向）代理服务器，防火墙，缓存服务器，用户代理（浏览器等）	需自行支持（http传输除外）
企业应用标准化程度	低（企业自定义）	中（基于SOAP协议，各厂商产品容易集成）

如下是主流RPC和REST框架

框架	特色	开发语言
Thrift	Thrift是一个跨语言的RPC框架，自带的代码生成引擎大幅提升了开发效率，从而使它如此流行。 最初由Facebook团队设计开发，如今已贡献给Apache	多语言
Dubbo	Dubbo是阿里巴巴开源的专门为Java设计的、成熟的RPC框架。支持基本的服务治理，全部服务治理 功能均在Client端集成：服务发现、负载均衡、容错、监控等	Java
Spring HATEOAS	Spring HATEOAS 能够很方便建立 基于HATEOAS 原则的REST 风格接口 ， 但须要依赖于 Spring 和 Spring MVC	Java

6. 总结

HTTP的本意是方便应用系统实现REST的架构，不过人们在早期并无意识到它的优势，所以目前更多使用的是RPC框架，由于REST 对开发人员的能力要求更高。综上，REST具备如下主要特色：

1. 以HTTP为应用协议。
2. 基于WEB中间件进行扩展：缓存代理提升缓存扩展，反向代理提供负载均衡和内外网协议转化（HTTPS和HTTP之间)。
3. 请求的无状态：因为服务器没有会话上下文信息，提升系统的可伸缩性。缺点是传输冗余一些。
4. 多级缓存：客户端代理，代理服务器，缓存服务器提供了强大缓存能力，提升了系统的可用性。
5. 对资源内容的描述方式，好比MIME协商或者在此基础上的扩展格式，保证了系统的简单性和通用性。
6. 资源状态变化促成应用状态迁移（HATEOAS），可以使开发者以资源为中心建模，这种设计相对简单。
7. 资源表述中连接广告了应用的状态流，但并不强迫客户端进行处理，有利于客户端平滑升级。