支持RESTful风格的接口

2023-03-13  微不足道 

RESTful是什么呢?
HTTP协议的原创作者Roy Thomas Fielding 在他的博士论文中提出一个观点:我写这篇论文的目的,就是希望在符合架构原理的前提下,通过理解和评估以网络为基础的应用软件的结构设计,得到一种功能强,性能好且适用于通信的架构,REST指的是一组架构约束条件和设计原则。
结合于原创作者的观点,现在把符合 REST (Represertational State Transter, 表述性状态转移) 约束的架构称为RESTful架构。RESTful 由于是面向资源接口设计的并且十分的操作抽象,因此能简化开发人员的一些不良设计,并且可以最大限度地利用 HTTP 最初的应用协议设计理念。想要完全了解RESTful,我们就必须掌握资源、表现层和状态转移这3个概念。
1.资源
这里的资源是指网络上的实体或具体信息,如一段文本,一幅图片,一个多媒体文件或一种可以提供的服务。资源是通过URI(Uniform Resource Identifier,统一资源标识符)进行标识的,要想和资源进行交互,只需要访问资源对应的URI就可以了,参考如下:
http://127.0.0.1/v1/news:获取新闻
http://127.0.0.1/v1/group:获取群组列表
http://127.0.0.1/v1/profile:获取个人的详细信息
2.表现层
资源有多种表现形式,具体如何展示是由表现层控制的。例如:数据既可以使用JSON来描述,也可以使用XML来描述。在RESTful服务中,表现层控制着服务器和客户端之间资源的传递形式,比如使用JSON和XML传输文本,而使用JPG,WebP格式传输图片等。当然,通过HTTP传输的数据也可以压缩。
3.状态转移
当我们通过网络和网页发生交互时,就会产生交互式且流程化的信息传递,而在信息传递过程中,必然会有数据和状态的变化,这就是状态转移,状态转移是在表现层之上完成的。在状态转移过程中,我们会用到HTTP的以下4种基本操作。
GET 操作:用来获取资源。
POST操作:用来新建或更新资源。
PUT操作:用来更新资源。
DELETE操作:用来删除资源。
提倡使用的方式可参照:
DELETE http://127.0.0.1/v1/group:删除群组
POST http://127.0.0.1/v1/friends:添加群组
UPDATE http://127.0.0.1/v1/profile:更新个人信息
不提倡或不允许使用的方式如下:
http://api.pr.com/v1/deleteGroup
另外,RESTful要求HTTP状态码必须能够传递穿服务器的状态信息。例如,常用的HTTP状态码200表示成功,500表示服务器内部错误。
RESTful接口测试

RESTful风格的接口和测试工程师之间有这必然的联系,其实想要真正的理解RESTful风格的接口和测试之间的关系,需要先搞明白接口有哪些优点。我们可以简单的举例说明一下,比如组装家具,原材料组装的话需要适配各种样式的螺丝,这时候我们就需要准备各种型号的螺丝刀,所以问题来了,只需要根据螺丝的规则,选择相同的螺丝刀头简单替换就可以了,简单又方便。
通过理解上述的场景后,大致概括为,RESTful指的是一组架构约束条件和设计原则,其本质是为了让访问者一句URI就可以找到资源,然后通过简单的输入和输出完成与服务的交互。
REST所约束的每一个URI都是独一无二的资源,可通过HTTP方法进行资源操作,实现表现层的状态转移。这就像螺丝刀刀头一样,待解决的问题就像螺丝,每一个接口只面向一种特定的资源,而不用管其他接口的处理方式,这样就能够一目了然的知道改用那种螺丝刀刀头固定那种螺丝了,从而降低接口开发的复杂度。
开发同学只需要遵循RESTful规范并按照一定的内部定义开发外部接口,就能形成像螺丝刀刀头一样轻便的接口并对外提供服务。现在的很多项目中,无论是服务器端还是服务器端的调用,还是前端和服务器端的调用,通常会采用RESTful风格来设计接口。
但是对于测试同学来说,RESTful风格的接口使用的仍是之前的访问模式,他们同样是HTTP接口,并且同样可以使用我们之前封装的框架来完成接口测试的任务。但是,RESTful接口测试和HTTP接口测试还有有一些区别的,因为还需要对现有的框架做一些修改,方便与更好的支持RESTful接口测试。
因为Eolink这个工具可以支持RESTful接口做调试,可以使用Eolink工具来简单操作一下,请参照图片示例:

Eolink工具可以实现在线支持不同的RESTful风格的接口,选择协议类型/版本,通过下拉的方式选择不同的请求方式就可以在线编辑一个接口,快速实现接口的请求和返回信息,对于开发和测试工程师来说这是一个快速简便好入门的一个debug接口的好工具。
感兴趣的同学通过该链接可以尝试一下:
https://www.eolink.com/?utm_source=ceshiwo&utm_content=ceshiwo018
现在,大概明白了RESTful接口测试和HTTP接口测试有很大的关系,那么RESTful接口测试和HTTP接口测试又有什么区别呢?两个关键点—数据交互的承载方式和操作方式需要特别关注。
首先来说一下数据交换的承载方式。RESTful风格的接口只要以JSON(JavaScript Object Notation)格式进行数据交换。熟悉SUT(被测系统)使用的Battle系统的同学可能知道,在Battle系统的Readme.md文件中看到过请求正文和响应正文中有关数据不跟的一些定义,这个就是Json。虽然Battle系统不算严格意义上使用RESTful接口,但是在数据交换的承载方式上,Battle系统模仿了RESTful风格。
在讲讲数据交换的操作方式。在Battle系统中,我们仅仅使用了HTTP的GET和POST两种基本操作;但是在RESTful风格的接口中,HTTP的4种进本操作都会被用到,比如,GET操作用来获取资源,POST操作用来新建或更新资源,PUT操作用来更新资源,DELETE操作用来删除资源等。
明白了RESTful风格的接口和普通的HTTP接口的区别之后,我们就会想一想自己得框架需要添加什么内容才能支持RESTful风格的接口。内容的添加方法有两种—借助外力或自行封装。在这里对于第一个RESTful风格的借口来说,数据交换的承载方式是JSON,Battle系统使用的数据格式也是JSON,虽然全部操作都是由参数拼接的过程,但是这些足以能满足需求。
RESRful设计6原则
1.Client-Server:服务端客户端分离,客户端不包括数据,服务端不包括用户状态;
2.Stateless:无状态,让客户端对服务端的操作完全通过表现层来进行;
3.Cache:客户端可以缓存服务端数据;
4.Uniform Interface:统一接口,服务端客户端统一接口;
5.Layered System:分层架构,分层系统,客户端可不直接连接服务端;
6.Code-on-Demand:客户端从服务器获取需要的代码,在客户端处执行;
总得来说
REST架构风格由一组经过选择的架构约束组成,通过这些架构约束在候选架构上产生所期待的架构属性。尽管能够独立考虑其中每一个架构约束,但是根据它们在公共架构风格(common architectural styles)中的来源来对它们进行描述,使得我们理解选择它们背后的基础理论更加容易。

115°/1153 人阅读/0 条评论 发表评论

登录 后发表评论