CN108664316A - 一种获取api的接口信息的方法和装置 - Google Patents

Abstract

本发明公开了一种获取API的接口信息的方法和装置，属于API集成对接领域。所述方法包括：服务器先获取目标API的数据流，然后再根据预设的接口信息和数据流的字段的对应关系，在目标API的数据流中特定的字段处提取目标API的接口信息。采用本发明，可以提高获取的API的接口信息的准确性，从而可以提高API对接的成功率。

Description

一种获取API的接口信息的方法和装置

技术领域

本发明涉及API集成对接领域，特别涉及一种获取API的接口信息的方法和装置。

背景技术

随着计算机技术的不断发展，应用程序编程接口(Application ProgrammingInterface，API)也得到了快速的开发，某个厂家可以将其产品内部的一些功能通过API的形式提供给外界使用，这样，其它厂家在无需分析了解上述功能的代码运行逻辑的前提下，就可以通过API调用上述产品中的部分功能。

在一个复杂的信息技术(Information Technology，IT)/通信技术(Communication Technology，CT)系统中，存在多种厂家提供的API，IT/CT系统的技术人员需要针对每个API的开发出相应的对接程序，然后通过对接程序与厂家提供的API进行对接，从而将不同厂家的API集成至IT/CT系统中。在集成对接的过程中，首先需要IT/CT系统的调研人员先对各个待集成的API的接口进行调研，即通过现场测试、与厂家沟通确认、分析工作日志等方式来确定API的接口信息。之后，程序开发人员可以根据上述API的接口信息来开发调试该API的对接程序。

在实现本发明的过程中，发明人发现现有技术至少存在以下问题：

由于各个厂家采用不同的协议描述API，每个调研人员的个人能力、经验也不同，这样，在调研人员对API的接口进行调研时，很难保证获取到的API的接口信息的准确度，而如果API的接口信息出现错误，则开发出来的对接程序很有可能无法与API进行对接，因此API对接的成功率较低。

发明内容

为了解决上述处理存在的问题，本发明实施例提供了一种获取API的接口信息的方法和装置。所述技术方案如下：

第一方面，提供了一种获取API的接口信息的方法，所述方法包括：

服务器可以先获取目标API的数据流，然后再根据预设的接口信息和数据流的字段的对应关系，在目标API的数据流中特定的字段处提取目标API的接口信息。

本发明实施例所示的方案，在获取目标API的接口信息的过程中，可以由服务器来执行相应的API调研任务，并直接在目标API的数据流中提取接口信息，相比人工调研的方式，更加方便快捷，也可以有效避免人工调研中的人为错误或误差，可以提高获取的接口信息的准确度。

在一种可能的实现方式中，服务器可以通过安装在目标API所属的设备上的抓包代理程序来获取该设备上的API的数据流，并根据目标API的地址信息，在获取到的多个数据流中筛选出目标API的数据流。

本发明实施例所示的方案，一个设备上可以存在多个API，同时服务器可以并行多个API的调研任务，则服务器获取到的数据流可能属于多个设备上的多个API，故而服务器需要根据目标API的地址信息，在大量数据流中查找携带有相同地址信息的数据流，即为目标API的数据流。

在一种可能的实现方式中，技术人员可以在服务器上进行目标API的调研任务的配置处理，或者可以在其它设备上进行配置，并将配置结果发送给服务器，这样，服务器则可以接收到目标API的接口调研指令，然后获取该接口调研指令中携带的目标API的地址信息。进而，服务器可以向目标API所属的设备发送抓包代理程序，以使上述设备安装抓包代理程序。

本发明实施例所示的方案，服务器可以接收目标API的接口调研指令，并从中至少获取到目标API的地址信息，从而服务器可以获知目标API所属的设备的地址信息，然后将抓包代理程序发送给该设备。该设备安装抓包代理程序后，服务器则可以直接通过抓包代理程序抓取目标API的数据流。

在一种可能的实现方式中，在从数据流中提取了目标API的接口信息后，可以采用预设的API元数据模板记录上述接口信息，从而可以生成目标API的API元数据。

其中，API元数据模板为用于描述不同API的接口信息的标准API描述模板。

本发明实施例所示的方案，采用预设的API的接口描述模板，可以生成统一格式的标准API描述模板，即API元数据模板，这样，不管是什么厂家、什么协议，都可以采用一套标准格式的API元数据模板来描述它以生成相应的API元数据，进一步的，技术人员开发对接程序时，可以直接导入上述API元数据，即可生成API的骨架代码，故而技术人员只需要关注业务逻辑本身的编写，而不用在分析API的协议类型、接口参数等信息上耗费大量精力，从而可以提升API对接的效率。

在一种可能的实现方式中，在获取到目标API的接口信息后，服务器还可以继续通过抓包代理程序获取目标API的数据流，然后根据获取到的数据流对目标API的接口信息进行修正处理。

本发明实施例所示的方案，根据某一个或几个数据流提取的API的接口信息可能会无法完整准确地描述各种业务场景下的API，不具备代表性和普适性，故而在获取到接口信息之后，继续获取API的数据流，并根据API的数据流对接口信息进行修正，从而可以提高获取到的API的接口信息的准确性和完整性。

在一种可能的实现方式中，服务器获取的API的接口信息中包括API协议描述信息，API策略信息和API资源信息的至少一项。

本发明实施例所示的方案，通过API协议描述信息、API策略信息和API资源信息三种信息，可以清晰，无歧义、完整的描述一个API，故而可以保证API的接口信息完整度和准确度，进而可以保证后续处理的顺利进行。

在一种可能的实现方式中，服务器可以先确定目标API的协议类型，然后根据该协议类型对应的协议解析模板，对目标API的数据流进行解析，获取API的协议描述文件，之后，再基于预设的接口信息和数据流的字段的对应关系，在所述目标API的数据流和API协议描述文件中提取所述目标API的接口信息。

本发明是实施例所示的方案，服务器由目标API的协议类型对应协议解析模板，对目标API的数据流进行解析得到API协议描述信息，然后再在数据流的指定字段中提取出API策略信息和API资源信息。

第二方面，提供了一种服务器，所述服务器包括收发器、处理器和存储器，所述处理器通过执行指令来实现上述第一方面所提供的获取API的接口信息的方法。

第三方面，提供了一种获取API的接口信息的装置，该装置包括至少一个模块，该至少一个模块用于实现上述第一方面所提供的获取API的接口信息的方法。

第四方面，提供了一种包含指令的计算机程序产品，当其在服务器上运行时，使得服务器执行上述第一方面所提供的获取API的接口信息的方法。

本发明实施例提供的技术方案带来的有益效果是：

本发明实施例中，在获取目标API的接口信息时，可以由服务器通过抓包代理程序对目标API的数据流进行抓取，然后服务器可以根据预先存储的接口信息和数据流的字段的对应关系，在特定的数据流的字段中提取相应的目标API的接口信息。这样，在获取API的接口信息时，服务器根据API的数据流自动获取API的接口信息，可以有效避免人工对API的接口调研时，由于调研人员能力经验不足的问题而出现的错误，获取到的API的接口信息准确性较高，从而可以提高API对接的成功率。

附图说明

图1是本发明实施例提供的一种服务器的结构示意图；

图2是本发明实施例提供的一种获取API的接口信息的方法流程图；

图3是本发明实施例提供的一种API的接口信息的组成示意图；

图4是本发明实施例提供的一种获取API的接口信息的流程示意图；

图5是本发明实施例提供的一种获取API的接口信息的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

如本申请所使用的，术语“组件”、“模块”、“系统”等等旨在指代计算机相关实体，该计算机相关实体可以是硬件、固件、硬件和软件的结合、软件或者运行中的软件。例如，组件可以是，但不限于是：在处理器上运行的处理、处理器、对象、可执行文件、执行中的线程、程序和/或计算机。作为示例，在计算设备上运行的应用和该计算设备都可以是组件。一个或多个组件可以存在于执行中的过程和/或线程中，并且组件可以位于一个计算机中以及/或者分布在两个或更多个计算机之间。此外，这些组件能够从在其上具有各种数据结构的各种计算机可读介质中执行。这些组件可以通过诸如根据具有一个或多个数据分组(例如，来自一个组件的数据，该组件与本地系统、分布式系统中的另一个组件进行交互和/或以信号的方式通过诸如互联网之类的网络与其它系统进行交互)的信号，以本地和/或远程过程的方式进行通信。

本发明实施例提供了一种获取API的接口信息的方法，该方法的执行主体为服务器。其中，服务器可以是IT/CT系统管理侧的服务器，用于获取各个厂家API的接口信息，并辅助技术人员针对每个API开发相应的对接程序。服务器可以包括收发器110、处理器120、存储器130，收发器110和存储器130可以分别与处理器120连接，如图1所示，图中的连接方式只是示意性的一种，该网络设备还可以是类似通用计算机架构中的，处理器、存储器、收发器通过总线进行连接，本发明实施例不做限定。收发器110可以用于接收或发送消息或数据，收发器110可以包括但不限于至少一个放大器、调谐器、一个或多个振荡器、耦合器、LNA(Low Noise Amplifier，低噪声放大器)、双工器等，存储器130可以用于存储控制带宽过程中本地产生或客户端发送的数据。处理器120可以是服务器的控制中心，利用各种接口和线路连接整个服务器的各个部分，如收发器110和存储器130等。可选的，处理器可以包括一个或多个处理单元；可选的，处理器120可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统，调制解调处理器主要处理无线通信。处理器120还可以是数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件等。处理器120可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(NetworkProcessor，简称NP)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其他可编程逻辑器件等。具体地，程序可以包括程序代码，程序代码包括计算机操作指令。

本申请将围绕可包括多个设备、组件、模块等的系统来呈现各个方面、实施例或特征。应当理解和明白的是，各个系统可以包括另外的设备、组件、模块等，并且/或者可以并不包括结合附图讨论的所有设备、组件、模块等。此外，还可以使用这些方案的组合。

另外，在本申请实施例中，“示例的”一词用于表示作例子、例证或说明。本申请中被描述为“示例”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用示例的一词旨在以具体方式呈现概念。

本申请实施例描述的网络架构以及业务场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着网络架构的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

下面将结合具体实施方式，对图2所示的处理流程进行详细的说明，内容可以如下：

步骤201，获取目标API的数据流。

其中，所述目标API的数据流可以是API的输入数据流(如业务请求消息)和/或输出数据流(如业务应答消息)。

在实施中，当IT/CT系统的技术人员需要针对某个厂家的API(即目标API)开发相应的对接程序时，可以先获取目标API的数据流，具体的，可以获取经过目标API的接口的消息，如API客户端发送至API服务端的业务请求消息、API服务端反馈回API客户端的业务应答消息等。

步骤202，根据预设的接口信息和数据流的字段的对应关系，在所述目标API的数据流中确定所述目标API的接口信息。

其中，API的接口信息可以是用于描述API的接口的信息，其中可以包括API的接口协议类型和版本，请求参数和应答参数的数据类型、API的接口路由策略、流控策略等。

在实施中，技术人员可以预先对大量不同的API的数据流进行分析，然后人工在数据流中提取API的接口信息，并确定出各接口信息所在的数据流的字段，从而可以生成接口信息和数据流的字段的对应关系，然后将该对应关系存储在服务器中。上述对应关系具体可以参考表1所示。

表1

这样，在获取到目标API的数据流后，服务器可以基于上述接口信息和数据流的字段的对应关系，先找到每个接口信息所在的数据流的字段，然后在相应的数据流的字段中提取出目标API的接口信息。

可选的，服务器可以将获取到的API的接口信息以固定模板的形式提供给技术人员，相应的，步骤202之后的处理可以如下：根据预设的API元数据模板和所述目标API的接口信息，生成所述目标API的API元数据。

其中，API元数据模板为用于描述不同API的接口信息的标准API描述模板

在实施中，技术人员可以预先设计出便于开发对接程序的标准API描述模板(即API元数据模板)，这样，服务器在获取到目标API的接口信息后，可以基于上述API元数据模板，生成目标API的API元数据。例如，抓包代理程序抓取的目标API对应的请求消息如下：

应答消息如下：

则根据步骤202中的对应关系，可以在相应字段提取目标API的接口信息，并按照预设的API元数据模板生成目标API的API元数据：

这样，不管是什么厂家、什么协议，都可以采用一套标准格式的API元数据来描述它，进一步的，技术人员开发对接程序时，可以直接导入上述API元数据，即可生成API的骨架代码，故而技术人员只需要关注业务逻辑本身的编写，而不用在分析API的协议类型、接口参数等信息上耗费大量精力，从而可以提升API对接的效率。

可选的，服务器可以获取到大量API的数据流，然后从这些数据流中筛选出目标API的数据流，相应的，步骤201的处理可以如下：通过多个抓包代理程序获取多个API的数据流，所述多个抓包代理程序安装在所述多个API所属的设备上；根据所述目标API的地址信息，在所述多个API的数据流中筛选所述目标API的数据流。

其中，抓包代理程序是用于抓取指定端口或者地址的数据流，并将抓取到的数据流通过流式传输的方式反馈至服务器的执行程序。

在实施中，为了提升API的调研效率，服务器支持对多个API接口进行并行调研，可以创建多个API的调研任务，在后台并发执行，即同时进行多个API的接口信息的获取处理，而针对每个调研任务，均有相应的抓包代理程序进行API的数据流的抓取处理。这样，服务器则可以通过多个安装在API所在设备上的抓包代理程序来获取这些API的数据流。需要说明的是，一个设备上可以存在多个API，安装在该设备上的抓包代理程序可以获取到该设备上所有API的数据流。之后，服务器可以汇总多个API的数据流，然后按照数据流中包含的API的地址信息对数据流进行分类，同类的数据流属于同一个API。另外，考虑到不同的设备上可以部署同种API，则可以将同种设备的API的数据流划分为一类。从而服务器可以根据目标API的地址信息，在汇总后的数据流中筛选出目标API的数据流。

进一步的，在筛选出目标API的数据流之后，服务器还可以对目标API的数据流进行过滤、剔重处理，即去除掉其中无效、重复的数据流。其中，无效的数据流可以是信息缺失、不完整的数据流，例如，数据流首包中记录了该数据流的大小为3000K，而实际接收到的数据流的大小仅有2000K，则该数据流即为无效数据流；重复的数据流可以是格式、标题相同的数据流，例如不同用户对同一API中同一功能的请求消息，即可以认为是重复的数据流。

可选的，服务器在获取目标API的数据流之前，需要先部署相应的抓包代理，相应的，步骤201之前还可以有以下处理：获取目标API的接口调研指令，所述接口调研指令中携带有所述目标API的地址信息；根据所述目标API的地址信息向所述目标API所属的设备发送抓包代理程序，以使所述设备安装所述抓包代理程序。

在实施中，当技术人员需要获取某个API的接口信息时，可以打开服务器中已安装的API调研程序，这时，服务器上可以显示有API调研管理界面，从而技术人员可以在该界面内配置API调研任务，具体的，技术人员可以对调研的规则进行具体的配置，例如数据流的采样策略是随机采样还是周期性采样，API调研的执行时刻是延迟执行还是立即执行，同时还可以设置需要调研的API对应的协议类型、地址信息等。这样，服务器则可以接收到相应的目标API的接口调研指令。或者，技术人员还可以在其它设备上进行API调研任务的配置处理，然后该设备可以将技术人员配置的内容以接口调研指令的形式发送给服务器。上述接口调研指令中至少携带目标API的地址信息，同时还可以携带技术人员设置的调研规则，如果其中未携带调研规则，服务器则可以采用默认的调研规则。

之后，服务器可以根据获取到目标API的地址信息确定目标API所属设备的地址信息，从而向该设备发送抓包代理程序，以使该设备安装抓包代理程序。其中，抓包代理程序部署在需要调研的第三方设备(即目标API所属的设备)上，用于对指定的API接口进行抓包：具体抓包方式可以采用代理或者网卡抓包的方式，捕获指定IP、端口的HTTP/HTTPS承载的SOAP、REST或HTTP报文等，并将捕获的数据流以二进制、实时流式传输或者周期性传输的方式推送给服务器。抓包代理程序和第三方设备之间可以使用PF_PACKET socket接口进行数据流的交互。

需要说明的是，服务器可以支持多个API调研任务同时在后台执行，每个API调研任务对应一个API，从而服务器可以根据配置的API的地址信息，采用并行分发的方式将抓包代理程序推送到指定的API所属的设备并安装抓包代理程序。抓包代理程序根据配置的抓包规则和端口等，按照指定的条件进行抓包。

可选的，在获取到目标API的接口信息后，还可以继续采集目标API的数据流，然后基于这些数据流对已获取的接口信息进行修正，相应的，步骤202之后还可以有如下处理：获取所述目标API的数据流，根据所述目标API的数据流对所述目标API的接口信息进行修正处理。

在实施中，服务器在根据目标API的数据流获取目标API的接口信息时，可能至少会存在如下问题：1.某个数据流与特定的业务场景相关，可能无法完整、准确描述某个API的接口，例如条件组合式的可选字段，当A字段值为V时，则某个可选字段(B字段)称为必选字段，在这种业务场景下成为必选字段；2.数据流中未包含所有异常场景，这样，则无法获取到API异常时相应的错误应答方式等信息。

故而，为了解决上述问题，服务器可以在获取到目标API的接口信息后，继续采用随机或者周期性采样的方式获取目标API的数据流(即对目标API进行抓包)，并将抓包的周期拉长到小时级，以保障抓包得到的数据流具备业务代表性和完整性。之后，服务器可以根据再次抓包得到目标API的数据流，对已获取的目标API的接口信息(可称为原始API元数据)中的消息结构、参数名称/类型/范围/必(可)选等信息不断进行自动修正、校准，具体的，修正策略可以如下：

1.如果原始API元数据中缺失某些可选字段，则增加该字段相应的信息；

2.如果原始API元数据中某些记录为必选的字段，从后续数据流中成为可选字段，则将其记录为可选字段；

3.如果原始API元数据的基础字段类型的定义值与后续数据流中的信息不符，存在冲突，则将基础字段类型修正为字符串类型，并记录在告警日志中，为后续人工仲裁提供依据。

4.如果原始API元数据中缺少某些信息，则进行相关信息的增加；

5.如果原始API元数据中记录的信息与后续数据流中的信息存在冲突的，则不修正，并将两种冲突的信息记录在告警日志中，等待后续人工仲裁。

可选的，目标API的接口信息包括API协议描述信息，API策略信息和API资源信息中的至少一项。

在实施中，首先，要想清晰、无歧义、完整的描述一个API，通常需要包含如下三部分信息：1.API协议描述信息，包括API使用什么协议、API的请求和应答数据结构、以及API的错误码等信息；2.API资源信息：包括API关联的资源信息、部署的环境信息、API提供者信息等；3.API策略信息：包括API的SLA策略(包括流控、优先级调度等)、路由策略等。故而目标API的接口信息中包括上述三种信息，则可以较为完整地描述一个API。进一步的，可以利用YAML或者JSON的方式来描述与具体的协议无关的信息，如API资源信息、API策略信息；而对于API协议描述信息，则可以采用目前业界已有的标准直接生成。最后，可以将上述两者结合起来，组合成完整的API元数据，同时还可以包括一些API扩展信息，具体可以如图3所示，其中，API元数据可以支持各种协议，以及已有的标准规范，并且完整性较好，能够包含API元数据三要素，同时可扩展性较好。具体实现可以参考如下：

其中，API协议描述信息可以由“type”字段和“metadata”字段组合说明，“type”字段用来说明API的接口协议类型，“metadata”字段用来导入具体描述该API的协议规范文件。例如“type”为“soap”，则使用“*.wsdl”来描述API的协议参数、数据结构和接口等。API资源信息可以由“services”字段来说明，具体用于描述API对应的服务提供者信息，而对于复杂的API，会关联多个服务提供者，因此1个API可以支持对应多个服务提供者，即包含多个“services”字段。API策略信息可以由“policies”字段进行说明，包括路由策略、流控策略、超时控制、SLA策略等。API扩展信息中包括协议类型扩展信息、API策略扩展信息等，可以通过与handlers组合使用，以API路由策略扩展为例，假如新增一种基于调用时延的负载均衡策略，则配置片段可以如下：

其中，“mechanism”为扩展的路由策略的名称，“handlers”中则指定扩展的路由策略的实现者。

可选的，步骤202中获取目标API的接口信息可以具体如下：确定所述目标API的协议类型，根据预先存储的所述目标API的协议类型对应的协议解析模板，将所述目标API的数据流转换成所述目标API的API协议描述文件，其中，所述API协议描述文件中记录有所述API协议描述信息；基于预设的接口信息和数据流的字段的对应关系，在所述目标API的数据流和API协议描述文件中提取所述目标API的接口信息。

在实施中，服务器侧的技术人员可以预先针对每种协议类型的数据流，设定具体的协议解析模板，用来生成相应的协议描述文件。这样，服务器在获取到目标API的数据流之后，可以先确定目标API的协议类型，然后利用该协议类型对应的协议解析模板，由抓包的数据流流反向生成描述目标API的接口协议信息的规范文件(即API协议描述文件)，例如SOAP协议的WSDL。具体的，根据协议类型不同，可以有两种不同的生成方式：

1.对于通用的协议类型，可以借助开源的协议解析框架(即协议解析模板)，将数据流转换成API协议描述文件，例如SOAP协议的CXF框架，Restful协议的Swagger框架。

2.对于私有的协议类型，通常没有开源的协议解析框架，则需要技术人员预先人工分析该协议，自主设计相应的协议解析模板，从而可以将数据流解析成相应的API协议描述文件，例如Google gRPC框架的IDL。

在获取到目标API的数据流并生成相应的协议描述文件之后，服务器可以基于预设的接口信息和数据流的字段的对应关系，在所述目标API的数据流和API协议描述文件中提取API策略信息和API资源信息。从而完成目标API的接口信息的获取处理。对于一些无法提取到的接口信息，例如超时时间等，属于可选的API策略信息，故而可以先记录为空。

基于上述描述，本实施例还提供了一种获取API的接口信息的详细流程，如图4所示：

步骤401，配置目标API调研任务，设置调研规则。

步骤402，执行API调研任务，向目标API所属的设备推送抓包代理程序。

步骤403，自动向抓包代理程序下发启动抓包指令。

步骤404，通过抓包代理程序获取目标API的数据流。

步骤405，对数据流以API的粒度进行分类管理。

步骤406，解析目标API的数据流，提取接口信息，生成原始API元数据。

步骤407，根据目标API的数据流，对原始API元数据进行修正。

步骤408，目标API调研任务完成，记录日志并展示调研任务的执行状态。

步骤409，下发停止抓包指令，以使目标API所属设备卸载抓包代理程序。

步骤410，显示或导出API元数据。

需要说明的是，本实施例中的具体处理可以由单一设备(即服务器)来完成，也可以由多个设备(即服务器组)协同完成，每个设备负责不同的处理步骤，此处不再进行具体说明。

本发明实施例中，在获取目标API的接口信息时，可以由服务器通过抓包代理程序对目标API的数据流进行抓取，然后服务器可以根据预先存储的接口信息和数据流的字段的对应关系，在特定的数据流的字段中提取相应的目标API的接口信息。这样，在获取API的接口信息时，服务器根据API的数据流自动获取API的接口信息，可以有效避免人工对API的接口调研时，由于调研人员能力经验不足的问题而出现的错误，获取到的API的接口信息准确性较高，从而可以提高API对接的成功率。

图5是本发明实施例提供的获取API的接口信息的装置的结构图。该装置可以通过软件、硬件或者两者的结合实现成为装置中的部分或者全部。本发明实施例提供的获取API的接口信息的装置可以实现本发明实施例图2所述的流程，该装置包括：第一获取模块501、第二获取模块502、第三获取模块503、发送模块504、生成模块505和修正模块506，其中：

第一获取模块501，用于获取目标API的数据流；

第二获取模块502，用于根据预设的接口信息和数据流的字段的对应关系，在所述目标API的数据流中获取所述目标API的接口信息。

可选的，所述第一获取模块501，具体用于：

通过多个抓包代理程序获取多个API的数据流，所述多个抓包代理程序安装在所述多个API所属的设备上；

根据所述目标API的地址信息，在所述多个API的数据流中筛选所述目标API的数据流。

可选的，所述装置还包括：

第三获取模块503，用于获取目标API的接口调研指令，所述接口调研指令中携带有所述目标API的地址信息；

发送模块504，用于根据所述目标API的地址信息向所述目标API所属的设备发送抓包代理程序，以使所述设备安装所述抓包代理程序。

可选的，所述装置还包括：

生成模块505，用于在获取所述目标API的接口信息之后，根据预设的API元数据模板和所述目标API的接口信息，生成所述目标API的API元数据，其中，所述API元数据模板为用于描述不同API的接口信息的标准API描述模板。

可选的，所述装置还包括：

修正模块506，用于在获取所述目标API的接口信息之后，获取所述目标API的数据流，根据所述目标API的数据流对所述目标API的接口信息进行修正处理。

可选的，所述目标API的接口信息包括API协议描述信息，API策略信息和API资源信息中的至少一项。

可选的，所述第二获取模块502，具体用于：

确定所述目标API的协议类型，根据预先存储的所述目标API的协议类型对应的协议解析模板，将所述目标API的数据流转换成所述目标API的API协议描述文件，其中，所述API协议描述文件中记录有所述API协议描述信息；

基于预设的接口信息和数据流的字段的对应关系，在所述目标API的数据流和API协议描述文件中提取所述目标API的接口信息。

本发明实施例中，在获取目标API的接口信息时，可以由服务器通过抓包代理程序对目标API的数据流进行抓取，然后服务器可以根据预先存储的接口信息和数据流的字段的对应关系，在特定的数据流的字段中提取相应的目标API的接口信息。这样，在获取API的接口信息时，服务器根据API的数据流自动获取API的接口信息，可以有效避免人工对API的接口调研时，由于调研人员能力经验不足的问题而出现的错误，获取到的API的接口信息准确性较高，从而可以提高API对接的成功率。

需要说明的是：上述实施例提供的获取API的接口信息的装置在获取API的接口信息时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的获取API的接口信息的装置与获取API的接口信息的方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现，当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令，在服务器上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴光缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是基站能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(如软盘、硬盘和磁带等)，也可以是光介质(如数字视盘(Digital VideoDisk，DVD)等)，或者半导体介质(如固态硬盘等)。

以上所述仅为本发明的一种可行的实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (22)

1.一种获取API的接口信息的方法，其特征在于，所述方法包括：

获取目标应用程序编程接口API的数据流；

根据预设的接口信息和数据流的字段的对应关系，在所述目标API的数据流中获取所述目标API的接口信息。

2.根据权利要求1所述的方法，其特征在于，所述获取目标API的数据流，包括：

通过多个抓包代理程序获取多个API的数据流，所述多个抓包代理程序安装在所述多个API所属的设备上；

根据所述目标API的地址信息，在所述多个API的数据流中筛选所述目标API的数据流。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

获取目标API的接口调研指令，所述接口调研指令中携带有所述目标API的地址信息；

根据所述目标API的地址信息向所述目标API所属的设备发送抓包代理程序，以使所述设备安装所述抓包代理程序。

4.根据权利要求1所述的方法，其特征在于，所述获取所述目标API的接口信息之后，还包括：

根据预设的API元数据模板和所述目标API的接口信息，生成所述目标API的API元数据，其中，所述API元数据模板为用于描述不同API的接口信息的标准API描述模板。

5.根据权利要求1所述的方法，其特征在于，所述获取所述目标API的接口信息之后，还包括：

获取所述目标API的数据流，根据所述目标API的数据流对所述目标API的接口信息进行修正处理。

6.根据权利要求1-5任一项所述的方法，其特征在于，所述目标API的接口信息包括API协议描述信息，API策略信息和API资源信息中的至少一项。

7.根据权利要求6所述的方法，其特征在于，所述根据预设的接口信息和数据流的字段的对应关系，在所述目标API的数据流中确定所述目标API的接口信息，包括：

确定所述目标API的协议类型，根据预先存储的所述目标API的协议类型对应的协议解析模板，将所述目标API的数据流转换成所述目标API的API协议描述文件，其中，所述API协议描述文件中记录有所述API协议描述信息；

基于预设的接口信息和数据流的字段的对应关系，在所述目标API的数据流和API协议描述文件中提取所述目标API的接口信息。

8.一种服务器，其特征在于，所述服务器包括收发器、处理器和存储器，其中：

所述收发器，用于获取目标API的数据流；

所述处理器，用于根据所述存储器中预设的接口信息和数据流的字段的对应关系，在所述目标API的数据流中确定所述目标API的接口信息。

9.根据权利要求8所述的服务器，其特征在于，所述收发器，具体用于：

通过多个抓包代理程序获取多个API的数据流，所述多个抓包代理程序安装在所述多个API所属的设备上；

所述处理器，还用于根据所述目标API的地址信息，在所述多个API的数据流中筛选所述目标API的数据流。

10.根据权利要求9所述的服务器，其特征在于，所述收发器，还用于：

获取目标API的接口调研指令，所述接口调研指令中携带有所述目标API的地址信息；

根据所述目标API的地址信息向所述目标API所属的设备发送抓包代理程序，以使所述设备安装所述抓包代理程序。

11.根据权利要求8所述的服务器，其特征在于，所述处理器，还用于：

在获取所述目标API的接口信息之后，根据预设的API元数据模板和所述目标API的接口信息，生成所述目标API的API元数据，其中，所述API元数据模板为用于描述不同API的接口信息的标准API描述模板。

12.根据权利要求8所述的服务器，其特征在于，所述处理器，还用于：

在获取所述目标API的接口信息之后，获取所述目标API的数据流，根据所述目标API的数据流对所述目标API的接口信息进行修正处理。

13.根据权利要求8-12任一项所述的服务器，其特征在于，所述目标API的接口信息包括API协议描述信息，API策略信息和API资源信息中的至少一项。

14.根据权利要求13所述的服务器，其特征在于，所述处理器，具体用于：

确定所述目标API的协议类型，根据预先存储的所述目标API的协议类型对应的协议解析模板，将所述目标API的数据流转换成所述目标API的API协议描述文件，其中，所述API协议描述文件中记录有所述API协议描述信息；

基于预设的接口信息和数据流的字段的对应关系，在所述目标API的数据流和API协议描述文件中提取所述目标API的接口信息。

15.一种获取API的接口信息的装置，其特征在于，所述装置包括：

第一获取模块，用于获取目标API的数据流；

第二获取模块，用于根据预设的接口信息和数据流的字段的对应关系，在所述目标API的数据流中获取所述目标API的接口信息。

16.根据权利要求15所述的装置，其特征在于，所述第一获取模块，具体用于：

通过多个抓包代理程序获取多个API的数据流，所述多个抓包代理程序安装在所述多个API所属的设备上；

根据所述目标API的地址信息，在所述多个API的数据流中筛选所述目标API的数据流。

17.根据权利要求16所述的装置，其特征在于，所述装置还包括：

第三获取模块，用于获取目标API的接口调研指令，所述接口调研指令中携带有所述目标API的地址信息；

发送模块，用于根据所述目标API的地址信息向所述目标API所属的设备发送抓包代理程序，以使所述设备安装所述抓包代理程序。

18.根据权利要求15所述的装置，其特征在于，所述装置还包括：

生成模块，用于在获取所述目标API的接口信息之后，根据预设的API元数据模板和所述目标API的接口信息，生成所述目标API的API元数据，其中，所述API元数据模板为用于描述不同API的接口信息的标准API描述模板。

19.根据权利要求15所述的装置，其特征在于，所述装置还包括：

修正模块，用于在获取所述目标API的接口信息之后，获取所述目标API的数据流，根据所述目标API的数据流对所述目标API的接口信息进行修正处理。

20.根据权利要求15-19任一项所述的装置，其特征在于，所述目标API的接口信息包括API协议描述信息，API策略信息和API资源信息中的至少一项。

21.根据权利要求20所述的装置，其特征在于，所述第二获取模块，具体用于：

确定所述目标API的协议类型，根据预先存储的所述目标API的协议类型对应的协议解析模板，将所述目标API的数据流转换成所述目标API的API协议描述文件，其中，所述API协议描述文件中记录有所述API协议描述信息；

基于预设的接口信息和数据流的字段的对应关系，在所述目标API的数据流和API协议描述文件中提取所述目标API的接口信息。

22.一种计算机可读存储介质，包括指令，当所述计算机可读存储介质在服务器上运行时，使得所述服务器执行所述权利要求1-7中任一权利要求所述的方法。