API full-life-cycle intelligent treatment method and system based on multi-modal data perception and blood relationship atlas

Abstract

The invention relates to the technical field of distributed system security and intelligent operation and maintenance, in particular to an API full-life-cycle intelligent treatment method and system based on multi-modal data perception and a blood relationship atlas, and the method comprises the steps: S1, collecting network traffic in a non-intrusive mode, automatically discovering an API, extracting metadata features, and generating an API change event; s2, performing semantic analysis on the API metadata based on a natural language processing technology, calculating a sensitivity score, and performing marking alarm on a high-risk interface; s3, constructing an API blood relationship map, and carrying out change influence analysis and risk assessment based on the map; s4, risk simulation is carried out on API changes based on flow playback, and plan changes are tested in a layered sandbox environment; and S5, automatically generating a document conforming to an open API specification based on the API metadata, and synchronously updating in real time. All links are connected in series to form a closed-loop governance system through the event-driven engine, automatic and intelligent governance of API assets is achieved, and the safety, stability and operation and maintenance efficiency of the system are improved.

Description

A method and system for intelligent governance of the entire lifecycle of APIs based on multimodal data perception and lineage mapping Technical Field

[0001] This invention relates to the fields of distributed systems and intelligent operation and maintenance technology, and in particular to an API full lifecycle intelligent governance method, system, device and storage medium based on multimodal data perception and lineage mapping. Background Technology

[0002] With microservice architecture becoming the mainstream paradigm in modern software development, the number and complexity of Application Programming Interfaces (APIs) have exploded. Against this backdrop, traditional API governance solutions are proving inadequate, exposing numerous serious challenges, specifically in the following aspects: 1) Proliferation of zombie APIs, expanding security blind spots: During system iteration, a large number of obsolete, invalid, or unmanaged APIs (i.e., "zombie APIs") are generated. Traditional governance methods lack effective automated discovery and removal mechanisms. These APIs persist in the system for a long time, cannot be effectively monitored and managed, and become favored entry points for attackers, greatly expanding the system's attack surface; 2) Weak sensitivity data leakage detection capabilities and high false negative rates: Existing sensitive information detection solutions mostly rely on static keyword or regular expression matching. This method struggles to understand the contextual semantics of APIs and cannot effectively identify sensitive data that has been transformed, encoded, or exists in complex business scenarios, resulting in low accuracy and high false negative rates, failing to meet increasingly stringent data compliance requirements; 3) Changes trigger cascading failures, lack of prior risk assessment: API changes are one of the main causes of online failures. Currently, there is a lack of capability to analyze the pre-emptive impact of API changes, especially for complex inter-service dependencies, making it difficult to quantify and assess the impact of changes on downstream callers. A minor interface change can trigger a large-scale online cascading failure due to incompatibility with downstream services, severely impacting business stability; 4) API documentation is severely outdated and maintenance costs are high: API documentation maintenance heavily relies on manual updates by developers, a cumbersome process prone to oversights, resulting in a significant disconnect between documentation and the actual implementation of the interface. This inconsistency greatly affects the efficiency of collaboration between front-end and back-end teams, and between multiple teams, and introduces potential technical and business risks due to information opacity.

[0003] Currently, some technical solutions on the market have limited functionality, often providing isolated solutions to only one of the aforementioned problems. For example, some tools focus on API gateway management, some on security scanning, and some on document generation. These solutions are fragmented, data cannot be shared, and they form isolated governance silos.

[0004] Therefore, existing technologies lack an integrated, automated, and intelligent governance platform that can cover the entire lifecycle of an API, from its creation, operation, modification, to its decommissioning. There is an urgent need for a systematic approach that can organically unify API asset governance, security analysis, dependency management, change control, and documentation maintenance, forming a closed-loop governance system integrating perception, analysis, decision-making, and execution. This system would systematically address the challenges faced by distributed systems in terms of security, stability, and operational efficiency. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by providing an intelligent API lifecycle governance method based on multimodal data perception and lineage mapping, comprising the following steps: S1: Collecting network traffic non-intrusively, automatically discovering APIs and extracting metadata features, and generating API change events including event type, API identifier, and feature differences when a new API or a change in the features of an existing API is detected; S2: Performing semantic analysis on the metadata features of the APIs based on natural language processing technology, calculating the API sensitivity score, and marking and alerting high-risk interfaces whose sensitivity scores reach a preset threshold; S3: Constructing an API lineage mapping, and when the API change event is received, performing change impact analysis based on the API lineage mapping, and conducting risk assessment in conjunction with the sensitivity score; S4: Performing risk simulation of API changes based on traffic replay, testing the planned changes of the APIs in a layered sandbox environment, and determining the change risk level based on comprehensive indicators; S5: Automatically generating API documents that conform to open API specifications based on the extracted API metadata, and updating the API documents in real time when the API change event is triggered.

[0006] Preferably, in step S1, the non-intrusive collection of network traffic, automatic API discovery, and extraction of metadata features includes: deploying a probe based on extended Berkeley Packet Filtering (eBPF) technology; capturing network packets in kernel mode via the probe in a bypass manner; analyzing the load characteristics of network packets using deep packet inspection technology to identify application layer protocols; for identified RESTful APIs, extracting URL paths, methods, and parameter names from their requests, and dynamically inferring parameter types based on parameter value pattern recognition; for identified gRPC protocols, prioritizing the acquisition of interface definition files through the integration service registry for accurate deserialization; when the interface definition files are unavailable, inferring message field structures based on the gRPC protocol structure and traffic samples using pattern recognition technology; and using a Bloom filter to quickly deduplicate identified APIs, combined with persistent storage for secondary verification to ensure deduplication accuracy.

[0007] Preferably, in step S2, the semantic analysis of the API's metadata features based on natural language processing technology to calculate the API's sensitivity score includes: cleaning and normalizing the path, parameter names, and return field names in the API's metadata features, and concatenating them into a text sequence; encoding the text sequence using a pre-trained language model trained through transfer learning, capturing the semantic relationships between elements in the text sequence using a self-attention mechanism, and outputting the API's sensitivity score through the classification layer of the pre-trained language model; setting a configurable sensitivity threshold, automatically marking the API as a high-risk interface and triggering an alarm when the sensitivity score exceeds the preset threshold; introducing a feedback learning closed-loop mechanism, using the correction information of the marking results by the operation and maintenance personnel as new labeled data, and incrementally learning the pre-trained language model based on the new labeled data to optimize the model's scoring accuracy.

[0008] Preferably, in step S3, an API lineage graph is constructed. When the API change event is received, a change impact analysis is performed based on the API lineage graph, including: aggregating multi-source data from a distributed tracing system, application performance monitoring tools, and the service mesh control plane to construct an API lineage graph with an attribute graph structure; in the API lineage graph, microservices, API endpoints, and databases are used as nodes, and calls and dependencies are used as directed edges. Nodes and directed edges are attached with operation and maintenance attributes including sensitivity scores, QPS, and average latency; when an API change event is received, starting from the node in the API lineage graph corresponding to the changed API, a weighted graph traversal algorithm is executed, prioritizing the traversal of core dependency edges, quantifying and statistically analyzing the number of downstream affected nodes and the proportion of core business applications, and completing the change impact analysis.

[0009] Preferably, in step S4, the risk simulation of API changes based on traffic replay includes: continuously recording API business traffic in the production environment, desensitizing sensitive data in the traffic and storing it using a compression algorithm, and constructing a high-fidelity test case library containing historical request characteristics; defining API change rules through a declarative rule engine, applying the API change rules to the historical request data in the test case library, and generating test requests simulating API changes; performing traffic replay in a layered sandbox: routing test requests from the core business link to the pre-release environment, and using a smart Mock service trained based on historical traffic recording data to simulate responses to downstream dependencies of non-core businesses; monitoring downstream response indicators in real time during the traffic replay process, and determining a high-risk change when any of the following conditions are met: if the 5xx error rate exceeds the error threshold; if the response latency P95 exceeds the latency threshold; or if the smart Mock detects an unrecognizable request pattern.

[0010] Preferably, in step S5, an API document conforming to the Open API Specification is automatically generated based on the extracted API metadata, and the API document is updated in real time when the API change event is triggered. This includes: mapping the extracted API metadata features to the OpenAPI Specification model to automatically generate an API definition file conforming to the OAS standard; when source code access is available, static code analysis technology is used to parse the abstract syntax tree of the source code, extract the comment information in the code, and fill the comment content into the API definition file to improve the document description; when an API change event is received, the document update process is automatically started, the API definition file is updated based on the latest API metadata after the change, and the updated API definition file is published to the integrated document platform to achieve real-time document synchronization; interface compatibility issues identified during the API change risk simulation process are recorded in a structured manner as historical risk points, and the attribute information associated with the corresponding API node in the API lineage graph is fed back.

[0011] Preferably, the method further includes a closed-loop feedback step: collecting issues discovered in API change risk simulation, including compatibility problems, response anomalies, and request pattern mismatches, and recording them as historical risk points in a structured manner, storing them in the attribute fields of the corresponding API nodes in the API lineage graph; when a change event triggering the same API is detected, querying the historical risk points recorded in the API lineage graph, and assigning a higher risk warning weight to the current change of the API based on the number, severity, and scope of related business impact of the historical risk points; establishing a continuous feedback learning mechanism, inputting historical risk point data, change risk assessment results, and manual intervention records of operations and maintenance personnel as training data into the API change governance system, and achieving self-optimization of the system's risk identification accuracy, assessment model parameters, and governance rules through knowledge accumulation.

[0012] Based on the same concept, this invention also provides an intelligent API lifecycle governance system based on multimodal data perception and lineage mapping, comprising: a non-intrusive API perception and asset governance module, which collects network traffic in a non-intrusive manner, automatically discovers APIs and extracts metadata features, and generates API change events including event type, API identifier, and feature differences when a new API or a change in the features of an existing API is detected; an intelligent semantic security analysis module, which performs semantic analysis on the metadata features of the API based on natural language processing technology, calculates the sensitivity score of the API, and marks and alerts high-risk interfaces whose sensitivity scores reach a preset threshold; a dependent topology discovery and impact assessment module, which constructs an API lineage mapping, performs change impact analysis based on the API lineage mapping when the API change event is received, and performs risk assessment in conjunction with the sensitivity score; a change security simulation and verification module, which performs risk simulation of API changes based on traffic replay, tests the planned changes of the API in a layered sandbox environment, and determines the change risk level based on comprehensive indicators; and an automated API documentation module, which automatically generates API documentation that conforms to open API specifications based on the extracted API metadata, and updates the API documentation in real time when the API change event is triggered.

[0013] Based on the same concept, the present invention also provides a computer device, including a memory and a processor, wherein the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, the processor causes the processor to perform the steps of an API full lifecycle intelligent governance method based on multimodal data perception and lineage mapping as described in the embodiments.

[0014] Based on the same concept, the present invention also provides a storage medium storing computer-readable instructions, characterized in that, when the computer-readable instructions are executed by one or more processors, the one or more processors cause the one or more processors to perform the steps of the API full lifecycle intelligent governance method based on multimodal data perception and lineage mapping as described in any one of the embodiments.

[0015] Compared with existing technologies, the beneficial effects of this invention are as follows: This invention achieves real-time and accurate perception and asset inventory management of all active APIs in the system through non-intrusive API automatic discovery and feature extraction, capturing network traffic and intelligently parsing multimodal protocols based on eBPF technology. It can automatically and quickly discover and clean up zombie APIs, effectively reducing the system's attack surface and fundamentally improving security. Simultaneously, it transforms API asset management from traditional manual maintenance to automated operation and maintenance, increasing efficiency by an order of magnitude. Furthermore, this invention uses natural language processing-based intelligent identification of sensitive interfaces to analyze API metadata features. Text-aware semantic analysis utilizes pre-trained models to capture deep semantic relationships to calculate sensitivity scores, achieving a leap from traditional keyword matching to intelligent semantic understanding. This improves the accuracy of sensitive interface identification and effectively discovers deep data leakage risks that traditional rules cannot identify, resulting in a qualitative leap in security capabilities. Furthermore, this invention constructs an API lineage graph and performs change impact analysis, aggregating multi-source data to build a panoramic dependency topology. When an API changes, it can automatically, accurately, and quantitatively analyze the scope of impact and combine sensitivity scores for comprehensive risk assessment, achieving a shift from passive response to proactive early warning. This provides intuitive and comprehensive guidance for change decision-making. The comprehensive data support significantly reduces the risk of online failures caused by unclear dependencies. This invention uses traffic replay-based change risk simulation in a layered sandbox environment to perform high-fidelity testing of planned changes using real production traffic. By comprehensively monitoring indicators, it proactively identifies compatibility and stability issues, reducing the online failure rate caused by API changes and achieving pre-emptive interception and mitigation of change risks, providing strong stability assurance for the continuity of core business. Furthermore, by automating API documentation generation and synchronization, using the interface contract generated by traffic analysis as the sole trusted source, this invention automatically generates and maintains standardized documentation that is strictly consistent with the interface implementation in real time. This reduces the manpower cost of API documentation maintenance, completely solves the problem of document lag, greatly improves development collaboration efficiency, and eliminates technical risks introduced by information inconsistencies. Finally, this invention uses an event-driven engine to connect non-intrusive discovery, semantic analysis, lineage graphs, risk simulation, and document synchronization into an organic whole, forming a closed-loop governance system integrating perception, analysis, decision-making, and execution. Data is interconnected and capabilities are linked at each stage, and continuous self-optimization is achieved through a feedback learning mechanism. Ultimately, this systematically and intelligently solves the security, stability, and efficiency challenges throughout the entire API lifecycle, achieving a significant leap in governance effectiveness. Attached Figure Description

[0016] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention.

[0017] Figure 1 is a flowchart of the API full lifecycle intelligent governance method based on multimodal data perception and lineage mapping according to the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention. Obviously, the described embodiments are only some, not all, of the embodiments described in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without creative effort are within the scope of protection of this application.

[0019] Those skilled in the art will understand that, unless otherwise stated, the singular forms “a” and “an” used herein, and “the”, may also include the plural forms. It should be further understood that the term “comprising” as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0020] The first embodiment is shown in Figure 1. This embodiment provides an intelligent governance method for the entire lifecycle of APIs based on multimodal data perception and lineage mapping. This method constructs a closed-loop governance system integrating perception, analysis, decision-making, and execution through the synergistic effect of multiple technical links such as non-intrusive data collection, intelligent semantic analysis, lineage mapping construction, change simulation, and automatic document generation. This method can not only respond to changes in the API ecosystem in real time, but also optimize itself through continuous data feedback, realize continuous monitoring of API assets, accurate risk identification, and proactive security control, and ultimately significantly improve the security, stability, and operational efficiency of distributed systems. The method includes the following steps: S1: Collect network traffic in a non-intrusive manner, automatically discover APIs and extract metadata features, and generate API change events including event type, API identifier, and feature differences when new APIs or changes in the features of existing APIs are identified. Specifically, in this embodiment, step S1 is the cornerstone of the accuracy and real-time performance of the entire process. Through bypass listening and intelligent parsing, all active API interfaces are automatically discovered and characterized, and an accurate and real-time updated API asset list is established.

[0021] Preferably, in step S1, network traffic is collected in a non-intrusive manner to automatically discover APIs and extract metadata features. This includes: deploying a probe based on Extended Berkeley Packet Filtering (eBPF) technology at the host or container kernel level; capturing network packets in a bypass manner through the probe in kernel space; analyzing the load characteristics of network packets using deep packet inspection technology; and identifying application layer protocols. Specifically, in this embodiment, north-south and east-west network traffic is captured in a non-intrusive bypass manner. The probe can automatically identify and distinguish various application layer protocols, including but not limited to HTTP / HTTPS, gRPC, Dubbo, etc. After capturing network packets, the eBPF-based probe performs preliminary protocol identification in kernel space. This identification process not only relies on standard port numbers but, more importantly, uses deep packet inspection technology to accurately distinguish different types of application layer protocols by analyzing the starting byte characteristics of the packet load, effectively addressing services deployed on non-standard ports; and targeting identified RESTful... The API extracts the URL path, method, and parameter name from its request, and dynamically infers the parameter type based on pattern recognition of the parameter value. Specifically, in this embodiment, the URL path, method (GET / POST, etc.), parameter name, parameter type (based on value inference or pattern recognition), and example value are extracted from the request line, headers, query string, and request body. The parameter type inference is a dynamic and intelligent process. For example, for the parameter value "2023-01-01", the system infers its type as date; for a value that matches a specific regular expression, it infers it as mobile_number.This not only enriches the metadata but also provides strong type clues for S2 semantic analysis. For the identified gRPC protocol, the interface definition file is preferentially obtained from the integration service registry for accurate deserialization. When the interface definition file is unavailable, pattern recognition technology is used to infer the message field structure based on the gRPC protocol structure and traffic samples. Specifically, in this embodiment, the interface definition file (such as a .proto file) is preferentially obtained from the integration service registry or configuration center for accurate deserialization; this is the preferred and core strategy, which can extract the complete RPC method name, all field names of request / response messages, data types, and nested structures. The fallback strategy—pattern recognition inference based on traffic samples—is as follows: when the definition file is unavailable, pattern recognition technology is used to infer the message field structure based on the inherent structure of the protocol and a large number of traffic samples. This strategy is a systematic learning process. By analyzing the gRPC frame structure and clustering a large number of samples, field boundaries and repetitive structures are inferred, generating a "structural skeleton," which still has high value for change detection. To cope with massive API scenarios, a Bloom filter is used to quickly identify new APIs and perform secondary verification by persistent storage to ensure the accuracy of deduplication. Specifically, in this embodiment, a query with approximately O(1) time complexity and extremely low memory usage is achieved. When a new API is identified or a change in the characteristics (such as path and parameters) of an existing API is detected, an API change event is generated. The "Bloom filter + persistent storage secondary verification" strategy is adopted to achieve 100% deduplication accuracy while ensuring high performance. The generated API change event is a standardized message containing rich context such as event type, API identifier, and feature differences, which is injected into the core event-driven engine.

[0022] S2: Based on natural language processing technology, semantic analysis is performed on the metadata features of the API to calculate the sensitivity score of the API. High-risk interfaces with sensitivity scores reaching a preset threshold are marked and alerted. Specifically, in this embodiment, beyond keyword matching, the interface functions are deeply understood from the semantic level to accurately identify potential data leakage risks.

[0023] Preferably, in step S2, semantic analysis is performed on the metadata features of the API based on natural language processing technology to calculate the API's sensitivity score. This includes cleaning and normalizing the path, parameter names, and return field names in the API's metadata features, and then concatenating them into a text sequence. Specifically, in this embodiment, for each API interface, its text features such as path, parameter names, and return field names are concatenated and normalized to form a continuous text sequence. For example: / api / v1 / user / profile user_id mobile_number id_card address. The text sequence is a temporary object dynamically constructed in memory, and its data directly originates from the API metadata extracted in step S1. Before splicing, the text is cleaned and normalized (e.g., unified naming conventions and removal of path parameters). In addition, techniques such as TF-IDF can be used to automatically identify and assign higher weights to words with high discriminative power, providing more valuable input features for the model. A pre-trained language model with transfer learning is used to encode the text sequence, and the self-attention mechanism is used to capture the semantic relationships between elements in the text sequence. The sensitivity score of the API is output through the classification layer of the pre-trained language model. Specifically, in this embodiment, a pre-trained language model (such as BERT or ERNIE) is used as the analysis engine. The model encodes the input text sequence and uses its self-attention mechanism to capture the deep semantic relationships between words. Finally, a sensitivity score (Score_sensitivity) between 0 and 1 is output through a classification layer. This embodiment employs a transfer learning strategy, using a model pre-trained on a general corpus as a foundation, and then fine-tuning it with a large number of labeled API text sequences to ensure the model's capabilities are accurately adapted to the API sensitivity identification task, thereby achieving high accuracy. A configurable sensitivity threshold is set; when the sensitivity score exceeds the preset threshold, the API is automatically marked as a high-risk interface and an alarm is triggered. Specifically, in this embodiment, a configurable sensitivity threshold T_s is set. When Score_sensitivity > T_s, the system automatically marks the interface as high-risk and triggers an alarm. To improve domain adaptability, the model supports fine-tuning based on business scenarios. The threshold T_s can be configured differently according to different business domains. A feedback learning closed-loop mechanism is introduced, using the correction information of the marking results by the operation and maintenance personnel as new labeled data. Based on the new labeled data, the pre-trained language model is incrementally learned to optimize the model's scoring accuracy, enabling the model to continuously evolve and become increasingly aligned with the actual security needs of the enterprise.

[0024] S3: Construct an API lineage graph. When an API change event is received, perform change impact analysis based on the API lineage graph and conduct risk assessment in conjunction with sensitivity scores. Specifically, in this embodiment, construct and visualize the complex dependency relationships between APIs and services to provide a data foundation for change impact analysis.

[0025] Preferably, in step S3, an API lineage graph is constructed. When an API change event is received, the impact of the change is analyzed based on the API lineage graph. This includes aggregating multi-source data from distributed tracing systems, application performance monitoring tools, and service mesh control planes to construct an API lineage graph with an attribute graph structure. Specifically, in this embodiment, data from distributed tracing systems (such as Zipkin and Jaeger), application performance monitoring (APM) tools, service mesh control planes (such as Istio), and API metadata discovered in step S1 are aggregated to form a unified dependency data source. During this process, data cleaning is performed. Deduplication and time window alignment are performed. For example, the call chain ID in the tracing and the service instance metrics in APM are matched with the API endpoints discovered in step S1 to ensure the accuracy and real-time nature of dependencies. In the API lineage graph, microservices, API endpoints, and databases are used as nodes, and calls and dependencies are used as directed edges. Nodes and directed edges are attached with operational attributes including sensitivity scores, QPS, and average latency. Specifically, in this embodiment, entities such as microservices, API endpoints, databases, and message queues are modeled as graph nodes, and relationships such as calls, dependencies, and data flows are modeled as directed edges, constructing a directed graph structure for the API lineage graph. This graph is stored in a graph database (such as Neo4j) to support efficient relationship queries and traversals. The graph model adopts an attribute graph structure, with nodes and edges bearing rich attributes. For example, API nodes include their sensitivity score, QPS, and average latency; service nodes include their business line and responsible person; and dependency edges include attributes such as call frequency, average network latency, and whether they are core dependencies. This makes the graph a dynamic knowledge base rich in operational data. When an API change event is received, a weighted graph traversal algorithm is executed starting from the node corresponding to the changed API in the API lineage graph. The algorithm prioritizes traversing core dependency edges, quantifies and statistically analyzes the number of downstream affected nodes and the proportion of core business applications, and completes the change impact analysis. Specifically, in this embodiment, when an API change event generated in step S1 is received, a graph traversal algorithm (such as breadth-first search, BFS) is automatically executed starting from the API node in the graph. The scope of impact not only quantifies the number of downstream nodes but also incorporates the sensitivity score from step S2. It highlights and alerts dependent paths involving high-risk sensitive interfaces, providing a more comprehensive basis for risk assessment. The specific traversal process is weighted and hierarchical: the algorithm prioritizes traversing and evaluating edges marked as "core dependencies" and increases the impact weight of their downstream nodes. At the same time, the scope of impact is presented visually, clearly showing the directly affected first-level downstreams and indirectly affected second-level and above downstreams, and calculating the proportion of affected core business applications, providing decision-makers with an intuitive and quantitative risk report.

[0026] S4: Perform risk simulation on API changes based on traffic replay, test the planned API changes in a layered sandbox environment, and determine the risk level of the changes based on comprehensive indicators. Specifically, in this embodiment, before the changes are deployed, the effects of the changes are simulated in an isolated sandbox environment to identify and avoid potential failures in advance.

[0027] Preferably, in step S4, risk simulation of API changes based on traffic replay includes: continuously recording API business traffic in the production environment, de-identifying sensitive data in the traffic and storing it using a compression algorithm, and constructing a high-fidelity test case library containing historical request characteristics. Specifically, in this embodiment, real production environment traffic flowing through the target API is continuously recorded, and de-identified and compressed for storage (e.g., using the LZ4 algorithm) to form a high-fidelity test case library. The recorded traffic is indexed and stored according to API endpoints and timestamps, and a retention strategy is set to ensure that the test case library can cover sufficient business scenarios (such as peak traffic on weekdays and holidays) without expanding indefinitely and consuming excessive storage resources. API change rules are defined through a declarative rule engine, and the API change rules are applied to the historical request data in the test case library to generate test requests simulating the API change. Specifically, in this embodiment, planned changes (such as modifying parameter types, adding or deleting return fields) are defined as a series of rules. During simulation, these rules are applied to historical requests extracted from the test case library to generate a batch of test requests simulating the "changed" state. Rules are defined and executed through a declarative rule engine. For example, a rule could be "convert the age field in the request body from a string to an integer." The engine ensures correct data type conversion during traffic reconstruction and records conversion failures, which also serves as a risk warning. Traffic replay is performed in a layered sandbox: test requests for core business links are routed to the pre-release environment, and downstream dependencies of non-core businesses are simulated using a smart Mock service trained on historical traffic recording data. Specifically, in this embodiment, for core business links, existing pre-release environments or test instances of key downstream services are prioritized for connection. For other downstream services, a smart Mock service based on historical traffic recording is used, which can return a contract-compliant response based on request characteristics. This intelligent mock service has learning capabilities, enabling it to analyze historical request-response pairs and build a behavioral model. When it receives a request that has not been recorded, it can infer and return a type-safe, logically consistent response based on the model, rather than simply returning a "404 Not Found". This greatly improves the coverage and realism of simulation testing. It monitors downstream response metrics in real time during traffic replay and identifies high-risk changes when any of the following conditions are met: the 5xx error rate exceeds the error threshold (e.g., 1%); the response latency P95 exceeds the latency threshold; or the intelligent mock detects an unrecognizable request pattern. Specifically, in this embodiment, the deployment process is halted and a detailed analysis report is generated. The judgment logic is scalable; in addition to basic metrics, it can also integrate business rule verification, such as verifying whether the balance change in the deduction interface response is correct, thereby discovering deeper logical errors.

[0028] S5: Automatically generates API documentation that conforms to the Open API specification based on the extracted API metadata, and updates the API documentation in real time when an API change event is triggered.

[0029] Preferably, in step S5, API documentation conforming to the Open API Specification is automatically generated based on the extracted API metadata, and the API documentation is updated in real time when an API change event is triggered. This includes: mapping the extracted API metadata features to the OpenAPI Specification model to automatically generate API definition files conforming to the OAS standard. Specifically, in this embodiment, the API features extracted in step S1 are cleaned and standardized, and mapped to a standard API description specification (such as OpenAPI Specification, OAS) model. This process includes standardizing discrete parameter information into the definitions of parameters and schema in OAS, normalizing recurring complex data structures, and defining them as reusable components.schemas, thereby generating a document foundation framework that is both accurate and conforms to industry standards. When source code access is available, static code analysis technology is used to parse the abstract syntax tree of the source code, extract the comment information in the code, and fill the comment content into the API definition file to improve the document description. Specifically, in this embodiment, based on structured API information, API definition files in YAML or JSON format conforming to the OAS standard are automatically generated, advocating for the generation of API definition files based on traffic analysis. The interface contract is the only trusted source, automatically assigning a unique identifier to each API and storing the generated OAS file in a version control system (such as Git) for easy tracking of the history of each change. When an API change event is received, the document update process is automatically initiated, updating the API definition file based on the latest API metadata, and publishing the updated API definition file to the integrated documentation platform to achieve real-time document synchronization. Specifically, in this embodiment, under the condition of being able to access the API provider's source code, static code analysis technology is used to scan the source code file, extract interface-level, method-level, and parameter-level comments, and then use natural language processing technology to parse and fill them into the OAS document as readability enhancement.Specifically, this involves parsing the Abstract Syntax Tree (AST) to precisely associate comments in the code with their corresponding interface elements. For example, the `@ApiOperation` annotation on Java methods or the comment block above Go functions can be extracted and populated into the `description` field of the OAS, achieving a seamless combination of machine-generated precise contracts and human-written user-friendly descriptions. Interface compatibility issues identified during API change risk simulation are recorded in a structured manner as historical risk points, and their attribute information is fed back to the corresponding API nodes in the API lineage graph. Specifically, in this embodiment, the generated or updated OAS documentation is automatically published to an integrated documentation platform (such as Swagger UI, ReDoc). When step S1 detects changes in API characteristics, the documentation update process is automatically triggered through a change event, ensuring that the documentation accessed by developers is always consistent with the runtime interface. This process is usually integrated with the CI / CD pipeline, and the documentation update can be an automatic step in the pipeline. At the same time, the system can be configured to send documentation change notifications to API-related developers or users, promoting team collaboration.

[0030] Preferably, the method further includes a closed-loop feedback step: collecting issues discovered during API change risk simulation, including compatibility problems, response anomalies, and request pattern mismatches, and recording them as historical risk points in a structured manner, storing them in the attribute fields of the corresponding API nodes in the API lineage graph; when a change event triggering the same API is detected, querying the historical risk points recorded in the API lineage graph, and assigning a higher risk warning weight to the current change of the API based on the number, severity, and scope of related business impact of the historical risk points; establishing a continuous feedback learning mechanism, using historical risk point data, change risk assessment results, and manual intervention records of operations personnel as training data input to the API. The governance system is modified to achieve self-optimization of risk identification accuracy, evaluation model parameters, and governance rules through knowledge accumulation. Specifically, in this embodiment, the interface compatibility issues discovered in the risk simulation in step S4 will be fed back to the lineage graph in step S3 and recorded as a "historical risk point" of the API. When the API changes again in the future, the system will give it a higher risk warning weight. This continuous feedback learning mechanism enables the entire governance system to continuously accumulate knowledge and become more and more intelligent and accurate.

[0031] Based on the same concept, the second embodiment of the present invention also provides an intelligent API lifecycle governance system based on multimodal data perception and lineage mapping, comprising: a non-intrusive API perception and asset governance module, which collects network traffic in a non-intrusive manner, automatically discovers APIs and extracts metadata features, and generates API change events including event type, API identifier and feature differences when a new API or a change in the features of an existing API is detected; an intelligent semantic security analysis module, which performs semantic analysis on the metadata features of APIs based on natural language processing technology, calculates the sensitivity score of APIs, and marks and alerts high-risk interfaces whose sensitivity scores reach a preset threshold; a dependency topology discovery and impact assessment module, which constructs an API lineage mapping, performs change impact analysis based on the API lineage mapping when an API change event is received, and performs risk assessment in combination with the sensitivity score; a change security simulation and verification module, which performs risk simulation of API changes based on traffic replay, tests planned API changes in a layered sandbox environment, and determines the change risk level based on comprehensive indicators; and an automated API documentation module, which automatically generates API documentation that conforms to open API specifications based on the extracted API metadata, and updates the API documentation in real time when an API change event is triggered.

[0032] The third embodiment is based on the same concept. This embodiment also provides a computer device based on the same concept, including a memory and a processor. The memory stores computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor performs the steps of an API full lifecycle intelligent governance method based on multimodal data perception and lineage mapping as described in the embodiment.

[0033] Based on the same concept, the present invention also provides a storage medium storing computer-readable instructions, characterized in that, when the computer-readable instructions are executed by one or more processors, the one or more processors cause the one or more processors to perform the steps of the API full lifecycle intelligent governance method based on multimodal data perception and lineage mapping as described in any one of the embodiments.

[0034] It is understood that, regarding the aforementioned API lifecycle intelligent governance method based on multimodal data perception and lineage mapping, if all components are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer server or a network device, etc.) to execute all or part of the steps of the methods in the various embodiments of this invention. The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.

[0035] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0036] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A method for intelligent governance of the entire lifecycle of APIs based on multimodal data perception and lineage mapping, characterized in that, Includes the following steps: S1: Collects network traffic in a non-intrusive manner, automatically discovers APIs and extracts metadata features, and generates API change events containing event type, API identifier and feature differences when a new API or changes in the features of an existing API are detected. S2: Perform semantic analysis on the metadata features of the API based on natural language processing technology, calculate the sensitivity score of the API, and mark and alert high-risk interfaces whose sensitivity scores reach a preset threshold. S3 Construct an API lineage graph; when an API change event is received, perform change impact analysis based on the API lineage graph, and conduct risk assessment in conjunction with the sensitivity score. S4: Perform risk simulation of API changes based on traffic replay, test the planned changes to the API in a layered sandbox environment, and determine the risk level of the changes based on comprehensive indicators; S5: Automatically generate API documentation that conforms to the open API specification based on the extracted API metadata, and update the API documentation in real time when the API change event is triggered.

2. The API full lifecycle intelligent governance method based on multimodal data perception and lineage mapping as described in claim 1, characterized in that, In step S1, the non-intrusive collection of network traffic, automatic API discovery, and extraction of metadata features includes: deploying a probe based on extended Berkeley Packet Filtering (eBPF) technology; capturing network packets in kernel mode via the probe in a bypass manner; analyzing the load characteristics of network packets using deep packet inspection technology to identify application layer protocols; for identified RESTful APIs, extracting URL paths, methods, and parameter names from their requests, and dynamically inferring parameter types based on parameter value pattern recognition; for identified gRPC protocols, prioritizing the acquisition of interface definition files through the integration service registry for accurate deserialization; when the interface definition files are unavailable, inferring message field structures based on the gRPC protocol structure and traffic samples using pattern recognition technology; and using a Bloom filter to quickly deduplicate identified APIs, combined with persistent storage for secondary verification to ensure deduplication accuracy.

3. The API full lifecycle intelligent governance method based on multimodal data perception and lineage mapping as described in claim 1, characterized in that, In step S2, the semantic analysis of the API's metadata features based on natural language processing technology to calculate the API's sensitivity score includes: cleaning and normalizing the path, parameter names, and return field names in the API's metadata features, and concatenating them into a text sequence; encoding the text sequence using a pre-trained language model trained through transfer learning, capturing the semantic relationships between elements in the text sequence using a self-attention mechanism, and outputting the API's sensitivity score through the classification layer of the pre-trained language model; setting a configurable sensitivity threshold, automatically marking the API as a high-risk interface and triggering an alarm when the sensitivity score exceeds the preset threshold; introducing a feedback learning closed-loop mechanism, using the correction information of the marking results by the operation and maintenance personnel as new labeled data, and incrementally learning the pre-trained language model based on the new labeled data to optimize the model's scoring accuracy.

4. The API full lifecycle intelligent governance method based on multimodal data perception and lineage mapping as described in claim 1, characterized in that, In step S3, an API lineage graph is constructed. When an API change event is received, an impact analysis is performed based on the API lineage graph. This includes: aggregating multi-source data from a distributed tracing system, application performance monitoring tools, and the service mesh control plane to construct an API lineage graph with an attribute graph structure. In the API lineage graph, microservices, API endpoints, and databases are used as nodes, and calls and dependencies are used as directed edges. Nodes and directed edges are attached with operational attributes including sensitivity scores, QPS, and average latency. When an API change event is received, starting from the node in the API lineage graph corresponding to the changed API, a weighted graph traversal algorithm is executed, prioritizing the traversal of core dependency edges, quantifying and statistically analyzing the number of downstream affected nodes and the proportion of core business applications, thus completing the impact analysis.

5. The API full lifecycle intelligent governance method based on multimodal data perception and lineage mapping according to claim 1, characterized in that, In step S4, the risk simulation of API changes based on traffic replay includes: continuously recording API business traffic in the production environment, desensitizing sensitive data in the traffic and storing it using a compression algorithm, and constructing a high-fidelity test case library containing historical request characteristics; defining API change rules through a declarative rule engine, applying the API change rules to the historical request data in the test case library, and generating test requests simulating API changes; performing traffic replay in a layered sandbox: routing test requests from the core business link to the pre-release environment, and using a smart Mock service trained based on historical traffic recording data to simulate responses to downstream dependencies of non-core businesses; monitoring downstream response indicators in real time during the traffic replay process, and determining a high-risk change when any of the following conditions are met: if the 5xx error rate exceeds the error threshold; if the response latency P95 exceeds the latency threshold; or if the smart Mock detects an unrecognizable request pattern.

6. The API full lifecycle intelligent governance method based on multimodal data perception and lineage mapping according to claim 1, characterized in that, In step S5, API documentation conforming to the Open API Specification is automatically generated based on the extracted API metadata, and the API documentation is updated in real time when the API change event is triggered. This includes: mapping the extracted API metadata features to the OpenAPI Specification model to automatically generate an API definition file conforming to the OAS standard; when source code access is available, static code analysis technology is used to parse the abstract syntax tree of the source code, extract the comment information in the code, and populate the comment content into the API definition file to improve the documentation description; when an API change event is received, the documentation update process is automatically started, the API definition file is updated based on the latest API metadata after the change, and the updated API definition file is published to the integrated documentation platform to achieve real-time documentation synchronization; interface compatibility issues identified during the API change risk simulation process are recorded in a structured manner as historical risk points, and the attribute information associated with the corresponding API node in the API lineage graph is fed back.

7. The API full lifecycle intelligent governance method based on multimodal data perception and lineage mapping as described in claim 6, characterized in that, The method also includes a closed-loop feedback step: collecting problems found in the API change risk simulation, including compatibility issues, response anomaly issues, and request pattern mismatch issues, and recording them as historical risk points in a structured manner, and storing them in the attribute fields of the corresponding API nodes in the API lineage graph; When a change event triggered by the same API is detected, the historical risk points recorded in the API lineage graph are queried. Based on the number, severity and scope of impact of the historical risk points on related businesses, a higher risk warning weight is assigned to the current change of the API. Establish a continuous feedback learning mechanism, inputting historical risk point data, change risk assessment results, and manual intervention records of operation and maintenance personnel as training data into the API change governance system. Through knowledge accumulation, the system can achieve self-optimization of risk identification accuracy, assessment model parameters, and governance rules.

8. An API full lifecycle intelligent governance system based on multimodal data perception and lineage mapping, characterized in that, include: The non-intrusive API awareness and asset governance module collects network traffic in a non-intrusive manner, automatically discovers APIs and extracts metadata features, and generates API change events that include event type, API identifier and feature differences when a new API or changes in the features of an existing API are detected. The intelligent semantic security analysis module performs semantic analysis on the metadata features of the API based on natural language processing technology, calculates the sensitivity score of the API, and marks and alerts high-risk interfaces whose sensitivity scores reach a preset threshold; the topology discovery and impact assessment module constructs an API lineage graph, and when the API change event is received, it performs change impact analysis based on the API lineage graph and performs risk assessment in combination with the sensitivity score; The security simulation and verification module is modified to perform risk simulation of API changes based on traffic replay. The planned changes to the API are tested in a layered sandbox environment, and the risk level of the changes is determined based on comprehensive indicators. The API documentation automation module automatically generates API documentation that conforms to the Open API Specification based on the extracted API metadata, and updates the API documentation in real time when the API change event is triggered.

9. A computer device, characterized in that, It includes a memory and a processor, wherein the memory stores computer-readable instructions, which, when executed by the processor, cause the processor to perform the steps of an API full lifecycle intelligent governance method based on multimodal data perception and lineage mapping as described in any one of claims 1 to 7.

10. A storage medium storing computer-readable instructions, characterized in that, When the computer-readable instructions are executed by one or more processors, the one or more processors perform the steps of the API full lifecycle intelligent governance method as described in any one of claims 1 to 7.

Images