第三篇:RESTful介绍

Published on in 技术分享 with 17 views

在介绍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:

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
    1. 不用再考虑API的版本
    2. 彻底与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风格的


标题:第三篇:RESTful介绍
作者:MarsChan
地址:https://www.marscheng.cn/articles/2019/06/25/1561457793156.html

Responses