应用程序接口管理方法、装置、电子设备和存储介质与流程

1.本文涉及但不限于应用程序接口领域。


背景技术：

2.日常研发过程中，尤其是在互联网公司，微服务体系下，微服务数量非常多，一般上千甚至过万，如此之多的app，所产生的api数量可想而知。但日常工作中，所有的需求交互，研发测试，质量管控等都是基于api来完成的。所以如何更好的管理api是一个非常大的挑战。
3.开源api管理系统五花八门，各种各样，功能也参差不齐。现在业界有集中比较流行的api管理方式：
4.(1)swagger
5.首先必须知道app所在ip地址，只有app存活的时候才能查看，另外因为其对外暴露的地址可以自行更改，所以还需要找相关研发人员去确认地址。其次api信息无法保存、只能实时查阅。其次由于其很容易泄漏公司所有api信息，所以存在安全隐患，线上是禁用的。所以适用场景受限。
6.(2)wiki
7.虽然能够保存并勉强可以作为一种沟通交互的手段，但维护成本很高，需要人工去编写维护，且很难保证api信息的可靠性。此外也无法表达api的扩展信息(例如服务、分组、组织结构、版本等)，更不可能与其他系统集成。
8.(3)yapi
9.类似yapi的开源api管理系统已经非常多，且很多功能已经非常强大，不仅仅支持api本身的管理，并且还提供了在线测试以及mock等功能。但是绝大多数还是通过手动输入api信息，以及集成了swagger doc导入或者markdown文本导入的功能。维护本身还是基于人的。这就不可避免的导致了api信息本身的可靠性不高、失真等问题依然存在。在系统间集成的时候这种失真会导致很多功能不可靠或者不可用。
10.这些api管理方式主要存在以下几方面的缺点：
11.第一、这些管理方式很难和其他系统整合，并且为了和公司其他系统整合，需要做很多二次开发工作。
12.第二、大部分都是基于手动维护api信息或者按照特定格式导入api信息，管理成本高，并且api容易失真，很难保证和代码保持一致。
13.第三、无法自动维护api与服务、分组、组织结构等的关系、很难基于api进行质量管控，需求沟通，测试自动化等一系列提升研发效能的工作。无法发挥api信息的真正价值。


技术实现要素：

14.下文呈现各种示例性技术方案的概述。在以下概述中可以进行一些简化和省略，其意在突出并介绍各种示例性技术方案的一些方面，但不限制本发明的范围。将在后续部
分呈现足以允许本领域的普通技术人员产生并使用本发明概念的示例性技术方案的详细描述。
15.为解决上述技术问题，本发明的技术方案提供一种应用程序接口管理方法，包括：解析代码中的api协议文档，将解析的api协议文档与本地原先存在的api协议文档做比较，判断api信息是否有变化，如有变化则将更新的api信息写入本地原先存在的api协议文档形成最新的api协议文档；接收最新的api协议文档，解析该最新的api协议文档，并生成自定义api对象，将所述api自定义对象与数据库原先存在的api自定义对象做比较，判断是否有变化的信息，如果有，则在数据库中同步更新变化的信息。
16.可选地，所述自定义api对象除了包含api参数信息之外，还包括以下至少之一：app信息、分组、泳道、版本、组织结构、api逻辑分组、api业务分组，api集合。
17.可选地，所述将所述api自定义对象与数据库原先存在的api自定义对象做比较，包括：将所述自定义api对象的md5值与数据库里面的原来的自定义api对象的md5值作比较。所述数据库可以是远程的。
18.可选地，所述api协议文档是swagger文档或javadoc文档。
19.可选地，所述判断是否有变化的信息，是按照请求头、查询参数、restful参数，请求体分别进行判断。
20.本发明的另一个技术方案提供了一种应用程序接口管理装置，包括：插件模块，被配置为解析代码中的api协议文档，将解析的api协议文档与本地存在的api协议文档做比较，判断api信息是否有变化，如有变化则将更新的api信息写入本地存在的api协议文档形成最新的api协议文档；api管理模块，被配置为接收最新的api协议文档，解析该最新的api协议文档，并生成自定义api对象，将所述api自定义对象与数据库原先存在的api自定义对象做比较，判断是否有变化的信息，如果有，则在数据库中同步更新变化的信息。
21.可选地，所述解析代码中的api协议文档是自动的。
22.可选地，所述自定义api对象除了包含api参数信息之外，还包括以下至少之一：app信息、分组、泳道、版本、组织结构、api逻辑分组、api业务分组，api集合。
23.可选地，所述将所述api自定义对象与数据库原先存在的api自定义对象做比较，包括：将所述自定义api对象的md5值与数据库里面的原来的自定义api对象的md5值作比较。
24.可选地，所述api协议文档是swagger文档或javadoc文档。
25.可选地，所述判断是否有变化的信息，是按照请求头、查询参数、restful参数，请求体分别进行判断。
26.可选地，所述插件是maven插件。
27.本发明的另一个技术方案还提供了一种电子设备，包括：处理器、存储器以及存储在存储器上运行的计算机程序，所述处理器执行计算机程序时实现上述任一个技术方案所述的方法的步骤。
28.本发明的另一个技术方案还提供了一种计算机可读存储介质，所述计算机程序被处理器执行时实现上述任一个技术方案所述的方法的步骤。
29.本发明的技术方案主要具有以下几个发面的有益效果：
30.第一、本发明的技术方案容易和其他系统整合，不需要再做二次开发。
31.第一，本发明的技术方案采用插件的方式，可通过项目脚手架自动生成，不需要人工干预，管理成本低。
32.第三、本发明的技术方案自动维护api与服务、分组、组织结构等的关系。
33.第四、本发明的技术方案同时还做到了api文档的比较上传，大大降低了后端服务压力。
附图说明
34.为了更好地理解各种示例性实施例，可以参考附图，在附图中：
35.图1示出了实施例提供的应用程序接口管理方法的流程示意图；
36.图2示出了实施例提供的应用程序接口管理装置的结构示意图。
37.为了便于理解，相同的附图标记已用于指代具有基本上相同或类似结构和/或基本上相同或类似功能的元件。
具体实施方式
38.描述和图式示出了本发明的原理。因此，将了解，本领域的技术人员将能够设计各种布置，尽管本文中未明确地描述或示出所述布置，但所述布置体现本发明的原理且包括在本发明的范围内。此外，本文中所引述的所有例子主要旨在明确地用于教学目的，以帮助读者理解本发明的原理和由发明人提供的用以深化本领域的概念，并且所有例子应视为并不限于此类特定引述的例子和条件。另外，如本文中所使用，除非另有指示(例如，“或另外”或“或在替代方案中”)，否则术语“或”是指非排他性的或(即，和/或)。并且，本文中所描述的各种实施例不一定相互排斥，因为一些实施例可以与一个或多个其它实施例组合以形成新的实施例。
39.名词解释：
40.maven:是一种项目管理工具，它包含了一个项目对象模型(project object model)，一组标准集合，一个项目生命周期(project lifecycle)，一个依赖管理系统(dependency management system)，和用来运行定义在生命周期阶段(phase)中插件(plugin)目标(goal)的逻辑。当你使用maven的时候，你用一个明确定义的项目对象模型来描述你的项目，然后maven可以应用横切的逻辑，这些逻辑来自一组共享的(或者自定义的)插件。maven有一个生命周期，当运行mvn install的时候被调用。这条命令告诉maven执行一系列的有序的步骤，直到到达指定的生命周期。遍历生命周期旅途中的一个影响就是，maven运行了许多默认的插件目标，这些目标完成了像编译和创建一个jar文件这样的工作。
41.api:(application programming interface，应用程序接口)是一些预先定义的接口(如函数、http接口)，或指软件系统不同组成部分衔接的约定。用来提供应用程序与开发人员基于某软件或硬件得以访问的一组例程，而又无需访问源码，或理解内部工作机制的细节。
42.app:(application，应用服务)。应用服务是指为集中管理的组织中提供应用的部署、供应、管理以及对应用出租访问的契约性服务。
43.swagger:swagger是一个规范和完整的框架，用于生成、描述、调用和可视化
restful风格的web服务。作用：1.接口的文档在线自动生成。2.功能测试。
44.第一个实施例提供了一种应用程序接口管理方法，参见图1，所述方法包括：
45.s101：解析代码中的api协议文档，将解析的api协议文档与本地存在的api协议文档做比较，判断api信息是否有变化，如有变化则将更新的api信息写入本地存在的api协议文档形成最新的api协议文档。
46.所述api协议文档可以包括多种，可以是swagger文档、javadoc文档等，或者其他自定义协议。
47.具体地，先创建app(应用服务，指为集中管理的组织中提供应用的部署、供应、管理以及对应用出租访问的契约性服务),通过项目脚手架创建协议文档swaggrr、java doc等，下文以swagger文档举例说明。可将自定义的插件，例如maven插件(自定义forseti-maven-plugin)装入app中。编写相关api接口代码，编写swagger注释，然后执行插件编译(maven compile)命令。
48.执行插件编译命令(maven compile)，具体地，可先扫描目标路径下面@restcontroller类，读取swagger注释，遍历所有的类，组装成json格式文本，判断是否存在本地api协议文档forseti_doc.txt，如果存在则与本地api协议文档forseti_doc.txt内容比较，如果api协议文档forseti_doc.txt不存在，则创建并写入api信息，如果有变更且允许上传，则上传到文档服务器。
49.当执行编译命令后会自动解析代码里面的swagger文档(api描述)，程序会根据当前生成的文档与本地存在的api协议文档forseti_doc.txt(字符串比较)里面的内容做比较(例如api参数是否有变化、是否增减api等)，如果不一致，则说明api有变化，会自动上传到后端api文档管理服务。并将最新的api信息写入本地存在api协议文档forseti_doc.txt，形成最新的api协议文档。如果一致说明没有变化则不上传。完成api信息到后端api文档管理服务的同步。
50.s102：接收最新的api协议文档，解析该最新的api协议文档，并生成自定义api对象，将所述api自定义对象与数据库原先存在的api自定义对象做比较，判断是否有变化的信息，如果有，则在数据库中同步更新变化的信息。
51.具体地，在api信息同步到后端api文档管理服务之后，由api管理模块解析swagger文档，转换生成自定义的api对象，所述自定义api对象除了包含基础的api参数信息之外，还包括app信息、分组、泳道、版本、组织结构、api逻辑分组、api业务分组，api集合等信息。
52.然后根据条件从数据库查询相关的自定义api对象，如果数据库中不存在相关自定义api对象，则创建并写入新生成地自定义api对象，如果数据库中存在相关自定义api对象，则将新的自定义对象与数据库原先存在的api自定义对象做比较，如果有变化，则在数据库中同步更新参数信息。
53.可选地，对于有变更的api同步发送变更事件到相关负责人以及关注变更的人员。
54.可选地，程序根据解析出的自定义api对象与数据库里面的自定义api对象做比较时，具体可采用md5 hash算法，即每个api有唯一的md5标识，md5值生成算法：api 参数以及参数所在层级拼接成字符串后进行md5计算得出。将解析出的自定义api对象的md5值与数据库里面的原来的自定义api对象的md5值作比较，可以得知api对象的哪些参数信息发生
变化。
55.可选地，如果有变化，可按照请求头、查询参数、restful参数，请求体等分别进行判断，并同步写入保存到不同的数据表中。
56.可选地，同步完api信息后，会根据上传过来的其他数据(分组、app id等)以及从cmda系统里面同步过来的app与组织结构的关系等数据，绑定api到上述各个维度。
57.实施例的方案容易和其他系统整合，不需要再做二次开发。
58.实施例的方案采用插件的方式，可通过项目脚手架自动生成，不需要人工干预，管理成本低。
59.实施例的方案自动维护api与服务、分组、组织结构等的关系。
60.实施例的方案同时还做到了api文档的比较上传，大大降低了后端服务压力。
61.第二个实施例提供了一种应用程序接口管理装置200，参见图2，包括：插件模块201和api管理模块202。
62.插件模块201，自动解析代码中的api协议文档，将解析的api协议文档与本地存在的api协议文档做比较，判断api信息是否有变化，如有变化则将更新的api信息写入本地存在的api协议文档形成最新的api协议文档，并上传到api管理模块；
63.所述api协议文档可以包括多种，可以是swagger文档、javadoc文档等，或者其他自定义协议。
64.具体地，先创建app(应用服务，指为集中管理的组织中提供应用的部署、供应、管理以及对应用出租访问的契约性服务),通过项目脚手架创建协议文档swaggrr、java doc等，下文以swagger文档举例说明。可将自定义的插件，例如maven插件(自定义forseti-maven-plugin)装入app中。编写相关api接口代码，编写swagger注释(包括api描述)，然后执行插件编译(maven compile)命令。
65.插件模块201执行插件编译命令(maven compile)，具体地，可先扫描目标路径下面@restcontroller类，读取swagger注释，遍历所有的类，组装成json格式文本，判断是否存在本地api协议文档forseti_doc.txt，如果存在则与本地api协议文档forseti_doc.txt内容比较，如果api协议文档forseti_doc.txt不存在，则创建并写入api信息，如果有变更且允许上传，则上传到文档服务器。
66.插件模块201执行编译命令后会自动解析代码里面的swagger文档(api描述)，插件模块201会根据当前生成的文档与本地存在的api协议文档forseti_doc.txt(字符串比较)里面的内容做比较(例如api参数是否有变化、是否增减api等)，如果不一致，则说明api有变化，会自动上传到后端api管理模块202。并将最新的api信息写入本地存在api协议文档forseti_doc.txt，形成最新的api协议文档。如果一致说明没有变化则不上传。完成api信息到后端api管理模块202的同步。
67.api管理模块202，接收最新的api协议文档，根据该最新的api协议文档解析成自定义api信息，并用md5算法生成md5值，用该md5值与数据库中原先存在的自定义api信息的md5值做比较，判断具体哪些自定义api信息发生变化，并将更新的自定义api信息存入到数据库中。
68.具体地，在api信息同步到后端api管理模块202之后，由api管理模块202解析swagger文档，转换生成自定义的api对象，所述自定义api对象除了包含基础的api参数信
息之外，还包括app信息、分组、泳道、版本、组织结构、api逻辑分组、api业务分组，api集合等信息。
69.然后根据条件从数据库查询相关的自定义api对象，如果数据库中不存在相关自定义api对象，则创建并写入新生成地自定义api对象，如果数据库中存在相关自定义api对象，则将新的自定义对象与数据库原先存在的api自定义对象做比较，如果有变化，则在数据库中同步更新参数信息，
70.可选地，对于有变更的api同步发送变更事件到相关负责人以及关注变更的人员。
71.可选地，程序根据解析出的自定义api对象与数据库里面的自定义api对象做比较时，具体可采用md5 hash算法，即每个api有唯一的md5标识，md5值生成算法：api 参数以及参数所在层级拼接成字符串后进行md5计算得出。将解析出的自定义api对象的md5值与数据库里面的原来的自定义api对象的md5值作比较，可以得知api对象的哪些参数信息发生变化。
72.可选地，如果有变化，可按照请求头、查询参数、restful参数，请求体等分别进行判断，并同步写入保存到不同的数据表中。
73.可选地，同步完api信息后，会根据上传过来的其他数据(分组、app id等)以及从cmda系统里面同步过来的app与组织结构的关系等数据，绑定api到上述各个维度。
74.第三个实施例还提供了一种电子设备，包括：处理器、存储器以及存储在存储器上运行的计算机程序，所述处理器执行计算机程序时实现上述任一实施例方法的步骤，例如步骤s101至s102，或者所述处理器执行所述计算机程序时实现上述各实施例中各模块/单元的功能，例如单元201至202的功能。所述计算机程序可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器中，并由所述处理器执行。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序在所述电子设备中的执行过程。
75.所述电子设备可以是智能手机等移动终端，或者是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述电子设备可包括，但不仅限于，处理器、存储器，可以包括更多或更少的部件，或者组合某些部件，例如所述电子设备还可以包括输入输出设备、网络接入设备、总线等。所称处理器可以是中央处理单元(central processing unit，cpu)，还可以是其他通用处理器、数字消息队列的管理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现成可编程门阵列(field programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。所述存储器可以是所述电子设备的内部存储单元，例如电子设备的硬盘或内存。所述存储器也可以是所述电子设备的外部存储设备，例如所述电子设备上配备的插接式硬盘，智能存储卡(smart media card，smc)，安全数字(secure digital，sd)卡，闪存卡(flash card)等。进一步地，所述存储器还可以既包括所述电子设备的内部存储单元也包括外部存储设备。
76.第五个实施例还提供了一种计算机可读存储介质，所述计算机程序被处理器执行时实现上述任一实施例方法的步骤。
77.在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个
单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。
78.所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本技术的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
79.在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
80.在本技术所提供的实施例中，应该理解到，所揭露的系统、电子设备和方法，可以通过其它的方式实现。例如，以上所描述的系统、电子设备实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，系统或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
81.以上所述实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改
或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的精神和范围，均应包含在本技术的保护范围之内。