【测开中台教程-15】首页大搜功能后台接口实现

上节课我们做到基于类视图的接口，因为比较复杂，所以我们甚至单独创建了一个Home_views.py的文件来存储。

urls.py上节课我有个笔误，这里纠正下：不是.view() 而是.as_view()

开始今天内容：在这个Home_views.py文件中，创建好我们的类：CLS_home_search

如图：别忘了导入View库

然后我们直接写一个get函数，这样GET请求就会自动的调用这个get函数了。

接下来，就是我们的详细设计阶段，这个get函数作为入口主函数。它要进行那些步骤呢？而这些具体的步骤实现，都可以交给其他普通函数。

接下来，我们可以试着去给三个搜索函数进行首轮开发(这种重业务功能，一般情况下都是持续迭代和优化的，所以这里叫首轮)

先来看看QPT：公司全平台搜索结果的函数开发

首先，我们想拿到其他各种各样平台数据的最简单的办法就是，通过调用那些平台本身的搜索接口，然后把拿到的数据进行整理。如果个别平台并没有设置这种搜索接口，那么我们就只能想办法去调用一些获取类的get请求，比如这里有个跳板机内部平台，并没有直接提供搜索用的接口，那我们就可以去拿到它的一些列表获取接口，比如菜单，比如跳板机列表这种。

所有的接口回来的数据，虽然是五花八门的，但归根结底，都应该是列表。

所以我们可以把这些列表经过一些简单的整理后，直接拼接成一个大列表，作为res['QPT']的值即可。

但这里需要注意的是这个大列表中的每个元素，都应该是一个小字典。格式如下：

{"url":"","des":"","platform":""}

三个字段，超链接url 不必填。des描述，必填。platform所属平台 必填。

当然，具体每个平台的结果整理，还是要靠小伙伴们之后在公司实际情况具体分析了。我这里只提供了大方向思路哈~

实现脚本如下：

上图我简单解释下，这里因为要搜索的平台众多，所以我做了一个并发，并且阻塞的线程。这样QPT函数完全执行的时间就是最慢的那个平台的搜索时间。

通过platform_list来制定要搜的那些平台，并且这里要有上面提到搜索用的api接口。

在QPT_search函数中，具体处理搜索业务，这里就要具体情况具体写了。实在遇到业务处理复杂的，可以用if来处理。

结果我们保存成一个字典，并加入到self.QPT_res列表中，这个self.QPT_res列表就是公司内全平台最终搜索到的结果了~

本节课到此结束，下节课继续实现吧~