本节我们来把接口库普通接口调试功能中的登陆态接口的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请求就可以了。
