An API knowledge graph construction method, medium and device

Abstract

This invention relates to the field of knowledge graph construction technology, and more particularly to an API knowledge graph construction method, medium, and device. By parsing source code, API definition files, and configuration files, it avoids API identification omissions caused by reliance on a single data source, making API asset identification more complete. A first knowledge graph represents the declarative interface features of the API, transforming the surface features of the API into structured semantic associations. A second knowledge graph integrates business, technology, and security nodes of multiple types, mining the deep contextual associations and multi-dimensional attributes of the API, making API semantic understanding more accurate and asset profiling more comprehensive. The target structure tree verifies code structure connectivity, combining graph path filtering with underlying code logic verification to avoid misjudgments and omissions. Furthermore, a knowledge graph is constructed by fusing two-layer connection relationships, integrating static declarative features with dynamic runtime associations, making API association determination more reliable.

Description

Technical Field

[0001] This invention relates to the field of knowledge graph construction technology, and in particular to an API knowledge graph construction method, medium, and device. Background Technology

[0002] With the widespread adoption of microservice architecture and cloud-native technologies, the number of application programming interfaces (APIs) in modern software systems is growing exponentially. As the core channel for interaction between the system and the outside world, a complete asset view of APIs is crucial for scenarios such as security auditing, architecture governance, service dependency analysis, and change impact assessment.

[0003] However, existing API knowledge graph construction methods typically rely on a single data source, such as analyzing only OpenAPI / Swagger specification documents, parsing only source code annotations, or monitoring only network traffic. This results in a graph that only reflects partial characteristics of the API and fails to form a complete asset view. Furthermore, existing solutions often separate the static declaration information of APIs (such as interface specifications) from dynamic implementation information (such as code logic and configuration context), creating information silos. For example, API declarations extracted from specification documents cannot be effectively correlated with actual behaviors analyzed from the code, resulting in a graph that cannot accurately reflect the API's operational status and dependencies in the real environment. Moreover, traditional API association analysis is mostly based on simple pattern matching or keyword similarity, which cannot deeply understand the semantic relationships between APIs. For modern applications using complex frameworks, dynamic routing, or reflection mechanisms, existing methods are prone to generating a large number of false positives or false negatives, making it difficult to accurately identify technical dependencies, data flow, and business logic relationships between APIs.

[0004] Therefore, how to construct a unified API asset knowledge graph that is comprehensive, rich in attributes, and accurately correlated has become an urgent technical problem to be solved. Summary of the Invention

[0005] To address the aforementioned technical problems, the present invention provides a method for constructing an API knowledge graph, which includes the following steps:

[0006] S1 parses the source code, API definition file, and configuration file of the project to be analyzed, and obtains the target structure tree corresponding to the source code, the first key feature vector corresponding to each API declared in the API definition file, and the second key feature vector corresponding to the configuration file.

[0007] S2. Based on the first key feature vector corresponding to each API, construct the first knowledge graph corresponding to each API, where the first knowledge graph is used to represent the declarative interface features of the API.

[0008] S3. Based on the association relationship between nodes in the first knowledge graph, determine the first connection relationship between API nodes.

[0009] S4. Based on the second key feature vector and the contextual relationship of the API, construct the second knowledge graph, which contains API nodes and associated business nodes, technical nodes, and security nodes.

[0010] S5. Based on the target structure tree, verify the code structure connectivity of each candidate path in the second knowledge graph that satisfies the consistency of preset attributes, and determine the second connection relationship between API nodes. The preset attributes include at least one of business attributes, technical attributes, and security attributes.

[0011] S6 constructs an API knowledge graph based on the first and second connection relationships between API nodes.

[0012] The present invention also provides a non-transitory computer-readable storage medium storing at least one instruction or at least one program, wherein the at least one instruction or at least one program is loaded and executed by a processor to implement the above-described API knowledge graph construction method.

[0013] The present invention also provides an electronic device, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0014] This invention has at least the following beneficial effects: By parsing three types of core data—source code, API definition files, and configuration files—it avoids API identification omissions caused by reliance on a single data source, making API asset identification more complete; by representing the declarative interface features of APIs through a first knowledge graph, it transforms the surface features of APIs such as input parameters, output parameters, and data models into structured semantic associations; by integrating multiple types of nodes—business, technology, and security—through a second knowledge graph, it mines the deep contextual associations and multi-dimensional attributes of APIs, making API semantic understanding more accurate and asset profiling more comprehensive, fully covering the core dimensions of technology, business, and security; by verifying the code structure connectivity through a target structure tree, it combines graph path filtering with underlying code logic verification, avoiding the misjudgment and omission problems of traditional pattern matching; and by constructing a knowledge graph through the fusion of two-layer connection relationships, it breaks down the information barriers between static declarative features and dynamic runtime associations, making API association determination more reliable and ensuring that the association logic is more in line with actual operating scenarios. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart of an API knowledge graph construction method provided in Embodiment 1 of the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It is understood that, where appropriate, the terms used to distinguish similar objects can be interchanged so that the invention can also be implemented in other embodiments besides the illustrated or described embodiments. Furthermore, the terms "including," "having," and any variations are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or devices.

[0019] Example 1

[0020] This first embodiment provides a method for constructing an API knowledge graph, such as... Figure 1 As shown, the method for constructing this API knowledge graph includes the following steps:

[0021] S1 parses the source code, API definition file, and configuration file of the project to be analyzed, and obtains the target structure tree corresponding to the source code, the first key feature vector corresponding to each API declared in the API definition file, and the second key feature vector corresponding to the configuration file.

[0022] The source code of the project to be analyzed is a collection of original code files written in a specific programming language (such as Java, Python, Go, etc.) that constitute the target application. It contains code units such as classes, methods, functions, variable declarations, and logical control statements that implement the core functionality of the application, as well as auxiliary information such as code comments, directory structure, and package organization. By parsing the source code, a target structure tree with both syntactic hierarchical integrity and execution logical coherence is obtained. This structure tree serves as the core basis for subsequent code structure connectivity verification. By locating the structural blocks corresponding to code segments, the actual execution relationships between API nodes are determined, solving the problem that traditional pattern matching cannot verify the logical connectivity of code.

[0023] API definition files are standardized, structured files that describe the metadata of application programming interfaces (APIs). They adhere to unified specifications (such as OpenAPI / Swagger specifications, RAML specifications, etc.) and clarify declarative information such as access rules, parameter constraints, and response formats for API endpoints. By parsing API definition files, core parameters that uniquely characterize the API's surface-level interface features are extracted and transformed into a structured first key feature vector, achieving a standardized and associative representation of API interface declaration information. This first key feature vector can be a set of vectors composed of core parameters such as the API name, input parameter types, input parameter constraints, output parameter types, and data formats. It provides core data for subsequent construction of the first knowledge graph. The declarative interface feature graph of the API is constructed using the feature parameters in the vectors, supporting the determination of relationships between API nodes based on surface-level features.

[0024] Configuration files are used to configure non-code-level information such as the application's runtime environment, framework parameters, dependencies, and routing rules. They do not contain core business logic implementations and are only used to control the application's runtime behavior to adapt to different deployment environments or functional requirements. By parsing the configuration files, runtime association features of the APIs are extracted and transformed into structured second key feature vectors, providing data support for API context relationship mining. The second key feature vector can be a set of vectors composed of core configurations such as framework annotation information, routing mapping rules, service dependency configurations, and module association parameters. It provides core data for subsequent second knowledge graph construction, supporting the mining of relationships between API nodes and business nodes, technical nodes, and security nodes, thus overcoming the limitation of the first key feature vector, which can only represent surface-level interface features.

[0025] The above-mentioned approach involves targeted analysis of three core data sources—source code, API definition files, and configuration files—to extract the fundamental data required for constructing an API knowledge graph. This transforms unstructured / semi-structured code and configuration information into structured, associative feature data and logical models, providing data support for subsequent two-layer knowledge graph construction and API node relationship determination. This approach also addresses the issues of reliance on a single data source and information fragmentation.

[0026] In one specific embodiment, S1 includes the following steps:

[0027] S11 performs lexical and syntactic analysis on the source code to obtain the abstract syntax tree corresponding to the source code.

[0028] S12, perform control flow analysis on the abstract syntax tree to obtain the control flow graph corresponding to the source code.

[0029] S13 maps and merges the syntax nodes in the abstract syntax tree and the control nodes in the control flow graph to obtain the target structure tree.

[0030] S14. Parse the description information of each API declared in the API definition file to obtain the first key feature vector corresponding to each API. The first key feature vector includes at least one of the following: API name, input parameter type, input parameter constraint, output parameter type, data format, data model name, field composition, and field type.

[0031] S15, parse the configuration file to obtain the second key feature vector, wherein the second key feature vector includes at least one of the following: framework annotation information, routing mapping rules, service dependency configuration, and module association parameters.

[0032] Lexical analysis and syntax analysis are used to transform source code from a sequence of characters into a structured syntactic representation. Lexical analysis breaks down the code into its smallest semantic units (lexical units), while syntax analysis organizes these lexical units into a hierarchical syntactic structure according to the programming language's syntax rules, ultimately forming an abstract syntax tree (AST), which enables machine-understandable code syntax structure. Specifically, the AST is an abstract representation of the source code's syntactic structure, presenting the hierarchical relationships of the code in a tree-like structure (e.g., classes containing methods, methods containing statements). Each node stores key information about the corresponding syntactic component (e.g., method name, parameter types, statement types), used to strip away the specific writing format of the source code while preserving the core syntactic logic, providing a structured foundation for subsequent control flow analysis and code structure extraction.

[0033] Control flow analysis is a core technique in static program analysis. Based on the syntactic structure of an abstract syntax tree, it mines the execution order and jump relationships of statements, branches, and loops in the code to construct a control flow graph. This transforms the static syntactic structure of the code into a dynamic execution logic path, reflecting the control flow direction during program runtime. Specifically, a control flow graph is a graphical representation of program control flow, with nodes as basic blocks and edges representing control flow jump relationships. It is used to intuitively present the execution logic of code branches, loops, and calls, providing a dynamic execution path basis for subsequent code structure connectivity verification.

[0034] Those skilled in the art will recognize that any existing word analysis method, syntax analysis method, or control flow analysis method falls within the protection scope of this invention, and will not be elaborated upon here.

[0035] Abstract syntax trees (ASTs) focus on the hierarchical structure of source code syntax (such as the static organization of classes, methods, and statements), while control flow graphs focus on the execution logic paths of source code (such as dynamic jumps to basic blocks). Both have information limitations when existing independently. Therefore, this embodiment uses node mapping and logical fusion to associate the static syntax structure with the dynamic execution logic, forming a target structure tree that combines structural integrity and logical coherence.

[0036] Syntax nodes are the basic building blocks in an abstract syntax tree (AST), corresponding to the syntactic components of the code (such as class nodes, method nodes, and statement nodes), and storing syntax-related information. Control nodes are the basic building blocks in a control flow graph, storing the set of executable statements and control flow jump information. Specifically, a correspondence is established between AST syntactic nodes and control flow graph control nodes. For example, a "method declaration node" in the AST corresponds to the set of all basic blocks corresponding to that method in the control flow graph, and a "conditional statement node" in the AST corresponds to the condition judgment basic blocks and branch basic blocks in the control flow graph, ensuring that each syntactic component can be associated with its corresponding execution logic unit. Based on the hierarchical structure of the AST, the control flow relationships of the control flow graph are embedded within it. For example, under the "method node" in the AST, statement nodes are organized according to the jump order of the basic blocks in the control flow graph, forming a hierarchical structure of "method-basic block-statement," while retaining the jump edge information between basic blocks, so that the target structure tree reflects both the syntactic hierarchy and the execution logic path. By removing redundant nodes and merging duplicate mapping relationships, a structured model that combines syntactic hierarchy integrity with execution logic coherence is obtained, ensuring the simplicity and consistency of the target structure tree.

[0037] By parsing the API definition file, core parameters that uniquely characterize the API surface interface are extracted and transformed into a structured first key feature vector, achieving a standardized and associative representation of API interface declaration information. Specifically, the API definition file is read and parsed based on the corresponding specification schema to identify each API endpoint declared in the file. For each API endpoint, core descriptive information is extracted, which may include the API name, input parameter types, input parameter constraints, output parameter types, output parameter data formats, data model names, field composition, and field types. The extracted feature parameters are standardized, such as by unifying data type identifiers and formatting constraint rule descriptions, to construct the first key feature vector.

[0038] By parsing configuration files, runtime association features of the API are extracted and transformed into a structured second key feature vector, providing data support for API context relationship mining. Specifically, the configuration file type is identified, and the corresponding parser is used to read the file content, removing comments and redundant configuration items. Core configuration information is extracted, including framework annotation information, routing mapping rules, service dependency configurations, module association parameters, etc. The extracted configuration information is then structured, such as standardizing annotation name formats and dependency configuration descriptions, to construct a second key feature vector, which is then associated with the corresponding API nodes.

[0039] The above approach uses three types of core files from the project to be analyzed as input. It employs a layered processing strategy of syntax parsing, logical fusion, and feature extraction. The source code is first parsed for its syntax structure, then the execution logic is fused to generate a target structure tree reflecting the static structure and dynamic execution flow of the code. For API definition files, the focus is on interface declaration information, extracting key vectors representing the characteristics of the API surface interface. For configuration files, the focus is on framework configuration and association information, extracting key vectors representing the API runtime environment and context dependencies. Finally, three types of structured basic data are output, providing standardized and comprehensive data support for knowledge graph construction.

[0040] S2. Based on the first key feature vector corresponding to each API, construct the first knowledge graph corresponding to each API, where the first knowledge graph is used to represent the declarative interface features of the API.

[0041] In one specific embodiment, S2 includes the following steps:

[0042] Based on the first key feature vector, with the API node as the root node, and the parameter node, response node, and data model node as the first nodes, relationship edges are established between the API node and the first node, and between the first nodes, to construct the first knowledge graph. The declarative relationship includes at least one of the following: parameter ownership relationship, response return relationship, and model usage relationship.

[0043] The method uses the first key feature vector of each API as input and adopts a three-step modeling approach of "root node definition - associated node splitting - relation edge construction". First, the API itself is defined as the root node of the graph, and all associated first nodes are coordinated to ensure the hierarchical integrity of the graph.

[0044] The first key feature vector is further split into parameter nodes, response nodes, and data model nodes as core first nodes. This transforms the flattened first key feature vector into structured node objects, providing a carrier for establishing semantic relationships between features. Specifically, parameter nodes represent the input parameter features of the API, storing information such as the input parameter name, input parameter type, and input parameter constraints from the first key feature vector; response nodes represent the output response features of the API, storing information such as the output parameter name, output parameter type, and data format from the first key feature vector; and data model nodes represent the data model (such as entity class or data structure) that the API parameters / responses depend on, storing information such as the data model name, field composition, and field type.

[0045] Therefore, relevant information about the input parameters is extracted from the first key feature vector, and an independent parameter node is created for each input parameter, with node attributes populated; relevant information about the output parameters is extracted, and response nodes are created, with node attributes populated; the data model that the parameters / responses depend on is identified, and data model nodes are created, with node attributes populated; and a unique identifier is assigned to each first node, which is associated with the corresponding API root node ID to ensure clear node affiliation.

[0046] Then, relationship edges are established based on the declarative relationships between the first nodes, forming an independent first knowledge graph for each API, focusing on the declarative interface features. These relationship edges connect the scattered nodes, forming a semantically related graph structure that reflects the inherent logic of the API's declarative features. Specifically, declarative relationships are inherent connections between the first nodes based on declarative interface features, including three types: parameter ownership relationships: the connection between the API root node and parameter nodes, representing "which input parameters an API has"; response return relationships: the connection between the API root node and response nodes, representing "which output responses an API returns"; and model usage relationships: the connection between parameter / response nodes and data model nodes, representing "a parameter / response depends on a data model".

[0047] Therefore, we establish "parameter ownership relationship" edges between the API root node and parameter nodes, labeling the edges with "owns input parameters," and associating the corresponding parameter node ID with the API root node ID to clarify the ownership relationship between the API and the input parameters; we establish "response return relationship" edges between the API root node and response nodes, labeling the edges with "returns output parameters," and associating the corresponding response node ID with the API root node ID to clarify the association relationship between the API and the output parameters; we establish "model usage relationship" edges between parameter nodes / response nodes and data model nodes, labeling the edges with "depends on model," and associating the corresponding parameter / response node ID with the data model node ID to clarify the dependency relationship between features and the data model; and we add a unique identifier and association basis (such as the corresponding first key feature vector field index) to each relationship edge to ensure that the relationship is traceable.

[0048] It should be noted that redundant first nodes and relation edges can also be removed to ensure that the first knowledge graph structure is concise and logically consistent, thereby improving the efficiency and accuracy of subsequent relationship determination.

[0049] As described above, by transforming API declarative interface features into a knowledge graph, the semantic relationships of API surface features become more explicit, solving the problems of fragmented API features and difficulty in correlation analysis, and providing a clear semantic basis for determining the relationships between API nodes. By splitting parameter nodes, response nodes, and data model nodes and establishing declarative relationship edges, the API interface feature representation becomes more refined, accurately reflecting the API's input and output rules and data model dependencies, improving the depth and accuracy of API feature recognition. By constructing an independent first knowledge graph for each API, the API's declarative features have independent traceability, and subsequent surface relationships between APIs can be quickly determined through graph node comparison, improving the efficiency of API connection relationship determination.

[0050] S3. Based on the association relationship between nodes in the first knowledge graph, determine the first connection relationship between API nodes.

[0051] In one specific embodiment, S3 includes the following steps:

[0052] S31. For any two API nodes, perform node comparison on the first knowledge graph corresponding to the two API nodes to identify whether there are any identical first nodes.

[0053] S32, if there is at least one identical first node, the first connection relationship between the two API nodes is determined to be connected, and the attribute information of the connection edge between the two API nodes is determined according to the node type corresponding to the identical first node. The node type includes data model node, parameter structure node, and security scheme node.

[0054] S33. If there is no identical first node, then the first connection relationship between the two API nodes is determined to be disconnected.

[0055] The core value of the first knowledge graph lies in representing the declarative interface features of the API, while the first node serves as the structured carrier of these features. If two APIs share the same first node in their first knowledge graphs, it indicates that the two APIs share commonalities in data dependencies, parameter rules, or security requirements, thus establishing a basis for surface-level semantic association. Therefore, they can be determined to be connected. Furthermore, the type of the same node directly reflects the dimension of the association. Based on this, connection edge attributes are defined, and auxiliary information is added to the connection edges to improve the interpretability of the association relationship and make the association logic clearer.

[0056] For example, if the same node is a data model node, the connection edge attribute is labeled as "Data Model Association - XXX", where XXX is the data model name; if the same node is a parameter structure node, the connection edge attribute is labeled as "Parameter Structure Association - XXX", where XXX is the parameter name; if the same node is a security scheme node, the connection edge attribute is labeled as "Security Scheme Association - XXX", where XXX is the authentication type; if there are multiple types of the same node, the attribute is labeled as a combination of "Multiple Associations - Data Model + Parameter Structure", etc., to clarify all association dimensions.

[0057] If the first knowledge graphs of two APIs do not have any common first nodes, it means that the first knowledge graphs of the two APIs have no commonalities in core declarative features such as data dependency, parameter rules, and security requirements, and lack the basis for surface semantic association. Therefore, they are determined to be disconnected.

[0058] As described above, by comparing the first knowledge graphs corresponding to different APIs, the common first nodes are identified, thereby inferring the surface semantic relationships between API nodes. By utilizing the logic that the same nodes represent the same / similar interface features, scattered APIs can be associated through common features. Without complex logical reasoning, node association judgment can be completed simply through structured node comparison, which improves the efficiency of large-scale API association analysis and solves the problems of lack of API semantic understanding and difficulty in establishing surface relationships in existing technologies. This provides a basic association link for subsequent API knowledge graph construction.

[0059] S4. Based on the second key feature vector and the contextual relationship of the API, construct the second knowledge graph, which contains API nodes and associated business nodes, technical nodes, and security nodes.

[0060] In one specific embodiment, S4 includes the following steps:

[0061] S41, based on the second key feature vector, extract API endpoint configuration information and associated service component information.

[0062] S42, Analyze the code structure and configuration information to determine the contextual relationships between APIs, wherein the contextual relationships include at least one of the following: code structure attribution, business module subordination, and technology dependency.

[0063] S43 uses API nodes, business nodes, technical nodes, and security nodes as second nodes, and establishes semantic connection edges between the second nodes based on contextual relationships to construct the second knowledge graph.

[0064] Contextual relationships, specifically those between APIs and other components, and between APIs themselves, are based on runtime environment, business logic, and technical architecture. These relationships serve as the basis for constructing semantic connection edges between second-level nodes and can reveal the deep-seated logic of API relationships. Specifically, contextual relationships include three categories: code structure attribution (the attribution relationship between the API and code organization units); business module attribution (the attribution relationship between the API and business function modules); and technology dependency (the dependency relationship between the API and technical components or other APIs).

[0065] The second key feature vector is obtained based on configuration file parsing. Since configuration files are the core carrier of API runtime environment and dependencies, extracting API endpoint configurations and associated service component information clarifies the API's operational foundation and technical dependencies, providing data support for subsequent contextual relationship mining. Specifically, framework annotation information and routing mapping rules are filtered from the second key feature vector to clarify endpoint configuration information such as endpoint identifiers, controller binding relationships, and parameter passing rules for each API; service dependency configurations and module association parameters are filtered to identify middleware, external service components, and their associated technical modules; and association identifiers (such as unique API IDs and component type tags) are added to the extracted information to form a mapping table of "API-configuration information-service component information," ensuring that the information is traceable and associative.

[0066] The contextual relationships of APIs are hidden in the code structure (such as package paths and class organization) and configuration information. By integrating and analyzing these two types of information, we can uncover the inherent relationships between APIs at the levels of code organization, business functions, and technical architecture, and realize the transformation from "isolated APIs" to "connected API networks".

[0067] Specifically, the process involves analyzing the package paths and class definitions of the source code to identify the controller classes and package names corresponding to the APIs. This establishes a mapping between APIs and code organization units, determining the "same package" and "same class" relationships between APIs, and thus defining the code structure hierarchy. Based on module association parameters and code directory structure in the configuration files, the process infers the business module to which the API belongs, identifies APIs that interact across modules, and determines the "cross-module collaboration" relationship between APIs based on inter-module interface configurations, thereby defining the business module hierarchy. Finally, based on service component information, the process identifies the technical components that the APIs depend on, determines the "common dependencies" between APIs, identifies direct calls from APIs to other APIs, determines "direct call" dependencies, and thus defines the technical dependencies.

[0068] The second node covers APIs and entities across business, technology, and security dimensions. Contextual relationships form the natural connection logic between second nodes. By establishing semantic connection edges, the scattered second nodes can be linked together into a structured graph, enabling visualization and analysis of API association logic and attributes, and providing a platform for subsequent candidate path selection and structural connectivity verification.

[0069] Specifically, using the unique API identifier as the core, endpoint configuration information is supplemented and linked to the first knowledge graph index to ensure association with API nodes in the first knowledge graph. Based on the hierarchical relationships of business modules, business nodes, including business line nodes and business module nodes, are created, with attributes including module identifier, business function description, and affiliated business line. Based on associated technical component information, technical nodes, including middleware nodes and service component nodes, are created, with attributes including component name, type, and configuration parameters. Based on security configurations in the configuration file, security nodes, including authentication mechanism nodes and authorization policy nodes, are created, with attributes including security mechanism type and configuration rules.

[0070] Based on code structure attribution, API nodes establish "subordinate" type edges with their respective business module nodes, with edge attributes indicating package path and controller class name; based on business module attribution, business module nodes within the same business line establish "same business line" type edges, and API nodes collaborating across modules establish "cross-module collaboration" type edges through business module nodes; based on technology dependency, API nodes establish "dependency" type edges with their dependent technology nodes, with edge attributes indicating dependency method, and API nodes with common dependencies establish "common dependency association" type edges through technology nodes; and API nodes establish "adopt security policy" type edges with their corresponding security nodes, with edge attributes indicating security configuration rules.

[0071] It should be noted that redundant second nodes and semantic connection edges can also be removed to ensure that the second knowledge graph structure is concise and logically consistent, thereby improving the efficiency and accuracy of subsequent relationship determination.

[0072] As described above, by integrating the second key feature vector with contextual relationships, the fragmented state of information in configuration files and code structures is broken, making the runtime association logic of the API clearer and solving the problem of the separation between static and dynamic analysis in existing technologies. By defining second nodes of multiple types such as business, technology, and security, a structured representation of the API's multi-dimensional attributes is realized, making up for the limitation of the first knowledge graph, which only focuses on declarative features, and making the API asset profile more complete. By establishing semantic connection edges based on contextual relationships, the association logic between the API and business modules, technical components, and security policies is made explicit, making the deep association of the API traceable and analyzable, and enhancing the semantic value of the second knowledge graph. Through the complementary operation of the second knowledge graph and the first knowledge graph, a two-layer data support of "declarative features + runtime association" is formed, laying a comprehensive and three-dimensional foundation for the construction of the final API knowledge graph.

[0073] S5. Based on the target structure tree, verify the code structure connectivity of each candidate path in the second knowledge graph that satisfies the consistency of preset attributes, and determine the second connection relationship between API nodes. The preset attributes include at least one of business attributes, technical attributes, and security attributes.

[0074] Among them, the preset attributes are the core attribute dimensions used to filter candidate paths, which correspond one-to-one with the node attributes of the second knowledge graph. Specifically, they include: business attributes that represent the business affiliation and functional positioning of the node, such as business line identifier, business module, and business function keywords; technical attributes that represent the technical architecture and dependency characteristics of the node, such as the microservice to which it belongs, the type of middleware it depends on, the technical protocol, and the code package path; and security attributes that represent the security policy and data protection requirements of the node, such as authentication mechanism, authorization level, and data sensitivity.

[0075] The above-mentioned approach combines the preset attribute consistency screening of the second knowledge graph with the code logic connectivity verification of the target structure tree to achieve accurate determination of deep associations between API nodes. By utilizing the dual logic of "attribute consistency representing association potential and code connectivity verifying actual associations", the approach solves the problem of misjudgment of associations caused by existing technologies that rely solely on surface features or a single analysis dimension. This ensures that the second connection relationship conforms to the actual operation logic of the API and provides a reliable deep association link for the final knowledge graph.

[0076] In one specific embodiment, S5 includes the following steps:

[0077] S51: For any two API nodes, find several initial paths between the two API nodes in the second knowledge graph.

[0078] S52, if all second nodes on the same initial path have at least one preset attribute that is completely identical, then the initial path is determined as a candidate path.

[0079] S53, for any candidate path, obtain the source code location corresponding to each second node on the current candidate path from the source code.

[0080] S54, locate the structure block corresponding to the source code location in the target structure tree.

[0081] S55, if all structural blocks corresponding to the current candidate path are continuous in the target structure tree or connected through a preset structure, then the second connection relationship between the two API nodes is determined to be connected, and the attribute information of the connection edge includes the same preset attribute corresponding to the current candidate path.

[0082] S56. If any structural block in the current candidate path is logically broken from other structural blocks, then the second connection relationship between the two API nodes is determined to be disconnected.

[0083] The second knowledge graph includes API nodes and various types of second nodes such as business, technology, and security nodes, as well as semantic connection edges between nodes. These edges constitute potential association links between API nodes. Path search can uncover all possible initial paths, providing comprehensive candidate objects for subsequent attribute screening and structural verification. Those skilled in the art will recognize that any graph path search algorithm in the prior art falls within the protection scope of this invention, such as depth-first search algorithm and breadth-first search algorithm, and will not be elaborated upon here.

[0084] An initial path may contain various combinations such as "API node → business node → API node" or "API node → technology node → security node → API node". Consistent pre-defined attributes are a prerequisite for deep connections between API nodes. If all second nodes on an initial path maintain consistent attributes in the business, technical, or security dimensions, it indicates that all second nodes belong to the same logical system, and the corresponding API nodes are more likely to have an actual connection. Conversely, the probability of a connection is extremely low, requiring no further verification. This process filters out candidate paths with potential connections, eliminates invalid initial paths without common attributes, focuses on core verification objects, and improves the efficiency of subsequent code structure connectivity verification.

[0085] Each second node has a corresponding source code implementation. Obtaining the source code location allows us to associate graph nodes with actual code logic, providing a basis for subsequent structural block location. The target structure tree is a fusion of an abstract syntax tree and a control flow graph, possessing both the syntactic structure and execution logic of code. Its nodes have a one-to-one correspondence with source code fragments. Therefore, the corresponding structural block can be accurately located through the source code location, transforming surface path verification into underlying code logic verification. This further transforms candidate paths from graph node links into code structural block links, providing specific verification objects for subsequent code structure connectivity verification, thus grounding association determination in code logic.

[0086] The connectivity of structural blocks in the target tree structure directly reflects the actual relationships at the code level. If structural blocks are continuous or connected through preset structures (such as the same module or control flow jumps), it indicates that the corresponding second nodes are closely related in code logic, thus inferring a deep actual relationship between API nodes. Consistent preset attributes clarify the dimension of the relationship. If structural blocks on the candidate path have logical breaks (such as belonging to different modules and having no control flow relationship or no preset structure connection), it indicates that the corresponding second nodes have no actual relationship at the code level. Even if they have consistent attributes, it is only a superficial commonality and does not constitute a true deep relationship. Therefore, verifying the deep relationships between API nodes based on code logic ensures the authenticity and reliability of the second connection relationship, while clarifying the relationship dimension, providing core information for the edge attributes of the final knowledge graph.

[0087] The preset structure refers to predefined code organization units or connection rules with fixed logical relationships within the target structure tree. These are used to determine whether structural blocks on candidate paths, though not directly continuous, form a substantial relationship through underlying code logic or architectural design, ensuring that code structure connectivity verification aligns with actual programming scenarios and framework characteristics. Examples include: preset structures for code organization including the same module package / directory structure, the same controller / service class structure, and parent / child class / interface implementation structure; preset structures for logical dependency relationships including control flow jump relationships, method call chain relationships, and data dependency relationships; preset structures for framework configuration relationships including framework annotation relationships, route mapping relationships, and middleware / service dependency relationships; and preset structures for security policy relationships including relationships within the same security domain and data anonymization / encryption relationships.

[0088] The aforementioned preset structure covers multiple code association scenarios, including static organization, dynamic logic, framework configuration, and security policies. It is suitable for API association logic in regular projects and can also solve the problem of determining whether structural blocks in complex frameworks and dynamic routing are not directly continuous but have substantial relationships. This ensures that the determination of the second connection relationship is more in line with the actual code execution logic.

[0089] The above-mentioned dual judgment through attribute consistency screening and code structure connectivity verification makes the deep association judgment between API nodes more accurate, solving the problem of misjudgment and omission of association caused by relying on only a single dimension in the existing technology, and ensuring that the second connection relationship fits the actual operation logic. By mining multiple paths and screening candidate paths in the second knowledge graph, the potential association scenarios between API nodes are fully covered, avoiding the omission of key deep association links and improving the integrity of the second connection relationship. By locating structural blocks and verifying connectivity through the target structure tree, the association verification at the graph level is transformed into the substantive verification at the code logic level, making up for the defects of static analysis and dynamic logic separation, and making the association judgment more convincing. By clarifying the attribute information of the connection edge, the association dimension of the second connection relationship is clearer, not only clarifying whether it is connected, but also reflecting on what attribute it is connected on, providing richer information for the semantic query and association analysis of the final knowledge graph.

[0090] S6 constructs an API knowledge graph based on the first and second connection relationships between API nodes.

[0091] In one specific embodiment, S6 includes the following steps:

[0092] S61, perform conflict detection on the first and second connection relationships, and generate an API connection relationship set.

[0093] S62, merge and deduplicate the API nodes in the first and second knowledge graphs to construct an API node set.

[0094] S63, Based on the API connection relationship set, establish fusion relationship edges between API nodes, wherein the fusion relationship edge includes relationship type and source identifier, wherein the source identifier includes first connection relationship source, second connection relationship source, fusion source, and adjudication source.

[0095] S64 injects technical attributes, security attributes, and business attributes into each API node to form a unified API knowledge graph.

[0096] The first connection focuses on surface-level declarative feature associations, while the second connection focuses on deep code structure and attribute associations. These two may have conflicting connectivity states (e.g., one connected, the other disconnected). Conflict detection and adjudication ensure the accuracy of the final associations and avoid contradictions in the graph's association logic. Specifically, the first connection (including connectivity state, same first node type, and association basis) and the second connection (including connectivity state, consistent preset attributes, and structural block connectivity verification results) are formatted in a unified way, clearly defining core fields such as API node pairing, connectivity state, association basis, and source type. Using API node pairing as a unique index, if the connectivity states of two connections within the same pair are inconsistent, they are considered conflicting; if they are consistent, they are considered non-conflicting. Conflicting connections are adjudicated, and the adjudicated connections are added to the API connection set, providing a standardized and conflict-free association basis for constructing fused relationship edges, ensuring the consistency of the graph's association logic.

[0097] Although API nodes in the first and second knowledge graphs correspond to the same entity, they may suffer from fragmented attributes and inconsistent identification. Merging and deduplication enables unique management of API nodes, preventing duplicate entities in the API knowledge graph and ensuring the accuracy of asset inventory. Specifically, a unique API identifier (such as API name + core feature vector hash value, or unique interface ID) is used as the deduplication key to ensure that only one node is retained for the same API; the attribute information of the same API node in the two knowledge graphs is merged to form initial node attributes; a globally unique ID is assigned to each deduplicated API node, associated with the first / second key feature vector index and the initial node attributes, constructing a unified and uniquely identified set of API nodes.

[0098] Fusion relationship edges are a structured representation of the association logic between API nodes. It is necessary to clearly define the association type (why the connection is established) and the source identifier (where the association originates) to ensure the clarity of the association logic and provide support for subsequent association tracing. Specifically, based on the association criteria of the API connection relationship set, fusion relationship types are defined. Surface-level associations correspond to the first type of connection, such as "association based on the same data model" or "association based on the same parameter structure"; deep-level associations correspond to the second type of connection, such as "association based on consistent business attributes" or "association based on technical dependence"; fusion-level associations correspond to connections where both types of connection are connected and semantically compatible, such as "dual association of surface features and deep structure".

[0099] At the same time, source identifiers are marked according to the origin and processing method of the connection relationship. The first connection relationship source means that only the first connection relationship is determined to be connected; the second connection relationship source means that only the second connection relationship is determined to be connected; the fusion source means that both types of connection relationships are connected and semantically compatible, without conflict; the adjudication source means that there is a conflict between the two types of connection relationships, and the connection is determined after adjudication.

[0100] Furthermore, for each pair of connected API nodes in the API connection relationship set, a fusion relationship edge is established, binding the relationship type and source identifier, and associating the corresponding connection relationship adjudication / fusion basis, thereby making the fusion relationship logic between API nodes explicit, realizing the traceability of the relationship, and providing structured support for the association analysis and path query of the API knowledge graph.

[0101] The attributes of API nodes are the core embodiment of their asset value. It is necessary to integrate multi-dimensional attributes from the first knowledge graph, the second knowledge graph, and the attribute reasoning process to ensure the complete profile of each API node and meet the needs of scenarios such as asset inventory and risk analysis. Specifically, technical attributes include declarative features from the first knowledge graph and technical dependencies from the second knowledge graph; business attributes include business module subordination relationships and functional descriptions extracted from code comments / method names from the second knowledge graph; security attributes include security node association information and data sensitivity reasoning results from the second knowledge graph. If the same attribute from different sources differs (e.g., the input parameter constraints in the API definition file and code parsing are inconsistent), the code parsing result (association information from the second knowledge graph) shall prevail, and the attribute source shall be marked. The integrated multi-dimensional attributes are injected into the corresponding API nodes, and combined with the API node set and the fusion relationship edge set, a unified API knowledge graph containing "node-edge-attribute" is formed, supporting operations such as node attribute query, relationship tracing, and path search.

[0102] The above-mentioned methods, through the detection and fusion of two types of connection conflicts, solve the problems of fragmented and logically contradictory API relationships, making the relationships between API nodes more unified and reliable, and providing a solid topological foundation for the construction of the API knowledge graph. By fusing relationship edge binding relationship types and source identifiers, the API relationship logic becomes clearer and more traceable, making it easier for users to understand the essence and source of the relationships, thus improving the practicality and credibility of the API knowledge graph. By injecting complete multi-dimensional attributes, the shortcomings of incomplete attributes in a single knowledge graph are compensated for, making the API asset profile more comprehensive and supporting asset query and analysis from multiple dimensions such as technology, business, and security.

[0103] In one specific embodiment, S61 includes the following steps:

[0104] S611, for any two API nodes, if the first connection relationship between the two API nodes is connected and the second connection relationship is not connected, or the first connection relationship is not connected and the second connection relationship is connected, then add the first connection relationship or the second connection relationship to the API connection relationship set.

[0105] S612, if the first connection relationship and the second connection relationship of the two API nodes are both disconnected, then add the disconnected relationship to the API connection relationship set.

[0106] S613 If the first connection relationship and the second connection relationship of the two API nodes are both connected, then check whether the relationship types of the first connection relationship and the second connection relationship are semantically compatible.

[0107] S614, if semantically compatible, then merge the first connection relationship and the second connection relationship to generate a merged connection relationship and add it to the API connection relationship set.

[0108] S615, if the semantics are incompatible, then the relationship is adjudicated based on the sufficiency of evidence corresponding to the first connection relationship and the second connection relationship and the verification result of the target structure tree, and the adjudicated connection relationship is added to the API connection relationship set.

[0109] Among them, semantically compatible dual connectivity relationships, whose association logic complements each other, can form a more comprehensive and persuasive connection relationship after fusion, improving the association depth and interpretability of the knowledge graph. Specifically, if semantically compatible, the type labels of the two types of connection relationships are merged to form a combined relationship type (such as "same source data model + consistent business attribute association"). The "same node information" of the first connection relationship is merged with the "consistent attribute details + structural block connectivity result" of the second connection relationship to form a complete association basis chain. At the same time, it is marked as "fusion source", which clearly indicates that the association relationship is generated by the fusion of the two types of connection relationships, and the fused connection relationship is included in the API connection relationship set.

[0110] Semantically incompatible dual connectivity relationships present logical contradictions and must be adjudicated based on reliability priority and evidentiary sufficiency to ensure the accuracy of the final relationship and avoid logical conflicts in the knowledge graph. Specifically, the evidentiary sufficiency of the first connectivity relationship = number of identical first nodes / total number of first nodes × 100%; the evidentiary sufficiency of the second connectivity relationship = number of consecutive structural blocks / total number of structural blocks in candidate paths × 100%. The target structure tree verification result (second connectivity relationship) has higher priority than surface feature matching (first connectivity relationship).

[0111] For example, if the sufficiency of evidence for the second connection relationship is greater than or equal to a preset threshold, the second connection relationship is adopted regardless of the sufficiency of evidence for the first connection relationship, and is marked "Source of Ruling - Priority Code Logic Verification"; if the sufficiency of evidence for the second connection relationship is less than the preset threshold, and the sufficiency of evidence for the first connection relationship is greater than or equal to the preset threshold, the first connection relationship is adopted, and is marked "Source of Ruling - Priority Core Feature Matching"; if the sufficiency of evidence for both is less than the preset threshold, it is marked as "Pending Manual Review," and the original data and evidence details of both types of relationships are retained and included in the API connection relationship set. The specific value of the preset threshold can be set by the implementer according to the actual situation, for example, 60%.

[0112] It should be noted that the connection relationships included in the API connection relationship set can be deduplicated and standardized in format to ensure that each API node pairing in the API connection relationship set retains only one final connection relationship, thereby improving the standardization and usability of the API connection relationship set.

[0113] The above-mentioned processing logic, covering all scenarios of single connectivity, dual disconnection, and dual connectivity (compatible / incompatible), makes the collection of API connection relationships more complete, avoiding omissions or misjudgments of key associations; through semantic compatibility verification and evidence sufficiency quantification, the processing of dual connectivity relationships is made more accurate, integrating complementary logic and resolving contradictions, thereby improving the reliability of connection relationships; through the integration of association criteria and source identification, the traceability of connection relationships is strengthened, and each relationship can be traced back to the original data and processing process, improving the credibility of the API knowledge graph.

[0114] The above-mentioned approach, by parsing three core data types—source code, API definition files, and configuration files—avoids API identification omissions caused by reliance on a single data source, resulting in more complete API asset identification. The first knowledge graph represents the declarative interface features of the API, transforming surface features such as API input parameters, output parameters, and data models into structured semantic relationships. The second knowledge graph integrates multiple types of nodes related to business, technology, and security, uncovering deep contextual relationships and multi-dimensional attributes of the API, leading to more accurate API semantic understanding and a more comprehensive asset profile, fully covering the core dimensions of technology, business, and security. The target structure tree verifies code structure connectivity, combining graph path filtering with underlying code logic verification, avoiding the misjudgments and omissions of traditional pattern matching. Furthermore, the knowledge graph is constructed through the fusion of two-layer connections, breaking down the information barriers between static declarative features and dynamic runtime relationships, making API relationship determination more reliable and ensuring that the relationship logic better aligns with actual operational scenarios.

[0115] Example 2

[0116] Embodiment 2 of the present invention provides a non-transitory computer-readable storage medium, which can be disposed in an electronic device to store at least one instruction or at least one program related to implementing a method in the method embodiment. The at least one instruction or at least one program is loaded and executed by the processor to implement the API knowledge graph construction method provided in the above embodiment.

[0117] Example 3

[0118] Embodiment 3 of the present invention provides an electronic device, which includes a processor and the non-transitory computer-readable storage medium of Embodiment 2 of the present invention.

[0119] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A method for constructing an API knowledge graph, characterized in that, The API knowledge graph construction method includes the following steps: S1, parse the source code, API definition file and configuration file of the project to be analyzed, and obtain the target structure tree corresponding to the source code, the first key feature vector corresponding to each API declared in the API definition file and the second key feature vector corresponding to the configuration file; S2, construct a first knowledge graph for each API based on the first key feature vector corresponding to each API, wherein the first knowledge graph is used to represent the declarative interface features of the API; S3, Based on the association relationship between nodes in the first knowledge graph, determine the first connection relationship between API nodes; S4. Based on the second key feature vector and the contextual relationship of the API, construct a second knowledge graph, wherein the second knowledge graph contains API nodes and associated business nodes, technical nodes, and security nodes; S5, based on the target structure tree, verify the code structure connectivity corresponding to each candidate path in the second knowledge graph that satisfies the preset attribute consistency, and determine the second connection relationship between API nodes, wherein the preset attribute includes at least one of business attribute, technical attribute, and security attribute. S5 includes the following steps: S51, for any two API nodes, find several initial paths between the two API nodes in the second knowledge graph; S52, if all second nodes on the same initial path have the same at least one preset attribute, then the initial path is determined as a candidate path. S53, for any candidate path, obtain the source code location corresponding to each second node on the current candidate path from the source code; S54, Locate the structural block corresponding to the source code location in the target structure tree; S55, if all structural blocks corresponding to the current candidate path are continuous in the target structure tree or connected through a preset structure, then the second connection relationship between the two API nodes is determined to be connected, and the attribute information of the connection edge includes the same preset attribute corresponding to the current candidate path. S56. If any structural block in all structural blocks corresponding to the current candidate path is logically broken with other structural blocks, then the second connection relationship between the two API nodes is determined to be disconnected. S6 constructs an API knowledge graph based on the first and second connection relationships between API nodes.

2. The API knowledge graph construction method according to claim 1, characterized in that, S1 includes the following steps: S11, perform lexical analysis and syntax analysis on the source code to obtain the abstract syntax tree corresponding to the source code; S12, perform control flow analysis on the abstract syntax tree to obtain the control flow graph corresponding to the source code; S13, map and merge the syntax nodes in the abstract syntax tree and the control nodes in the control flow graph to obtain the target structure tree; S14, parse the description information of each API declared in the API definition file to obtain the first key feature vector corresponding to each API, wherein the first key feature vector includes at least one of the following: API name, input parameter type, input parameter constraint, output parameter type, data format, data model name, field composition, and field type; S15, parse the configuration file to obtain a second key feature vector, wherein the second key feature vector includes at least one of framework annotation information, routing mapping rules, service dependency configuration and module association parameters.

3. The API knowledge graph construction method according to claim 1, characterized in that, S2 includes the following steps: Based on the first key feature vector, with the API node as the root node, and the parameter node, response node, and data model node as the first node, relationship edges are established between the API node and the first node, and between the first nodes, to construct a first knowledge graph. The declarative relationship includes at least one of parameter ownership relationship, response return relationship, and model usage relationship.

4. The API knowledge graph construction method according to claim 3, characterized in that, S3 includes the following steps: S31, For any two API nodes, perform node comparison on the first knowledge graph corresponding to the two API nodes to identify whether there are any identical first nodes; S32, if there is at least one identical first node, the first connection relationship between the two API nodes is determined to be connected, and the attribute information of the connection edge between the two API nodes is determined according to the node type corresponding to the identical first node. The node type includes data model node, parameter structure node, and security scheme node. S33. If there is no identical first node, then the first connection relationship between the two API nodes is determined to be disconnected.

5. The API knowledge graph construction method according to claim 1, characterized in that, S4 includes the following steps: S41, Based on the second key feature vector, extract the API endpoint configuration information and associated service component information; S42, Analyze the code structure and configuration information to determine the contextual relationships between APIs, wherein the contextual relationships include at least one of code structure attribution, business module subordination, and technology dependency. S43, using API nodes, business nodes, technology nodes, and security nodes as second nodes, and establishing semantic connection edges between the second nodes based on the contextual relationships, a second knowledge graph is constructed.

6. The API knowledge graph construction method according to claim 1, characterized in that, S6 includes the following steps: S61, perform conflict detection on the first connection relationship and the second connection relationship, and generate an API connection relationship set; S62, merge and deduplicate the API nodes in the first and second knowledge graphs to construct an API node set; S63, Based on the API connection relationship set, establish fusion relationship edges between API nodes, wherein the fusion relationship edge includes a relationship type and a source identifier, wherein the source identifier includes a first connection relationship source, a second connection relationship source, a fusion source, and a ruling source; S64 injects technical attributes, security attributes, and business attributes into each API node to form a unified API knowledge graph.

7. The API knowledge graph construction method according to claim 6, characterized in that, S61 includes the following steps: S611, for any two API nodes, if the first connection relationship between the two API nodes is connected and the second connection relationship is not connected, or the first connection relationship is not connected and the second connection relationship is connected, then add the first connection relationship or the second connection relationship to the API connection relationship set. S612, If the first connection relationship and the second connection relationship of the two API nodes are both disconnected, then add the disconnected relationship to the API connection relationship set; S613, If the first connection relationship and the second connection relationship of the two API nodes are both connected, then check whether the relationship types of the first connection relationship and the second connection relationship are semantically compatible; S614, if semantically compatible, then merge the first connection relationship and the second connection relationship to generate a merged connection relationship and add it to the API connection relationship set; S615, if the semantics are incompatible, then the relationship is adjudicated based on the sufficiency of evidence corresponding to the first connection relationship and the second connection relationship and the verification result of the target structure tree, and the adjudicated connection relationship is added to the API connection relationship set.

8. A non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores at least one instruction or at least one program segment, characterized in that, The at least one instruction or the at least one program segment is loaded and executed by the processor to implement the API knowledge graph construction method as described in any one of claims 1-7.

9. An electronic device, characterized in that, Includes a processor and the non-transitory computer-readable storage medium as described in claim 8.

Images