接口测试平台代码实现120:cookie持久化-3

本节我们来把接口库普通接口调试功能中的登陆态接口的cookie保持对话功能完善。

前端的话没有什么好改动的，我们直接把视线聚集到views.py中的函数：

Api_send
和project_login_send_for_other

我们先来看 被调用的登陆态接口，这个函数之前是去发送请求，然后返回提取的字段，交给Api_send。

现在我们要增加一个判断，也就是如果提取设置=='cookie'，那么就不是提取返回值字段来，而是要保持会话，根据前俩节的内容我们知道，如果要保持会话，那么我们的请求代码也要进行改变，之前是用requests.request,现在我们要声明一个a = requests.session()

然后登陆接口调用的是a.request方法，最终返回a，但是我们针对每种请求体类型都写了一个requests.request,所以虽然麻烦，但是目前逻辑上最简单的方法就是在不同的请求体类型中，都加入一个判断，虽然看起来比较low，但是系统执行起来的时候肯定只会走其中一个分支，所以运行并没有浪费效率的地方。

先来试着改一下none类型的：

我们把之前的请求代码放到了else里，新的if分支中判断了下返回体设置，然后声明了a，然后a进行请求登陆态接口，然后直接省略后面一切步骤，返回a即可。

之后我们依次改其他几种请求体类型：

好了，到这为止，我们理论上搞定了登陆态接口被调用的方法。

接下来我们要考虑普通接口调用它的时候的情况了。

之前它会返回一个字典，里面包含提取的登陆态字段。但是现在如果是cookie持久化的话，那么返回的就是a，a是什么呢？我们不用关心，反正a不是字典就可以了。

所以我们在接收的时候对登陆态返回的东西用类型判断一下，就知道是字典还是a了，若是a，那就是说明登陆态设置的是cookie持久化，那么普通接口的请求代码也要改，也要从requests.request改成a.request方法了。

不过这里比较复杂，让我们先来回忆一下，普通接口调试函数中关于登陆态的旧逻辑吧：

首先判断是否需要登陆态，需要就去请求，不需要就变成空字典。

然后会依次插入到url,header,和各种body中。

这时，无论需不需要，login_res都是字典，所以我们在后面请求体请求中，可以直接放心的用循环遍历login_res.keys()

但是我们现在增加了cookie相关，那么返回的就可能是a，那么我们后面的代码按现在的逻辑去遍历 直接就报错了。

所以我们需要判断login_res的类型看看是不是cookie持久化，若是，那么后面的所有具体不同的请求体类型的请求代码，直接全换即可。

首先是改url插入：

增加了if ，来判断login_res的类型，若是字典的情况，才会进行插入，否则就是cookie,不需要插入到url。

然后是header：

可以看到，只有当是dict字典时，才会进行插入header的操作。

然后是各种请求体：

首先是none:

其实就是简单判断了下，如果是字典那么还是之前的requests.request，如果不是，那么就是cookie持久化，那么就用a.requests来请求，此时a就是login_res，login_res是调用登陆态接口函数返回的东西。

接下来是其他几种：

注意，其中只有为字典时，才需要进行遍历插入请求体的代码，若不是，那么就直接用login_res请求就可以了。

到这里，其实就算搞定了。

大家可以自行测试一下。

最后欢迎分享和宣传哦～