第三篇：RESTful介绍

在介绍restful之前先放一张从之前文章评论里看到的图，我觉得它把soap和rest之间的一些区别形容地非常形象。

在第一篇和第二篇中我们也介绍过，soap协议传递的报文要基于xml格式的soap消息，它定义了非常复杂的xml schemas，因此会让传递的消息变得非常重，而rest是充分利用了http协议本身语义，所以会比较轻量。那么除了这些，rest和我们常用的soap协议又有那些区别呢？rest为什么会被看成是未来webservice的发展趋势？下面就让我们具体来看看什么是rest，什么是restful webservcie。

1.概述REST和RESTful

REST全称是Representational State Transfer，中文意思是表征性状态转移。 它首次出现在2000年Roy Fielding的博士论文中，Roy Fielding是HTTP规范的主要编写者之一。 他在论文中提到："我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。REST指的是一组架构约束条件和原则。" 如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。

REST本身并没有创造新的技术、组件或服务，而隐藏在RESTful背后的理念就是使用Web的现有特征和能力， 更好地使用现有Web标准中的一些准则和约束。虽然REST本身受Web技术的影响很深， 但是理论上REST架构风格并不是绑定在HTTP上，只不过目前HTTP是唯一与REST相关的实例。

是不是被上面一段话整的云里雾里？其实用人话来总结就是：

• REST是一种风格是用URL定位资源，用HTTP动词（GET,POST,DELETE,PUT,PATCH ）描述操作的协议。
• RESTful实现REST风格的一种软件架构风格，提供了设计原则和约束条件。

2.理解REST

2.1 资源

REST全称是表征性状态转移，表征指的就是资源。任何事物，只要有被引用到的必要，它就是一个资源。资源可以是实体(例如手机号码)，也可以只是一个抽象概念(例如价值) 。下面是一些资源的例子：

• 某用户的手机号码
• 某用户的个人信息
• 最多用户订购的GPRS套餐
• 两个产品之间的依赖关系
• 某用户可以办理的优惠套餐
• 某手机号码的潜在价值

2.1.1资源的标识

要让一个资源可以被识别，需要有个唯一标识，在Web中这个唯一标识就是URI(Uniform Resource Identifier)。

URI既可以看成是资源的地址，也可以看成是资源的名称。如果某些信息没有使用URI来表示，那它就不能算是一个资源， 只能算是资源的一些信息而已。URI的设计应该遵循可寻址性原则，具有自描述性，需要在形式上给人以直觉上的关联。这里以github网站为例，给出一些还算不错的URI：

• https://github.com/git
• https://github.com/git/git
• https://github.com/git/git/blob/master/block-sha1/sha1.h
• https://github.com/git/git/pulls
• https://github.com/git/git/pulls?state=closed
• https://github.com/git/git/compare/master…next

2.1.2 统一资源接口

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

如果按照HTTP方法的语义来暴露资源，那么接口将会拥有安全性和幂等性的特性，例如

• GET和HEAD请求都是安全的，无论请求多少次，都不会改变服务器状态。
• GET、HEAD、PUT和DELETE请求都是幂等的，无论对资源操作多少次，结果总是一样的，后面的请求并不会产生比第一次更多的影响。

GET /zoos：列出所有动物园
POST /zoos：新建一个动物园
GET /zoos/ID：获取某个指定动物园的信息
PUT /zoos/ID：更新某个指定动物园的信息（提供该动物园的全部信息）
PATCH /zoos/ID：更新某个指定动物园的信息（提供该动物园的部分信息）
DELETE /zoos/ID：删除某个动物园
GET /zoos/ID/animals：列出某个指定动物园的所有动物
DELETE /zoos/ID/animals/ID：删除某个指定动物园的指定动物

REST的发明者Roy Fielding博士曾经说过“Hypermedia作为应用引擎”是REST的前提， 这不是一个可选项，如果没有Hypermedia，那就不是REST。(摘自Infoq对Fielding博士的第二段访谈）

因此除了符合HTTP协议自身的语义，REST还要满足Hypermedia（超媒体即应用状态引擎（hypermedia as the engine of application state））。

采用Hypermedia的API在响应（response）中除了返回资源（resource）本身外，还会额外返回一组链接（link）。 这组链接描述了对于该资源，消费者（consumer）接下来可以做什么以及怎么做。

这样做的好处是：

1. 不再揣测如何组合使用API
2. 不用再考虑API的版本
3. 彻底与API的内部实现解耦

在这里分享一篇详细介绍Hypermedia的文章，写得很好，有兴趣的同学可以点进去了解下。

http://hippoom.github.io/blogs/value-of-hypermedia-from-client-perspective.html

2.1.3资源的表述

客户端通过HTTP可以获取资源，这个资源一般只是资源的表述。 例如文本资源可以采用html、xml、json等格式，图片可以使用PNG或JPG展现出来

2.2 无状态

“会话”状态不是作为资源状态保存在服务端的，而是被客户端作为应用状态进行跟踪的。即RESTful 服务是无状态的并且不会为任何客户端保持状态。一个请求不应该依赖过去的请求，服务对待每个请求都是独立的。客户端应用状态在服务端提供的超链接的指引下发生变迁。服务端通过超链接告诉客户端当前状态有哪些后续状态可以进入。

举个栗子，假设我们在阅读一篇需要翻页的文章，我们如果要访问下一页。

有状态的请求就需要记录我们上一次请求的页数PageNo，然后根据PageNo请求下一页

有状态设计：
Request1: GET http://MyService/Page/1
Request2: GET http://MyService/NextPage

Request2的请求是要基于Request1请求的页数来进行的，服务器需要记住这个页数，否则Request2无法进行。即Request2需要依赖Request1操作，如果Request1操作不成功，则Request2也不会成功。

而无状态设计中每一步都是独立，我们请求任何一页都不需要知道上一次请求的是哪一页。

无状态设计像这样：
Request1: GET http://MyService/Page/1
Request2: GET http://MyService/Page/2
每个请求都能被单独对待。

无状态服务更容易设计成集群，更容易维护，更容易伸缩。这样的服务提供了更好的响应时间，因为它们能容易进行负载均衡。随着微服务的概念越来越普及，无状态设计势必会成为未来的趋势。

综上，我们总结下REST的要求：

1. 客户端和服务器结构 通信只能由客户端单方面发起，表现为请求-响应的形式。
2. 连接协议具有无状态性
   
   通信的会话状态（Session State）应该全部由客户端负责维护。
3. 能够利用Cache（缓存）机制增进性能
   
   服务器返回信息必须被标记是否可以缓存，如果缓存，客户端可能会重用之前的信息发送请求。
4. 统一接口（Uniform Interface）
5. 层次化的系统
   
   系统组件不需要知道与他交流组件之外的事情。封装服务，引入中间层。
6. 按需代码（Code-On-Demand ） - Javascript （可選）
   
   泛指任何按照客户端软件（例如，浏览器）的请求，将可执行的软件程序从服务器计算机发送到客户端的技术。

3.怎么评价REST

3.1 REST优势

• 轻量，直接基于http，不在需要任何别的诸如消息协议。get/post/put/delete为CRUD（增删改查）操作，充分利用 HTTP 协议本身语义。
• 客户-服务器（Client-Server）客户端服务器分离，提高用户界面的便携性（操作简单），通过简化服务器提高可伸缩性（高性能，低成本），允许组件分别优化（可以让服务端和客户端分别进行改进和优化）
• 无状态（Stateless），从客户端的每个请求要包含服务器所需要的所有信息。
  • 提高可见性（可以单独考虑每个请求）
  • 提高了可靠性（更容易从局部故障中修复）
  • 提高可扩展性（降低了服务器资源使用）
• HTTP 本身提供了丰富的内容协商手段，无论是缓存，还是资源修改的乐观并发控制，都可以以业务无关的中间件来实现，限制了系统的复杂性，提高了可扩展性。

3.2 RESR缺点

• restful首先是要求必须把所有的应用定义成为“resource”，然后只能针对资源做有限的四种操作（即增删改查）。有许多现实中需要的API无法融入到restful所定义的规范中，比如user login / resetpassword等。虽然可以把login / password等也纳入为某种资源，然后进行增删改查。但这是在解决一些原本不存在不需要解决的问题，纯属浪费。 restful API仅适用与业务非常简单的场景，比方说，就是为了提供少量数据表单的增删改查。而这种场景实在是太过简单，实际中几乎找不到。所有的接口，服务器端原本就存在有相应的函数，它们本来就有自身的命名空间，接受的参数、返回值、异常等等。
  
  采用轻便的方式暴露出来即可。无需把一堆函数重新归纳到“资源”，再削减脑袋把所有的操作都映射为“增删改查”。
• 开发效率低【不适应于自动化处理】
• 运行效率低【需要比较复杂的字符串匹配模式】
• 环境适应性差【不适应参数复杂的情况】

4.RESTful的应用

• 亚马逊提供rest风格的接口查找图书
• 雅虎提供的Web Service也是REST风格的