第三篇：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风格的