接口测试平台代码实现39:接口数据全部保存

 我们之前的章节已经解决了各种接口的数据的提取问题，本节的任务就是把这些传给后端，然后保存成功。

   打开P_apis.html,找到我们上次没写完的ts_save()函数：

我们之前之所以没有直接写完这个函数，是因为突然发现我们没有获取到接口id，所以传递给后端的时候，完全不知道这些数据是哪个接口的。所以我们中途去写了ts_show()函数，这个函数在打开弹层之后会永久保留当前的接口id在一个small标签中。然后我们的ts_save()函数就可以从这个永久的small标签中拿到当前接口id了。

   所以现在获取到这个id吧：

然后就是写一个请求 给后端发送这些数据了哈：

ulr我给定义为了：/Api_save/

那么到这里就可以继续了么，其实我们忽略了一个问题，就是其中的ts_api_body这个参数，他的类型目前看，因为用户选择的编码格式不同，这个请求体的类型也不同，分为两类：字符串和数组，这里我们只能按照字符串格式发出去，所以要把为数组的俩个情况在最后转变为字符串：

分别加上这句把数组变成字符串的代码，改成如下：

然后写好urls.py：

再去写后台函数：

让我们来思考下这个后台函数要做哪些事吧：

1. 获取到前端过来的所有数据
   
2. 保存
   
3. 返回保存成功文案
   

代码如下：

# 保存接口
def Api_save(request):
    # 提取所有数据
    api_id = request.GET['api_id']
    ts_method = request.GET['ts_method']
    ts_url = request.GET['ts_url']
    ts_host = request.GET['ts_host']
    ts_header = request.GET['ts_header']
    ts_body_method = request.GET['ts_body_method']
    ts_api_body = request.GET['ts_api_body']
    # 保存数据
    DB_apis.objects.filter(id=api_id).update(
        api_method = ts_method,
        api_url = ts_url,
        api_header = ts_header,
        api_host = ts_host,
        body_method = ts_body_method,
        api_body = ts_api_body
    )
    # 返回
    return HttpResponse('success')

我们接下来就是 启动服务，刷新页面，然后测试下各个编码格式的保存情况，看看是否报错等等。之前我说过，咱测试开发做的工具，千万不要有bug，不然太打脸了，因为也没有专门的测试排期，所以我们每做完一步都要仔细全面的测试。当然因为内部工具的关系，不用太追求各种异常输入异常处理情况。

在充分测试之后，没发现报错情况。我们就继续往下做。

目前的情况下，用户在点击了保存按钮后，虽然后台成功保存了新数据，但是这个调试弹层还没有关闭。所以我们给ts_save() 的请求的返回值function (ret){} 里面加入一个隐藏弹层的代码

再刷新页面试试，发现可以点击保存后关闭了弹层，比较符合使用习惯了。

接下来我们要思考一个问题：

我们每次隐藏弹层，弹层的各个输入框保存的内容其实并没有清空，那么下次我们点击其他接口的调试按钮时候，打开的其实仍然是这个弹层，所以各个输入框的内容其实还是上个接口的内容。这个就相当于这个缓存我们没有清理的后果，在我们很多app上也出现过类似bug。

有的同学会说，在我们的ts_show()函数中，已经明确会该给这个弹层的各个输入框加载新接口的数据了。自然会覆盖掉上一个接口的数据。

当然，这说的没有错，理想情况下是这样的。

不过以下俩种情况就不好说了：

1. 网速慢的时候，用户打开后会先看到旧的数据，然后过了2秒后，新的数据才加载进来替换。很容易让人怀疑自己的眼睛，或者调试出错。
   
2. 当新数据加载失败的时候，没有替换成功，但是用户可能不知道失败了，因为他看到的还是上一个接口的数据，他会以为这个旧数据就是当前接口的数据。如果他此时不小心点击了保存按钮，然后保存按钮就会真实的把这个旧数据变成新接口的。那么真正的新接口的数据就永远的丢失了。
   

所以为了以上的各种风险情况成真，我们有必要做一个清理缓存的函数，clear_ts_api()。这个函数每次运行都会把调试弹层的各个输入框清理干净。

那么何时运行呢，就在每次用户打开的时候，也就是放在ts_show()函数内的最开始位置调用。

   先新建这个函数：

然后内部开始写清空的代码：

这个函数呢其实也不是很简单的，我们在清理了简单部分后，就要继续处理复杂的请求体编码格式部分了。

在这之前，我们需要对html部分代码 当中的一些标签 加上id，以便更好的控制：

给none加上id，这样让新接口打开时默认先切换到none，而不是保存上一个接口的子页面切换状态，然后写好对应的初始化代码,注意是点击.click()

然后删除掉我们之前方便调试写的俩个表格类的请求体tr：

但是要注意，我们必须要留一个空行，不然会触发这个第三方表格插件的bug

改成如下即可：

然后就是我们要进行初始化的代码了，为了方便初始化调用，我们这里仍然要对俩个tbody都加上id：

然后我们去写代码：

这里我们运用的是强制把其的子内容改成空空的一个tr行内带着两个td列。

然后就是紧接着的，五个多行文本框的清空了：

最后还有一个 返回体文本框，我们顺便也给它清空了吧，以免上一个接口的返回值被误认成当前接口的返回值：

所以先给它加上id：

代码：

最后我们在ts_show()函数中调用这个clear_ts_api即可：

然后刷新页面进行测试：

我们发现了一个bug:

就是这个第三方表格插件，虽然我们已经成功让其保留了一个空行，但是貌似这个空行显示的并不对：

连修改，删除按钮都没有显示出来。此时就算我们点击添加新参数的按钮，它的原理也只是复制第一行，就会出现多个不正确的行：

引起这个的问题是，这个第三方插件想要正确显示，不仅仅是html正确即可，它最后还是要运行一下它的js函数，才能对其进行正确显示化。

这个函数就是我们前面引入的这部分：

这俩部分之所以没有生效，是因我们在运行clear_ts_api()时，没有加入，而他们本来的运行时机是在整个接口库页面刚进入的时候就运行过了，之后我们若想强行更改tbody的内容tr td等，就必须重新运行这俩个函数，所以我们还要在clear_ts_api()函数的最后再运行一下这俩个函数即可：

现在让我们刷新页面再看看：发现效果已经正常显示了。

这里其实还有个坑，就是千万不要删除仅有的一行，否则就无法再添加新的正常的参数了，当然这种情况我们可以有很多办法避免，当然正常来用户真的需要切换到form-data和x-www...的时候，也确实是要传入参数了，那么就不会手欠的删掉第一行，而会直接编辑第一行或者先添加很多行。当然万一操作失误导致第一行被删除，那么只需要保存/取消，然后重新打开即可。