Application program interface identification method and device, medium and electronic equipment

Abstract

The present disclosure relates to an application program interface identification method, device, medium and electronic equipment. The method comprises: extracting a current API request path from current network traffic; if a target path matching the current API request path exists in a request path tree and the API list does not contain the target path, adding the target path to the API list, and the node belonging to a dynamic parameter in the request path tree being a wildcard node. In this way, the API list can be updated in real time based on the current API request, which not only ensures the real-time performance of the API list, but also ensures the integrity of the API list, realizes accurate automatic maintenance of the API list, and saves the cost of manual maintenance. The node belonging to the dynamic parameter in the request path tree is a wildcard node, and different paths of the same API containing different dynamic parameters are recorded only once in the API list, which can ensure that the API list is accurate and has no redundancy.

Description

Technical Field

[0001] This disclosure relates to the field of network security technology, and more specifically, to an application programming interface (API) identification method, apparatus, medium, and electronic device. Background Technology

[0002] In today's digital world, Application Programming Interfaces (APIs) play a crucial role. They are the foundation for building and connecting applications, enabling the flow of data and functionality between different systems and services. However, with the widespread use of APIs, they have also become primary targets of cyberattacks. Therefore, protecting API security has become an important issue, crucial for ensuring the overall information security of an enterprise. Obtaining an accurate and complete API list is a prerequisite for verifying the security of related APIs. In industrial practice, obtaining a complete API list faces many challenges. Rapid iteration in R&D leads to increasing system complexity, which may result in a large number of APIs scattered across various systems and services. If API list maintenance relies heavily on manual methods, it will lead to extremely high maintenance costs. Summary of the Invention

[0003] This summary section is provided to briefly introduce the concepts, which will be described in detail in the detailed description section below. This summary section is not intended to identify key or essential features of the claimed technical solution, nor is it intended to limit the scope of the claimed technical solution.

[0004] In a first aspect, this disclosure provides an application programming interface (API) identification method, including:

[0005] Extract the current application interface (API) request path from the current network traffic;

[0006] If a target path exists in the request path tree that matches the current API request path, and the target path is not included in the API list, then the target path is added to the API list. The request path tree is a multi-way tree that is dynamically updated based on historical API request paths, and the nodes belonging to dynamic parameters in the request path tree are wildcard nodes.

[0007] Secondly, this disclosure provides an application programming interface (API) identification device, comprising:

[0008] The extraction module is used to extract the current application programming interface (API) request path from the current network traffic;

[0009] The matching module is used to add the target path to the API list if there is a target path in the request path tree that matches the current API request path and the target path is not included in the API list. The request path tree is a multi-way tree that is dynamically updated based on historical API request paths, and the nodes in the request path tree that belong to dynamic parameters are wildcard nodes.

[0010] Thirdly, this disclosure provides a computer-readable medium having a computer program stored thereon, which, when executed by a processing device, implements the steps of the application programming interface identification method provided in the first aspect of this disclosure.

[0011] Fourthly, this disclosure provides an electronic device, comprising:

[0012] A storage device on which computer programs are stored;

[0013] A processing device is configured to execute the computer program in the storage device to implement the steps of the application programming interface identification method provided in the first aspect of this disclosure.

[0014] In the above technical solution, the current API request path is extracted from the current network traffic. If a target path matching the current API request path exists in the request path tree, but is not included in the API list, the target path is added to the API list. This allows for real-time updates to the API list based on the current API request, ensuring both real-time performance and completeness, achieving accurate and automatic maintenance of the API list, and saving manual maintenance costs. Furthermore, nodes representing dynamic parameters in the request path tree are wildcard nodes. This ensures that different paths to the same API containing different dynamic parameters are only recorded once in the API list, guaranteeing an accurate and non-redundant API list.

[0015] Other features and advantages of this disclosure will be described in detail in the following detailed description section. Attached Figure Description

[0016] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale. In the drawings:

[0017] Figure 1 This is a flowchart illustrating an application programming interface (API) identification method according to an exemplary embodiment.

[0018] Figure 2This is a schematic diagram illustrating the structure of a request path tree according to an exemplary embodiment.

[0019] Figure 3 This is a schematic diagram illustrating an API request path matching according to an exemplary embodiment.

[0020] Figure 4 This is a flowchart illustrating an application interface identification method according to another exemplary embodiment.

[0021] Figure 5A This is a schematic diagram illustrating a method of traversing a request path tree to identify nodes in the request path tree that belong to dynamic parameters, according to an exemplary embodiment.

[0022] Figure 5B It is Figure 5A The diagram shows the structure of the request path tree obtained after replacing the nodes that are dynamic parameters with preset characters.

[0023] Figure 6 This is a schematic diagram illustrating, according to an exemplary embodiment, fine-tuning a linear model and a pre-trained encoder based on an API list.

[0024] Figure 7 This is a block diagram illustrating an application programming interface (API) identification device according to an exemplary embodiment.

[0025] Figure 8 This is a schematic diagram of the structure of an electronic device according to an exemplary embodiment. Detailed Implementation

[0026] As discussed in the background section, obtaining a complete API list in industrial practice presents numerous challenges. Rapid iterations in R&D lead to increasing system complexity, potentially resulting in a large number of APIs scattered across various systems and services. If API list maintenance relies heavily on manual labor, it incurs extremely high maintenance costs. Therefore, several methods for extracting API lists using computers have emerged:

[0027] The first approach is to extract the API list based on the API infrastructure configuration: Some teams or enterprises have a unified, centralized gateway with APIs as the granularity. The API list can be obtained by extracting the configuration files from the gateway. While this method can obtain the most complete API list for services already connected to the infrastructure, in a large enterprise, the business and teams are complex, the code sources are diverse, and the infrastructure is numerous. Each business or even team has its own development model and habits, which may not be suitable for connecting to such a centralized gateway. Even if a similar centralized gateway is connected, it faces the challenge of many configuration types, rapid iteration of configuration formats, and the need for continuous adaptation.

[0028] The second approach is to extract the API list based on the business team's structured documents: some teams maintain separate structured information documents for each API, and the API list is directly parsed from these documents. This approach also faces challenges in terms of completeness in the context of complex infrastructure and diverse teams. Furthermore, the structured documents require additional resources from the business team for maintenance, and there are update delays.

[0029] The third approach is to extract the API list based on Layer 7 gateway traffic: Large enterprises typically have a standardized Layer 7 proxy gateway (i.e., the Open Systems Interconnection (OSI) seven-layer model). Network traffic is collected based on this gateway, and APIs are extracted according to the traffic path. This implementation provides a holistic and universal traffic collection method even with complex backend infrastructure and complex team development models. However, many business processes contain dynamic parameters in RESTful interfaces. Simply basing the API list on the path content without further processing will cause it to swell significantly (the same API will be recorded multiple times due to different dynamic parameters), hindering further analysis and use. Software interfaces designed based on the Representational State Transfer (REST) ​​concept are called RESTful interfaces.

[0030] In view of this, the present disclosure provides an application programming interface (API) identification method, apparatus, medium, and electronic device.

[0031] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0032] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0033] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0034] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0035] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0036] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0037] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0038] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application, server, or storage medium performing the operations of this disclosed technical solution, based on the prompt message.

[0039] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0040] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0041] Meanwhile, it is understood that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and related provisions.

[0042] Figure 1 This is a flowchart illustrating an application programming interface (API) identification method according to an exemplary embodiment, wherein the API identification method can be applied to electronic devices such as clients and servers. Figure 1 As shown, the application interface identification method may include the following S101 and S102.

[0043] In S101, the current application programming interface (API) request path is extracted from the current network traffic.

[0044] In this disclosure, network traffic is the total number of data packets passing through a network link per unit time. It is a basic indicator for measuring network load and forwarding performance. Hypertext Transfer Protocol (HTTP) traffic is one type of network traffic. HTTP traffic can be traffic generated by calling APIs or HTTP background traffic, etc. In order to better manage APIs, it is necessary to identify the APIs used from HTTP traffic.

[0045] Here, network traffic refers to the traffic of the API to be identified; that is, identifying whether the network traffic includes an API, and identifying whether the API included in the network traffic is a known API in the API list or an unknown API outside the API list. In one embodiment, the network traffic is HTTP traffic.

[0046] This embodiment of the disclosure can collect network traffic based on a Layer 7 proxy gateway. Network traffic can be collected by the execution entity of this embodiment; alternatively, it can be collected by other devices and then sent to the execution entity of this embodiment.

[0047] After obtaining the current network traffic, you can first extract the Uniform Resource Locator (URL) containing the current API request path from the current network traffic, and then extract the current API request path from the URL.

[0048] For example, the URL containing the current API request path extracted from the current network traffic is https: / / mydoc.com / docx / Th8vd5cO1oaFW0x39mbc1oUXnDe. Then, the current API request path " / docx / Th8vd5cO1oaFW0x39mbc1oUXnDe" is extracted from this URL. The URL is composed of the protocol, domain name, and path, where "https: / / " is the protocol, "mydoc.com" is the domain name, and " / docx / Th8vd5cO1oaFW0x39mbc1oUXnDe" is the path.

[0049] In S102, if there is a target path in the request path tree that matches the current API request path, and the API list does not contain the target path, then the target path is added to the API list.

[0050] In this disclosure, the request path tree is a multi-way tree that is dynamically updated based on historical API request paths, and the nodes belonging to dynamic parameters in the request path tree are wildcard nodes. The root node of the request path tree is empty, and the other nodes are path nodes on the request path. Any path node on the request path is the parent node of its adjacent downstream path node.

[0051] The request path tree contains two types of nodes: static character nodes and universal matching nodes (also known as wildcard nodes). Static character nodes are formed by path parsing and are represented by strings. Static character nodes are of non-wildcard type, while wildcard nodes are nodes belonging to dynamic parameters and are represented by preset characters (e.g., "*", "?", "#", "&", etc.). Wildcard nodes are of wildcard node type. Wildcard nodes have wildcard matching logic; during path matching, wildcard nodes match according to wildcards.

[0052] For example, the request path " / docx / Th8vd5cO1oaFW0x39mbc1oUXnDe" forms the path "Root→docx→Th8vd5cO1oaFW0x39mbc1oUXnDe" in the request path tree (e.g., ...). Figure 2 (As shown).

[0053] In this disclosure, it is possible to determine whether a target path exists in the request path tree that matches the current API request path by traversing the request path tree. For example... Figure 3As shown, assuming the request path tree stores a path "Root→aaa→*→aaac", and the current API request path is " / aaa / args_1 / aaac", by matching the current API request path with the request path tree, the target path "Root→aaa→*→aaac" that matches the current API request path can be obtained. If the API list does not contain this target path, it can be added to the API list, and then real-time network traffic can be monitored for real-time API identification. If the API list contains the target path, it is not necessary to add it again; real-time network traffic monitoring can continue for real-time API identification.

[0054] In the above technical solution, the current API request path is extracted from the current network traffic. If a target path matching the current API request path exists in the request path tree, but is not included in the API list, the target path is added to the API list. This allows for real-time updates to the API list based on the current API request, ensuring both real-time performance and completeness, achieving accurate and automatic maintenance of the API list, and saving manual maintenance costs. Furthermore, nodes representing dynamic parameters in the request path tree are wildcard nodes. This ensures that different paths to the same API containing different dynamic parameters are only recorded once in the API list, guaranteeing an accurate and non-redundant API list.

[0055] If a business system is large, its corresponding request path tree is usually quite large. Determining whether a target path matching the current API request path exists by traversing the request path tree is inefficient and affects API recognition efficiency. Therefore, the business system can be divided into multiple sites based on domain names, where each site corresponds to at least one domain name. Accordingly, the request path tree can include multiple request path subtrees corresponding to each site, where each site's request path subtree is independent and does not affect the others. In this case, the following method can be used to determine whether a target path matching the current API request path exists in the request path tree:

[0056] After extracting the current API request, firstly, determine the target domain name in the URL where the current API request path is located; if there is a path in the request path subtree corresponding to the target site that matches the current API request path, then it is determined that there is a target path in the request path tree, where the target site is the site that corresponds to the target domain name among multiple sites.

[0057] In the above implementation, the target site corresponding to the API request path is first found. Then, the path matching the current API request path is found by traversing the request path subtree corresponding to the target site. This can improve the efficiency of path matching and thus improve the API recognition efficiency.

[0058] Figure 4 This is a flowchart illustrating an application programming interface (API) identification method according to another exemplary embodiment. For example... Figure 4 As shown, the above method may also include the following S103.

[0059] In S103, if there is no target path in the request path tree that matches the current API request path, the current API request path is added to the request path tree to obtain a new request path tree.

[0060] In this disclosure, the current API request path can be added to the request path tree in the following way: First, the request path can be divided into path nodes. Then, according to the positional relationship of each path node in the current API request path, each path node is added to the request path tree. In the new request path tree, any path node on the current API request path is the parent node of its adjacent downstream path node.

[0061] When the request path tree includes multiple request path subtrees corresponding to different sites, the current API request path can be added to the request path tree in the following ways:

[0062] First, determine the target domain name in the Uniform Resource Locator (URL) where the current API request path is located; then, add the current API request path to the request path tree corresponding to the target site, where the target site is the site that corresponds to the target domain name among multiple sites.

[0063] If no matching target path exists in the request path tree, the current API request path can be temporarily added to the request path tree instead of the API list. This allows for later periodic traversal to determine if the current API request path contains dynamic parameters. If it does, the path nodes containing dynamic parameters are replaced with preset characters. If a subsequent request path matches the path obtained after replacing the preset characters, that path is then added to the API list. This ensures that different paths to the same API containing different dynamic parameters are recorded only once in the API list, guaranteeing accuracy and eliminating redundancy.

[0064] If no matching target path exists in the request path tree, the current API request path is added to the request path tree. This makes the request path tree dynamically updated. Newly added API request paths may contain dynamic parameters. Therefore, the request path tree can be periodically traversed to identify nodes with dynamic parameters and perform preset character replacements. This continuously maintains the dynamically updating request path tree, ensuring that matching paths are added to the API list promptly and minimizing the latency of API list updates. Specifically, the above method can also include the following two steps:

[0065] The request path tree is traversed according to the first preset cycle to identify nodes in the request path tree that belong to dynamic parameters.

[0066] Replace nodes in the request path tree that belong to dynamic parameters with preset characters.

[0067] In this disclosure, when the request path tree includes multiple request path subtrees corresponding to each site, the multiple request path subtrees corresponding to each site can be traversed in parallel according to a first preset period.

[0068] The following provides a detailed description of the specific implementation method for traversing the request path tree according to the first preset period. Specifically, this can be implemented through various methods. In one implementation, the dynamic parameter can include any one of the following: a number, a string starting with a number, a Universally Unique Identifier (UUID), an MD5 hash, a random string, or a string representing a username or other indistinct characteristics. For each node in the request path tree, it is determined whether all child nodes of that node contain any one of the following: a number, a string starting with a number, a UUID, an MD5 hash, a random string, or a string representing a username or other indistinct characteristics. If all child nodes of that node contain any of the above dynamic parameters, then all child nodes of that node are determined to be dynamic parameters. The presence of a random string in all child nodes of that node can be determined using a Hidden Markov Random String Algorithm.

[0069] In another implementation, a pre-trained deep learning model can be used to traverse the request path tree according to a first preset period. That is, the deep learning model can identify the nodes in the request path tree that belong to dynamic parameters. In this way, the deep learning model can conveniently identify the nodes in the request path tree that belong to dynamic parameters.

[0070] Specifically, the deep learning model can traverse the request path tree through the following steps (1) to (3) to identify the nodes in the request path tree that belong to dynamic parameters:

[0071] Step (1): For each node in the request path tree, concatenate all the child nodes of the node and input them into the deep learning model to determine whether the child nodes of the node contain dynamic parameters.

[0072] In this disclosure, the property that all child nodes of a node belong to dynamic parameters is the same; that is, all child nodes of a node either do not belong to dynamic parameters or all belong to dynamic parameters. Therefore, the deep learning model determines whether all child nodes of a node contain dynamic parameters by judging whether the concatenated string contains dynamic parameters, where the concatenated string is the string obtained by concatenating all child nodes of the node.

[0073] Step (2): If all child nodes of the node contain dynamic parameters, then all child nodes of the node are determined to be dynamic parameters.

[0074] Step (3): If none of the child nodes of the node contain dynamic parameters, then it is determined that none of the child nodes of the node belong to dynamic parameters.

[0075] For example, such as Figure 5A As shown, for the root node, all child nodes of the root node (i.e., the second-level nodes of the request path tree) can be concatenated and input into the deep learning model to determine whether the child nodes of the root node contain dynamic parameters. The output of the deep learning model is False, which means that the child nodes of the root node do not contain dynamic parameters. In this case, no preset character replacement is performed.

[0076] against Figure 5A In the example of the "docx" node, first, all child nodes of the "docx" node (including the "Th8vd5cO1oaFW0x39mbc1oUXnDe" node, the "arg_1" node, the "args_2" node, etc.) are concatenated and input into the deep learning model to determine whether any of the child nodes of the "docx" node contain dynamic parameters. If the deep learning model outputs True, it indicates that all child nodes of the "docx" node contain dynamic parameters. At this point, all child nodes of the "docx" node can be replaced with the preset character "*", resulting in... Figure 5B The request path tree shown.

[0077] During the initial operation phase of the business system, the deep learning model can be trained based on the API list. Because the API list initially contains fewer paths and fewer training samples, the accuracy of dynamic parameter recognition in the deep learning model is low. However, the API list is dynamically updated, containing more and more paths, and correspondingly, more and more training samples. Therefore, the deep learning model can be periodically updated based on the API list to improve the accuracy of dynamic parameter recognition, thereby ensuring the API list is accurate and free of redundancy. Specifically, the above application programming interface (API) recognition method may further include the following steps:

[0078] The deep learning model is updated according to the API list and the second preset cycle.

[0079] Specifically, deep learning models can be updated periodically through the following steps (a) to (d):

[0080] Step (a): Obtain the current API list according to the second preset cycle.

[0081] Step (b): Replace all the preset characters in the current API list with the original characters before replacement to obtain the reference API list.

[0082] For example, if a path in the current API list is “aaa→*→aaac”, which is obtained by replacing the path node “args_1” in the path “aaa→args_1→aaac” with the preset character “*”, then the preset character “*” in the path “aaa→*→aaac” in the API list can be replaced with the original character “args_1” before the replacement.

[0083] Step (c): For each reference path in at least a portion of the reference paths in the reference API list, determine the annotation information of at least a portion of the path nodes on that reference path.

[0084] In this disclosure, for each reference path in a subset of reference paths in the reference API list, the annotation information of some or all path nodes on that reference path can be determined.

[0085] The annotation information is used to indicate whether the corresponding path node belongs to a dynamic parameter. For example, if a path node belongs to a dynamic parameter, its annotation information can be represented by 1; if a path node does not belong to a dynamic parameter, its annotation information can be represented by 0.

[0086] Specifically, the annotation information of nodes that were preset characters before replacement belongs to dynamic parameters, while the annotation information of other nodes does not belong to dynamic parameters.

[0087] Step (d): Train the deep learning model using each annotation and the path node corresponding to each annotation as training samples.

[0088] Specifically, for each path node corresponding to the labeled information, the model can be trained by using the path node as the input of the deep learning model and the labeled information of the path node as the target output of the deep learning model.

[0089] The following section details the training methods for deep learning models during the initial operation phase of a business system. In one implementation, such as... Figure 6 As shown, the deep learning model described above can include an encoder based on the attention mechanism of the Transformer sequence model and a linear model.

[0090] First, an open-source corpus (such as an English corpus) can be used to pre-train the encoder using a masked language model (Mask LM); then, the pre-trained encoder can be fine-tuned based on the API list.

[0091] One approach is similar to updating the deep learning model described above, where the pre-trained encoder is fine-tuned based on the API list. During the model fine-tuning phase and update nodes, the parameters of the linear model are also updated accordingly.

[0092] The path nodes input into the model need to be segmented into words first, and then the segmentation results are input into the deep learning model. Since the segmentation method in the request path is different from that in common natural language, there are no natural segmentation symbols. Therefore, the traditional word-based segmentation method cannot segment this type of text well. At the same time, the commonly used segmentation methods in the request path are not the same. Therefore, segmentation can be performed on a morpheme-based basis.

[0093] like Figure 6 As shown, when the encoder obtained after pre-training is fine-tuned, the output result (i.e., CT) at the corresponding position of the classification token [CLS] is used to input the output result into the linear model to obtain the final classification result (cls result).

[0094] Figure 7 This is a block diagram illustrating an application programming interface (API) identification device according to an exemplary embodiment. Figure 7 As shown, the device 200 includes:

[0095] Extraction module 201 is used to extract the current application programming interface (API) request path from the current network traffic;

[0096] The matching module 202 is used to add the target path to the API list if there is a target path in the request path tree that matches the current API request path and the target path is not included in the API list. The request path tree is a multi-way tree that is dynamically updated based on historical API request paths, and the nodes in the request path tree that belong to dynamic parameters are wildcard nodes.

[0097] In the above technical solution, the current API request path is extracted from the current network traffic. If a target path matching the current API request path exists in the request path tree, but is not included in the API list, the target path is added to the API list. This allows for real-time updates to the API list based on the current API request, ensuring both real-time performance and completeness, achieving accurate and automatic maintenance of the API list, and saving manual maintenance costs. Furthermore, nodes representing dynamic parameters in the request path tree are wildcard nodes. This ensures that different paths to the same API containing different dynamic parameters are only recorded once in the API list, guaranteeing an accurate and non-redundant API list.

[0098] Optionally, the device 200 further includes:

[0099] An adding module is used to add the current API request path to the request path tree if the target path does not exist in the request path tree, thereby obtaining a new request path tree, wherein in the new request path tree, any path node on the current API request path is the parent node of its adjacent downstream path node.

[0100] Optionally, the device 200 further includes:

[0101] The traversal module is used to traverse the request path tree according to a first preset period in order to identify nodes in the request path tree that belong to dynamic parameters.

[0102] The replacement module is used to replace the nodes belonging to dynamic parameters in the request path tree with preset characters.

[0103] Optionally, the traversal module is used to traverse the request path tree according to a first preset period using a pre-trained deep learning model.

[0104] Optionally, the deep learning model traverses the request path tree in the following manner:

[0105] For each node in the request path tree, all child nodes of that node are concatenated and input into the deep learning model to determine whether all child nodes of that node contain dynamic parameters.

[0106] If all child nodes of a node contain dynamic parameters, then all child nodes of that node are considered to be dynamic parameters.

[0107] Optionally, the device 200 further includes:

[0108] The update module is used to update the deep learning model according to the API list and at a second preset period.

[0109] Optionally, the update module includes:

[0110] The `GetSubmodule` is used to retrieve the current API list according to a second preset period.

[0111] The replacement submodule is used to replace all preset characters in the current API list with the original characters before replacement, so as to obtain a reference API list;

[0112] The determination submodule is used to determine the annotation information of at least a portion of the path nodes on each reference path in at least a portion of the reference paths in the reference API list, wherein the annotation information is used to characterize whether the corresponding path node belongs to a dynamic parameter;

[0113] The training submodule is used to train the deep learning model using each of the labeled information and the path node corresponding to each of the labeled information as training samples.

[0114] Optionally, the request path tree includes multiple request path subtrees corresponding to each site, wherein each site corresponds to at least one domain name;

[0115] The device 200 further includes:

[0116] The first determining module is used to determine the target domain name in the Uniform Resource Locator where the current API request path is located after the current API request is extracted;

[0117] The second determining module is used to determine that the target path exists in the request path tree if there is a path in the request path subtree corresponding to the target site that matches the current API request path, wherein the target site is the site among the plurality of sites that corresponds to the target domain name.

[0118] The following is for reference. Figure 8The diagram illustrates a structural schematic of an electronic device (e.g., a terminal device or a server) 600 suitable for implementing embodiments of the present disclosure. The terminal device in the embodiments of the present disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 8 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0119] like Figure 8 As shown, electronic device 600 may include a processing device (e.g., a central processing unit, a graphics processor, etc.) 601, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 602 or a program loaded from storage device 608 into random access memory (RAM) 603. RAM 603 also stores various programs and data required for the operation of electronic device 600. Processing device 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.

[0120] Typically, the following devices can be connected to I / O interface 605: input devices 606 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 607 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 608 including, for example, magnetic tapes, hard disks, etc.; and communication devices 609. Communication device 609 allows electronic device 600 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 8 An electronic device 600 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0121] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 609, or installed from a storage device 608, or installed from a ROM 602. When the computer program is executed by the processing device 601, it performs the functions defined in the methods of embodiments of this disclosure.

[0122] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0123] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0124] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0125] The aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: extract the current application programming interface (API) request path from the current network traffic; and if a target path matching the current API request path exists in the request path tree and the target path is not included in the API list, then add the target path to the API list, wherein the request path tree is a multi-way tree dynamically updated based on historical API request paths, and the nodes belonging to dynamic parameters in the request path tree are wildcard nodes.

[0126] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0127] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0128] The modules described in the embodiments of this disclosure can be implemented in software or in hardware. The name of a module does not necessarily limit the module itself; for example, an extraction module can also be described as "a module that extracts the current application programming interface (API) request path from current network traffic".

[0129] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0130] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0131] According to one or more embodiments of this disclosure, Example 1 provides an application programming interface (API) identification method, comprising:

[0132] Extract the current application interface (API) request path from the current network traffic;

[0133] If a target path exists in the request path tree that matches the current API request path, and the target path is not included in the API list, then the target path is added to the API list. The request path tree is a multi-way tree that is dynamically updated based on historical API request paths, and the nodes belonging to dynamic parameters in the request path tree are wildcard nodes.

[0134] According to one or more embodiments of this disclosure, Example 2 provides the method of Example 1, the method further comprising:

[0135] If the target path does not exist in the request path tree, the current API request path is added to the request path tree to obtain a new request path tree, wherein any path node on the current API request path is the parent node of its adjacent downstream path node in the new request path tree.

[0136] According to one or more embodiments of this disclosure, Example 3 provides the method of Example 2, the method further comprising:

[0137] The request path tree is traversed according to a first preset period to identify nodes in the request path tree that belong to dynamic parameters.

[0138] Replace the nodes belonging to dynamic parameters in the request path tree with preset characters.

[0139] According to one or more embodiments of this disclosure, Example 4 provides the method of Example 3, wherein traversing the request path tree according to a first preset period includes:

[0140] The request path tree is traversed using a pre-trained deep learning model according to a first preset cycle.

[0141] According to one or more embodiments of this disclosure, Example 5 provides the method of Example 4, wherein the deep learning model traverses the request path tree in the following manner:

[0142] For each node in the request path tree, all child nodes of that node are concatenated and input into the deep learning model to determine whether all child nodes of that node contain dynamic parameters.

[0143] If all child nodes of a node contain dynamic parameters, then all child nodes of that node are considered to be dynamic parameters.

[0144] According to one or more embodiments of this disclosure, Example 6 provides the method of Example 4, the method further comprising:

[0145] The deep learning model is updated according to the API list at a second preset period.

[0146] According to one or more embodiments of this disclosure, Example 7 provides the method of Example 6, wherein updating the deep learning model according to the API list at a second preset period includes:

[0147] Retrieve the current API list according to the second preset cycle;

[0148] Replace all preset characters in the current API list with the original characters before replacement to obtain the reference API list;

[0149] For each reference path in at least a portion of the reference paths in the reference API list, determine the annotation information of at least a portion of the path nodes on the reference path, wherein the annotation information is used to characterize whether the corresponding path node belongs to a dynamic parameter;

[0150] The deep learning model is trained using each of the aforementioned annotation information and the path node corresponding to each of the aforementioned annotation information as training samples.

[0151] According to one or more embodiments of this disclosure, Example 8 provides a method of any one of Examples 1-7, wherein the request path tree includes multiple request path subtrees corresponding to each site, wherein each site corresponds to at least one domain name;

[0152] The method further includes:

[0153] After extracting the current API request, determine the target domain name in the Uniform Resource Locator where the current API request path is located;

[0154] If there is a path in the request path subtree corresponding to the target site that matches the current API request path, then it is determined that the target path exists in the request path tree, wherein the target site is the site among the plurality of sites that corresponds to the target domain name.

[0155] According to one or more embodiments of this disclosure, Example 9 provides an application programming interface (API) identification device, comprising:

[0156] The extraction module is used to extract the current application programming interface (API) request path from the current network traffic;

[0157] The matching module is used to add the target path to the API list if there is a target path in the request path tree that matches the current API request path and the target path is not included in the API list. The request path tree is a multi-way tree that is dynamically updated based on historical API request paths, and the nodes in the request path tree that belong to dynamic parameters are wildcard nodes.

[0158] According to one or more embodiments of the present disclosure, Example 10 provides a computer-readable medium having a computer program stored thereon that, when executed by a processing device, implements the steps of the method described in any one of Examples 1-8.

[0159] According to one or more embodiments of this disclosure, Example 11 provides an electronic device, including:

[0160] A storage device on which computer programs are stored;

[0161] A processing device for executing the computer program in the storage device to implement the steps of any one of the methods in Examples 1-8.

[0162] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0163] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0164] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative forms of implementing the claims. Regarding the apparatus in the above embodiments, the specific manner in which the various modules perform their operations has been described in detail in the embodiments relating to the method, and will not be elaborated upon here.

Claims

1. A method for identifying application programming interfaces (APIs), characterized in that, include: Extract the current application interface (API) request path from the current network traffic; If there is a target path in the request path tree that matches the current API request path, and the target path is not included in the API list, then the target path is added to the API list. The request path tree is a multi-way tree that is dynamically updated based on historical API request paths, and the nodes that belong to dynamic parameters in the request path tree are wildcard nodes. If the target path does not exist in the request path tree, the current API request path is added to the request path tree to obtain a new request path tree, wherein any path node on the current API request path is the parent node of its adjacent downstream path node in the new request path tree.

2. The method according to claim 1, characterized in that, The method further includes: The request path tree is traversed according to a first preset period to identify nodes in the request path tree that belong to dynamic parameters. Replace the nodes belonging to dynamic parameters in the request path tree with preset characters.

3. The method according to claim 2, characterized in that, The step of traversing the request path tree according to a first preset period includes: The request path tree is traversed using a pre-trained deep learning model according to a first preset cycle.

4. The method according to claim 3, characterized in that, The deep learning model traverses the request path tree in the following manner: For each node in the request path tree, all child nodes of that node are concatenated and input into the deep learning model to determine whether dynamic parameters are contained in all child nodes of that node. If all child nodes of a node contain dynamic parameters, then all child nodes of that node are considered to be dynamic parameters.

5. The method according to claim 3, characterized in that, The method further includes: The deep learning model is updated according to the API list at a second preset period.

6. The method according to claim 5, characterized in that, The step of updating the deep learning model according to the API list and at a second preset period includes: Retrieve the current API list according to the second preset cycle; Replace all preset characters in the current API list with the original characters before replacement to obtain the reference API list; For each reference path in at least a portion of the reference paths in the reference API list, determine the annotation information of at least a portion of the path nodes on the reference path, wherein the annotation information is used to characterize whether the corresponding path node belongs to a dynamic parameter; The deep learning model is trained using each of the aforementioned annotation information and the path node corresponding to each of the aforementioned annotation information as training samples.

7. The method according to any one of claims 1-6, characterized in that, The request path tree includes multiple request path subtrees corresponding to each site, wherein each site corresponds to at least one domain name; The method further includes: After extracting the current API request path, determine the target domain name in the Uniform Resource Locator where the current API request path is located; If there is a path in the request path subtree corresponding to the target site that matches the current API request path, then it is determined that the target path exists in the request path tree, wherein the target site is the site among the plurality of sites that corresponds to the target domain name.

8. An application programming interface (API) identification device, characterized in that, include: The extraction module is used to extract the current application programming interface (API) request path from the current network traffic; The matching module is used to add the target path to the API list if there is a target path in the request path tree that matches the current API request path and the target path is not included in the API list. The request path tree is a multi-way tree that is dynamically updated based on historical API request paths, and the nodes that belong to dynamic parameters in the request path tree are wildcard nodes. An adding module is used to add the current API request path to the request path tree if the target path does not exist in the request path tree, thereby obtaining a new request path tree, wherein in the new request path tree, any path node on the current API request path is the parent node of its adjacent downstream path node.

9. A computer-readable medium having a computer program stored thereon, characterized in that, When executed by the processing device, the program implements the steps of the method described in any one of claims 1-7.

10. An electronic device, characterized in that, include: A storage device on which computer programs are stored; A processing device for executing the computer program in the storage device to implement the steps of the method according to any one of claims 1-7.

Images