技术分享 | 如何确保API 的稳定性与正确性?你只需要这一招

164 篇文章 1 订阅
79 篇文章 2 订阅

现在,越来越多的 Web 应用转向了RESTful的架构,很多产品和应用暴露给用户的往往就是一组 REST API,这样有一个好处,用户可以根据需要,调用不同的 API,整合出自己的应用出来。从这个角度来讲,Web 开发的成本会越来越低,人们不必再维护自己的信息孤岛,而是使用 REST API 这种组合模式。

image1080×804 50 KB

那么,作为 REST API 的提供者,如何确保 API 的稳定性与正确性呢?全面系统的测试是必不可少的。Java 程序员常常借助于 JUnit 来测试自己的 REST API,不,应该这样说,Java 程序员常常借助于JUnit 来测试 REST API的实现!从某种角度来说,这是一种“白盒测试”,Java 程序员清楚地知道正在测试的是哪个类、哪个方法,而不是从用户的角度出发,测试的是哪个REST API。

image1080×654 61.1 KB

Rest-Assured 是一套由 Java 实现的 REST API测试框架,它是一个轻量级的REST API 客户端,可以直接编写代码向服务器端发起 HTTP请求,并验证返回结果;它的语法非常简洁,是一种专为测试 REST API 而设计的 DSL。使用 Rest-Assured 测试 REST API,就和真正的用户使用 REST API 一样,只不过 Rest-Assured 让这一切变得自动化了。

image1073×733 49.6 KB

模拟get请求

雪球网是一个股票投资网站,你可以使用网站的搜索功能来查询股票信息,比如我们想查询sougou的信息,下 面利用了charles分析工具来查看请求和回答:

image2124×1170 400 KB

这是一个Get请求,返回的内容格式如下:

现在,我们使用 Rest-Assured 来编写一个简单的测试程序调用相同的Get请求:

  • 第一步,我们要判断这是什么格式数据:json
  • 第二步,确定请求地址:从charles的结果中获取y为https://xueqiu.com/stock/search.json

tmp1064×275 24.7 KB

  • 第三步,填写表单:从chrome浏览器检查结果中查询request的query信息是code:sougou

我们的代码也很简单:

返回的结果却很残酷:

tmp1080×274 38.9 KB

与登陆账号,刷新页面有关的话,我首先想到了cookie,网站都用cookie来保存账号相关信息,于是加入 cookie:

返回结果正确,你问我惊不惊喜,老实回答,不惊喜。因为我搞不明白为什么一个查询需要Cookie验证,如果不加Cookie,返回的信息却是没有登陆!

image899×974 72.4 KB

显然,我的Cookie并不包含登陆信息,因为我压根就没有登陆,当然这是网站的设计,与Rest-assured无关。

1080×474 70 KB


更进一步

怎么区别xml与json

image942×679 33.3 KB

答:你看就知道了嘛,xml长这个样子

json长这个样子

given,when,then分别是什么

image965×707 32 KB

答:given用于放置需要的参数,比如上面例子中,我将访问参数:code和cookie放到了given里;when用于填 写要访问的url;then进行断言,来来判断结果是否正确。

模拟post请求

有的时候,我们想提交表单,这种情况下使用get会非常被动,于是post登场了。

下面是代码。

我相信此时你的内心是这样的。

别着急,下面我会讲清楚…

在我大万维网世界中,TCP就像汽车,我们用TCP来运输数据,它很可靠,从来不会发生丢件少件的现象。但是 如果路上跑的全是看起来一模一样的汽车,那这个世界看起来是一团混乱,非常紧急的警车可能被前面的汽车拦堵在路上,整个交通系统一定会瘫痪。

image1080×806 75.6 KB

为了避免这种情况发生,交通规则HTTP诞生了。HTTP给汽车运输设定了好几个服务类别,有GET, POST, PUT, DELETE等等,HTTP规定,当执行GET请求的时候,要给汽车贴上GET的标签(设置method为GET),而且要求把传送的数据放在车顶上(url中)以方便记录。如果是POST请求,就要在车上贴上POST的标签,并把货物放在车厢里。当然,你也可以在GET的时候往车厢内偷偷藏点货物,但是这是很不光彩;也可以在POST的时候在车顶上也放一些数据,让人觉得傻乎乎的。HTTP只是个行为准则,而TCP才是GET和POST怎么实现的基本。

image1080×818 81.4 KB

使用断言

使用EqualTo

在前面,我们使用了EqualTo判断值是否是“搜狗”:

它的作用显而易见:判断值是否相同。比如下面的例子

如果你想验证LottoId是否等于5,你可以这样做:

使用HasItems

image906×677 37.8 KB

你可以用再次EqualTo(),对WinnerId[0]用一次,对WinnerId[1]用一次。

image992×714 40.4 KB

哈哈,当然不是。你可以使用HasItems,它是这么使用的:

从根开始定位

image1067×701 41.4 KB

额…请教王师傅。

image1080×608 37.8 KB

比如下面的代码,我们可以这么验证:

使用find

image1000×673 34.8 KB

image1024×641 37 KB

答对了,请一定要记住xml和json的区别,不要混谈,那么你能编写一个测试来验证杂货(groceries)的类别是 否包含巧克力(Chocolate)和咖啡(Coffe)吗?

image1051×684 31.5 KB

这确实达到了我的要求,但代码明显有很多bug,如果我更改了category的位置,像下面这样,你的代码就不 适用了,我不难为你了,请王师傅来解答吧:

image1080×688 46.1 KB

find的用法展示的很清楚,不需要我多讲,当然还有一点要注意,你可以这么使用find:

**是个特殊用法,它从xml文档根部开始,进行深度搜索,直到找到符合我们需要的项。

image989×740 44.8 KB

使用findAll

image1047×647 39 KB

现在我手头只有20块钱,我只能买两本书,我更喜欢世纪的谚语和白鲸记,现在的任务是:挑选出格低于10的书籍,并且标题是“世纪的谚语(Sayings of the Century)”和“白鲸记(Moby Dick)”

image1023×666 40.2 KB

对的,这时候应该使用findAll,可以粗鲁的认为多个find的叠加。findAll可以筛选出一批符合要求的数据,而 find只能筛选出一个符合要求的数据,这就像是我们只能挑出一个人领取一等奖,但有很多人可以拿参与奖, 两个方法都有自己的用武之地。

image1080×512 38.1 KB

下面的代码展示了findAll的用法:

提取想要的值

有时候,我们并不想验证是否正确,我们只想取出这个值以进行下一步处理,比如我想取出next的链接:/title?page=2,这种情况怎么办呢?

下面的代码判断内容是不是JSON,并且标题是My Title的话,就返回href链接/title?page=2,这个值被存放在nextTitleLink中,以供我们以后使用。

image880×561 33 KB

image892×470 96.9 KB

当然,有两点需要注意:

  • 返回类型是Response,我们可以用Response.xxx来二次提取想要的值。
  • extract().后面是response()方法,不要写错了。

更改默认值

rest-assured有很多默认值,也正因为如此,需要我们的填的参数可以很少,也可以很多,就像画画一样,可以很精致,也可以很简洁。

image1080×775 55.3 KB

修改端口

rest-assured发起请求时,默认使用的host为localhost,端口为8080,如果你想使用不同的端口,你可以这样做:

或者是这样

或者

修改baseURI和basePath

你也可能改变默认的baseURI、basePath

这就意味着,类似 get("/hello") 这样的一个请求,其实完整的请求为:http://myhost.com:80/resource/hello , 并且使用基础授权认证"username" and “password”。

其他

其他的默认值可以参考下面:

重置

你也可以重置为标准的baseURL(localhost)、basePath(空)、标准端口port(8080)、标准根路径root path(" "),默 认的认证scheme(none)以及URL编码(true),通过下面的方法重置:

specification

在不同的测试用例当中,我们可能会有重复的响应断言或者是请求参数,那么我们可以将重复的这一部分提取出来定义一个规范或者模板,这样的话在后续的测试用例当中就可以使用这个规范模板了。

image1032×1248 81.3 KB

为了达到这个效果,我们可以使用RequestSpecBuilder或 ResponseSpecBuilder来实现,它们之间的区别 是,前者用在请求中,后者则用在body中。

ResponseSpecification重用

例如,你想在多个测试用例中,都使用这样的断言:判断响应状态码是否为200,并且Json数组"x.y"的大小是否 等于2。你可以定义一个ResponseSpecBuilder来实现这个功能:

在这个例子中,需要重用的两个断言数据被定义在"responseSpec",并且与另外一个body断言合并,组成了这个测试用例中全部的断言,那么这个测试用例需要全部断言都通过用例结果才会通过,一旦其中一个断言失败,则测试用例的测试结果为失败。

RequestSpecification重用

同样,假如你想在多个测试用例中重用请求数据,可以通过下面的代码来实现:

这里的请求数据被合并在"requestSpec"中,所以这个请求包含了两个参数(“parameter1"和"parameter2”)以及一 个头部(“header1”)。

总结

本文就rest-assured的基本功能进行举例说明,其中例子大多来自于官方文档,同时我也建议大家多去阅读该开 发文档,其中有很多我们没有讲到的东西。

本文参考:

rest-assured官网:Usage · rest-assured/rest-assured Wiki · GitHub

rest-assured介绍:IBM Developer

get与post的区别:GET和POST两种基本请求方法的区别 - 在途中# - 博客园

使用specification:rest-assured的默认值与Specification重用 - lwjnicole - 博客园

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 在设计 PHP 的 API 接口时,需要注意以下几点: 1. 接口的安全性:应确保 API 接口能够安全地保护数据和资源,并防止未经授权的访问。 2. 接口的可用性:应确保 API 接口能够稳定地提供服务,并保证高可用性。 3. 接口的简易性:应设计简单易用的 API 接口,方便开发人员调用。 4. 接口的文档:应为 API 接口提供详细的文档,包括接口地址、请求方式、请求参数、响应数据等信息。 5. 接口的版本控制:应对 API 接口进行版本控制,以便在不影响现有应用程序的情况下对接口进行更新。 6. 接口的访问限制:可以考虑对 API 接口设置访问限制,如 IP 限制、API key 验证等。 ### 回答2: 设计一个PHP的api接口时需要注意以下几点: 1. 安全性:API接口需要确保数据传输的安全性,可以使用HTTPS协议来加密数据传输。此外,还需要通过身份验证和访问控制来保护接口免受未授权访问。 2. 响应格式:API接口应该返回标准化的数据格式,如JSON或XML。这样可以方便客户端对返回数据进行解析和处理。 3. 错误处理:在接口设计中,需要考虑各种可能的错误情况,并返回相应的错误码和错误信息给客户端。这有助于客户端进行错误处理和故障排除。 4. 模块化设计:建议将API接口设计成模块化的形式,即将不同功能的接口封装成独立的模块。这样可以提高代码的可维护性和可扩展性。 5. 接口版本控制:如果API接口存在需求变更或新增功能的可能性,建议设计接口版本控制机制,以便客户端可以选择使用不同版本的接口。 6. 缓存处理:对于一些频繁请求但不经常变动的数据,可以考虑在接口中加入缓存机制,提高接口的性能和响应速度。 7. 日志记录:为了方便排查问题和监控接口的运行情况,需要在接口中加入日志记录功能,记录请求和响应的相关信息。 8. 文档和示例:为了便于开发者理解和使用接口,需要提供详细的接口文档和示例代码。文档中应包含接口的请求方式、参数列表、返回值等信息。 9. 性能考虑:在接口设计时需要考虑接口的性能,尽量避免不必要的数据查询和计算,合理使用缓存和异步处理等技术手段来提高接口的性能。 10. 异常处理:在接口中需要考虑各种异常情况的处理,包括数据库连接异常、文件读写异常等。合理的异常处理可以提高接口的稳定性和可靠性。 ### 回答3: 设计一个PHP的API接口需要注意以下几点: 1. 功能明确:在设计API接口时,需要明确接口的功能,定义好每个API的用途和参数,确保功能的准确性和完整性。 2. 接口设计规范:遵守RESTful规范,通过合理的URI命名、请求方法(GET、POST、PUT、DELETE等)来实现不同操作,使接口易于理解和使用。 3. 参数验证与过滤:在接口中对传入的参数进行验证和过滤,确保参数的合法性,防止恶意攻击和错误数据的传入。 4. 错误处理与异常处理:当接口出现错误或异常时,需要进行相应的错误处理,返回合适的错误码和错误信息,方便接口调用者进行问题排查和调试。 5. 安全性考虑:对于涉及用户隐私或敏感数据的接口,需要进行身份验证和权限控制,确保只有合法的用户可以访问和操作接口。 6. 接口版本管理:当接口需要升级或变更时,需要考虑版本管理,防止因接口变更导致现有功能出错或不可用。 7. 接口文档和注释:设计API接口时,应编写清晰的接口文档和注释,描述接口的用法、参数和返回值,方便其他开发人员使用和理解。 8. 性能优化:在设计API接口时应考虑性能优化,例如使用缓存、减少数据库查询等方法,提高接口的响应速度和可扩展性。 9. 日志记录与监控:为了方便问题排查和系统监控,API接口需要进行日志记录,记录调用的请求和返回结果,方便定位问题和分析接口调用情况。 10. 接口的稳定性与兼容性:设计API接口时要考虑接口的稳定性和兼容性,尽量避免频繁的接口变更,确保接口的稳定性,减少对接口调用者的影响。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值