接口测试平台代码实现43:接口底层请求逻辑

终于结束了接口调试层的前端编写。来到了后台代码处理。其实就是点击Send按钮，我们调用requests来发送请求，并把返回值显示到调试层的返回体中即可,注意实际中这部分会越来越复杂，内容也会越来越多，本教程目前章节只会实现初始的各种请求难度，后续章节可能会不断完善这块。

首先打开P_apis.html ,找到调试的Send按钮：

注意，我们要给这个按钮添加一个onclick函数ts_send()，也就是请求函数。

然后我们去下面的script中找个位置，新建这个函数：

好，让我们现在来设计一下这个函数：

首先他要获取这个接口当前所有的数据，用户正在选择的编码格式和请求体。

然后发出请求给后台传递这个接口的所有数据。然后接受到后台返回值后，直接切换到返回体子页面，并把返回值显示到返回体的多行文本框中。

(获取各种接口数据的代码和保存接口的函数中基本相同，所以基本可以直接复制)

好，代码如下：大家直接复制保存函数中的代码即可，但是

要注意修改请求url为/Api_send/，返回值处理方式也做了变更

好，复制完了之后别忘了修改下请求地址。

我们接下来要写好当这个send请求成功后，接收到后端给的返回值就显示在调试层中的代码，也就是这个位置，我们删掉了复制保存函数中刷新页面的代码，取而代之的是：

好了。我们前端目前的改动基本结束了。去开始写后端。

首先是urls.py中写好对照：

然后去后台新建这个Api_send函数：

这个Api_send函数的代码仍然可以大部分都复制Api_save保存函数的代码哦～

我们先没做发送请求的代码，而是先写死了个demo返回值。来测试前端显示返回值的效果如何：

重启服务，刷新页面。点击一下send按钮看看：

发现已经成功切换到了这个返回值页面了。

（有同学反馈说这个返回值子页面颜色不好看，所以给换了，大家自己也自主设计一下）

这里有个小bug，大家需要跟我一起处理一下。

就是我们无论是发送请求/还是保存接口时，请求体编码格式都保存用户当前所选的子页面。但是如果当用户选的并不是任何一个编码格式，而是返回体子页面的时候，会怎样呢？

答案是报错：

关于这个问题是属于设计上的漏洞。因为当处于返回体子页面时候，我们系统无法推断出用户到底想保存/请求的是哪种编码格式。所以我们应该不允许用户在返回体页面激活时点击保存或Send按钮。

有的同学会问了，那么假如他想连续发送请求的话，他还需要切换回刚刚的请求体编码格式子页面再点击Send，这样会不会麻烦了一点点。

其实这里我们很少会出现这种操作，毕竟如果返回体成功正确，他就不会再点击Send了，如果不正确，那么八成需要去修改刚刚的请求体，就需要先切回去。不过也有大概率去修改的是url等，而不是修改请求体。所以最好还是可以保存最近一次请求的请求体编码格式和请求体 比较好。这里就涉及到了我们要想办法记住用户上一次选择的请求体编码格式和请求体。

那么这个我们其实可以通过在数据库接口表给他加俩个字段来实现，一个是上次的请求体方式，一次是上次的请求体。

既然修改了数据库结构，那么就要执行那俩句同步生效的命令了：

不知道有多少人能背着写出来：

执行成功后，我们切换回P_apis.html中，仔细研究下这个报错是怎么产生的，如何解决：

我们注意到，当用户选择激活的子页面是编码格式的时候，才会定义声明ts_api_body这个变量，那么当选择激活的是返回体子页面时候，自然这个变量不存在，所以报错了。

那么我们的解决办法就是，当请求体编码格式这个函数

当它为#response的时候，也就是返回体的时候，也就是不是任何一种编码格式的时候。后台要对其进行处理，选用上一次的请求体编码格式和请求体内容来进行再次请求。

所以我们去后台编写ts_send()函数：

我们先加一句print，打印一下看看此时的ts_body_method也就是请求体编码格式的值到底是什么吧？

果然是这三个大字。

然后我们加一个判断：

如上图，只有当ts_body_method为返回体三个字时，就去数据库中找到上次存储的东西。如果是正常请求，那么就保存他们为last的俩个字段。

不过这时，其实还没有完全完成。因为还有一个新的小bug出现了。就是如果用户第一次就直接手动切换到返回体子页面，然后直接点Send怎么办？

我们去获取上次的请求体编码格式和请求体内容时发现 还没有储存，是空的。这时候我们要提醒用户，请先设置好请求体再点击Send即可。

所以继续修改这个函数：

又增加了一层判断。当请求体编码格式为空或者None时，就给他返回这句提示。这句提示会显示在返回体中。

试下效果：

如图，没啥问题了。

请求功能我们解决了这个bug，那么保存功能呢？我们好好设想一下场景：

场景1:用户设置好请求体编码格式和内容后，直接点击保存按钮。这时什么问题都没有，保存成功。

场景2:用户设置好请求体编码格式和内容后，点击Send按钮测试了一下，发现返回体没问题，这时他就会直接点击保存按钮。那么我们的俩个字段数据从哪来呢？当然是上一次的俩个last字段了。因为在他请求的时候，这俩个字段就已经保存了这次的请求体编码格式和内容了。

所以我们找到保存函数，按如下方式更改：（其中的api_name我挪了下位置方便看）

好，让我们来测试一下。

新建了一个接口，然后在form-data中输入几行参数，然后点击Send按钮，等到返回体子页面激活后，我们直接点击保存按钮。弹层自动关闭。我们再打开看看是否保存成了。发现保存成功了，自动切换到了form-data上并且显示了刚刚输入的几行参数。

好了本节课到此结束。小伙伴是不是觉得有点比之前烧脑了呢？

不要担心，这是正常的。后端的逻辑稍难一些是常理。

能持续跟到现在的点个赞再走哈～