An application programming interface orchestration model training method, an orchestration method and an apparatus

Abstract

The application provides an application programming interface (API) orchestration model training method and device, which converts original call logs into a directed heterogeneous graph with features containing topology, performance and error information. Then, based on a graph neural network, incremental link reasoning is performed in a context subgraph to automatically generate the API call link with the highest probability and its performance estimation, thereby realizing intelligent recommendation of the orchestration scheme. During the training process, a composite loss function is used to simultaneously optimize the topology accuracy, delay and error rate, thereby driving the model to integrate the function correctness and operation efficiency. This method automatically generates the workflow design instead of manual orchestration, thereby greatly improving the development efficiency. Meanwhile, relying on the runtime data backflow, the system can be iterated to continuously enhance the system adaptability and robustness.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to an application programming interface (API) orchestration model training method, orchestration method, and apparatus. Background Technology

[0002] With the widespread adoption of microservice architecture, application functions are being broken down into numerous independent services exposed through APIs (Application Programming Interfaces). To complete complex business processes such as "user order placement," developers need to assemble multiple APIs into orchestration workflows according to specific sequences, conditions, and error handling logic. Currently, there are two main approaches: one is to manually write the call logic in the code, which offers high flexibility but is lengthy and error-prone; the other is to use visual low-code platforms such as MuleSoft, Zapier, and Huawei Cloud API Explorer to generate workflows by dragging and dropping connectors and configuring parameters, lowering the barrier to entry but still relying on manual design. A common drawback of these solutions is the "human-in-the-loop": orchestration correctness, performance, and subsequent optimization depend entirely on the developer's experience, leading to long design cycles and high maintenance costs. Simultaneously, the large amount of API call logs generated during runtime contains valuable information such as success paths, latency, and error rates, but due to the fragmented nature of existing toolchains, this information cannot be fed back to the design phase, creating a gap between design and runtime data and missing opportunities for continuous optimization. Therefore, a new application programming interface orchestration model is urgently needed. Summary of the Invention

[0003] In view of this, embodiments of the present invention provide an application programming interface orchestration model training method, orchestration method and apparatus to eliminate or improve one or more defects existing in the prior art, and solve the problem that the prior art relies on manual labor and cannot utilize existing orchestration experience information in the API orchestration process.

[0004] One aspect of the present invention provides a method for training an application programming interface orchestration model based on call history, the method comprising the following steps:

[0005] Data cleaning and format standardization are performed on application programming interface call logs obtained based on preset data sources. The logs are grouped according to business content or user subject and sorted by timestamp. A directed heterogeneous graph is constructed with application programming interfaces as nodes and their node characteristics recorded, and call relationships as edges and their edge characteristics recorded.

[0006] Based on the call sequence between one or more specified starting nodes, a business context subgraph is extracted from the directed heterogeneous graph; using the business context subgraph as input, iterative link prediction is performed based on the execution graph convolutional neural network, calculating the probability that the leading node in the business context subgraph is connected to all other candidate nodes, selecting the one with the highest probability to add and update the business context subgraph, repeating the iteration until the business endpoint application programming interface or the node sequence length reaches a preset upper limit, and outputting the prediction result, which includes each node of the predicted workflow path, the prediction delay, and the prediction failure rate;

[0007] Based on the prediction results and the differences between the historical records in the directed heterogeneous graph, the topology correctness loss, delay penalty loss, and error rate penalty loss are calculated, and a joint loss is constructed to update the parameters of the graph convolutional neural network, resulting in an application programming interface orchestration model.

[0008] In some embodiments, data cleaning and format standardization are performed on application programming interface call logs obtained based on a preset data source, including:

[0009] The application programming interface call logs are obtained using the application programming interface gateway, service mesh, application performance monitoring system, or application server log system as the preset data source.

[0010] Invalid fields in the application programming interface call log are removed, and missing data is filled, including filling missing numeric fields with mean, median or default value, and filling missing categorical fields with preset markers.

[0011] The timestamps in the application programming interface call logs are converted into a unified Coordinated Universal Time (UTC) format, mapping API paths with the same semantics but different parameter values ​​to a unique, unchanging, preset standard form.

[0012] In some embodiments, the node characteristics include static category characteristics and dynamic statistical characteristics; the static category characteristics include application programming interface function type, microservice to which it belongs, and authentication level; the dynamic statistical characteristics include average latency, historical error rate degradation call frequency;

[0013] The edge features include time features, context features, and result features. The time features include the call time and the time difference within the session. The context features include the request / response size and request parameter features. The result features indicate whether the call was successful.

[0014] In some embodiments, the graph convolutional neural network is obtained by stacking multiple graph attention network layers, and the graph attention network layers are constructed based on a multi-head attention mechanism.

[0015] In some embodiments, the formula for calculating the topological correctness loss is:

[0016]

[0017] in, This represents the loss in topological correctness. Indicates the actual next-hop node. This represents the i-th negative sample node among the candidate nodes, excluding the actual next-hop node. This represents the predicted probability of the actual next-hop node. represents the predicted probability of the negative sample node; k represents the total number of negative sample nodes;

[0018] The formula for calculating the delay penalty loss is:

[0019]

[0020]

[0021] in, This represents the delay penalty loss. The predicted delay represents the predicted workflow path. This represents the total historical latency of each edge within the predicted workflow path. Let represent the i-th edge, and n represent the total number of edges; This represents the historical average delay of the i-th edge;

[0022] The formula for calculating the error rate penalty loss is:

[0023]

[0024]

[0025] in, This represents the error rate penalty loss. This indicates a prediction of the overall failure rate of the predicted workflow path. This represents the historical overall failure rate of the predicted workflow path. This represents the historical path failure probability of the i-th edge within the predicted workflow path;

[0026] The formula for calculating the joint loss is:

[0027]

[0028] in, Indicates the joint loss, and These are the weighting coefficients.

[0029] On the other hand, the present invention also provides an application programming interface orchestration method based on call history, the method comprising the following steps:

[0030] Construct an initial subgraph based on the user-specified application programming interface (API) start node or the initial API call list contained in the user session;

[0031] The initial subgraph is input into the application programming interface orchestration model in the above-mentioned application programming interface orchestration model training method based on call history, and the nodes of the predicted workflow path, the prediction latency, and the prediction failure rate are output to form an application programming interface list.

[0032] In some embodiments, the method further includes:

[0033] The application programming interface list is translated and output into corresponding workflows according to a preset format and deployed through a CI / CD pipeline. The preset format includes: declarative configuration files, computer language scripts, and visual workflows displayed on a visualization platform.

[0034] On the other hand, the present invention also provides an application programming interface orchestration device based on call history, including a processor, a memory, and a computer program / instructions stored in the memory. The processor is used to execute the computer program / instructions, and when the computer program / instructions are executed, the device implements the steps of the above method.

[0035] On the other hand, the present invention also provides a computer-readable storage medium having a computer program / instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0036] On the other hand, the present invention also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0037] The application programming interface (API) orchestration model training method, orchestration method, and apparatus described in this invention cleanses and reconstructs the original API call logs into a directed heterogeneous graph with node and edge features, fully preserving topology, performance, and error patterns. Subsequently, a graph convolutional neural network is used to perform iterative link prediction on the extracted context subgraph, automatically outputting the API call sequence with the highest probability, along with its prediction latency and failure rate, thus achieving automatic generation of orchestration schemes. The joint loss function simultaneously constrains topological correctness, latency, and error rate during the training phase, enabling the model not only to learn the syntactically correct call order but also to proactively pursue the path with optimal performance and lowest risk. This invention significantly shortens the workflow design cycle and reduces labor costs; simultaneously, relying on continuously flowing production data, the model can adaptively optimize as APIs evolve, improving system resilience and scalability.

[0038] Additional advantages, objects, and features of the invention will be set forth in part in the description which follows, and will also become apparent in part to those skilled in the art upon studying the description, or may be learned by practice of the invention. The objects and other advantages of the invention can be realized and obtained by means of the structures specifically pointed out in the description and drawings.

[0039] Those skilled in the art will understand that the objectives and advantages achievable with the present invention are not limited to those specifically described above, and that the above and other objectives achievable with the present invention will become clearer from the following detailed description. Attached Figure Description

[0040] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, are not intended to limit the scope of the invention. In the drawings:

[0041] Figure 1 This is a flowchart illustrating the application programming interface orchestration model training method based on call history according to an embodiment of the present invention.

[0042] Figure 2 This is a schematic diagram of the overall architecture of the intelligent API orchestration and recommendation system according to an embodiment of the present invention.

[0043] Figure 3 This is a schematic diagram of the API orchestration steps of the intelligent API orchestration recommendation system according to an embodiment of the present invention. Detailed Implementation

[0044] 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 embodiments and accompanying drawings. Here, the illustrative embodiments and descriptions of this invention are used to explain the invention, but are not intended to limit the invention.

[0045] It should also be noted that, in order to avoid obscuring the invention with unnecessary details, only the structures and / or processing steps closely related to the solution according to the invention are shown in the accompanying drawings, while other details that are not closely related to the invention are omitted.

[0046] It should be emphasized that the term "including / comprises" as used herein refers to the presence of a feature, element, step, or component, but does not exclude the presence or addition of one or more other features, elements, steps, or components.

[0047] Currently, the mainstream technical solutions for solving API orchestration problems can be categorized into two types: manual code implementation and rule-based visualization platforms.

[0048] Manual code orchestration is the most basic implementation method. Developers use general-purpose programming languages ​​(such as Java, Python, Go, etc.) to directly write instructions for calling different APIs in their business logic code. This approach requires developers to manually handle all the details, including service discovery, request construction, response parsing, data transformation, error handling, retry logic, and call order control. While this imperative orchestration method is flexible, its drawbacks are also quite obvious: the implementation process is lengthy, prone to errors, and the code has poor readability and maintainability. Furthermore, whenever business processes change, the code needs to be modified, tested, and redeployed, leading to low development efficiency and difficulty in adapting to rapidly changing business requirements.

[0049] Rule-based visual (low-code / no-code) orchestration platforms are currently the mainstream solution in the market and a key existing technology compared to this invention. These platforms aim to reduce the complexity of API orchestration, allowing developers and even non-technical personnel to design and manage workflows through a graphical user interface (GUI). Users drag and drop connectors or functional modules representing different API services on a visual canvas, such as conditional statements, loops, parallel branches, and other logical components, and then define their execution order and dependencies by connecting them. Users can configure the request parameters and header information for each API node and define how to map or transform the output data of the previous API into the input data of the next API. After the design is complete, the platform automatically generates and deploys the underlying execution logic.

[0050] Additionally, existing technologies include API recommendation systems aimed at assisting developers, rather than fully automating workflow generation. These systems fall under the category of recommendation engines applied in software engineering. They rely on keyword searches within API documentation or collaborative filtering algorithms to recommend APIs based on combinations used by other developers. However, this approach is relatively crude and fails to grasp the deep semantics and sequential dependencies of API calls.

[0051] Existing technologies suffer from two fundamental limitations. First, there's a bottleneck in the human-centric workflow. Whether it's an orchestration tool providing a visual design interface or a recommendation tool offering code snippets, they are essentially tools to assist human decision-making. The former is a "design tool," the latter an "assistance tool." Ultimately, the logic, structure, and correctness of the workflow rely entirely on the knowledge, experience, and intuition of human developers. The system's "intelligence" lies in the convenience of the user experience, rather than the automatic discovery and creation of the workflow itself. This means that the entire API orchestration design process is limited by human cognitive abilities and available time. The workflows designed by developers are based on their perception of how things should work, not necessarily the most efficient and reliable way the system actually operates in a real-world environment.

[0052] Secondly, there is a disconnect between design-time and runtime data. During system operation, infrastructure such as API gateways and service meshes generate massive amounts of API call logs. These logs are valuable empirical data, truthfully recording which API call sequences succeeded, which failed, which executed quickly, and which executed slowly. However, current API orchestration design tools are completely disconnected from this valuable runtime data. When developers design a workflow, they often do so in a vacuum environment based on static API documentation and business requirements. The true performance of this workflow can only be known after it is deployed to the production environment and new logs are generated. In this process, there is no automated feedback loop that can utilize existing, massive amounts of historical log data to guide, optimize, or even automatically generate new orchestration designs. This leads to a huge gap between the design-time environment and runtime reality, wasting the collective wisdom and real-world patterns contained in historical data.

[0053] In view of this, the present invention provides a training method for an application programming interface orchestration model based on call history, such as... Figure 1 As shown, the method includes the following steps S101~S103:

[0054] Step S101: Clean and format the application programming interface call logs obtained based on the preset data source, group them according to business content or user subject and sort them by timestamp, construct a directed heterogeneous graph with application programming interfaces as nodes and their node characteristics recorded, and call relationships as edges and their edge characteristics recorded.

[0055] Step S102: Based on the call sequence between one or more specified starting nodes, extract a business context subgraph from the directed heterogeneous graph; using the business context subgraph as input, perform iterative link prediction based on the execution graph convolutional neural network, calculate the probability that the leading node in the business context subgraph is connected to all other candidate nodes, select the one with the highest probability to add and update the business context subgraph, repeat the iteration until the business endpoint application programming interface or the node sequence length reaches a preset upper limit, and output the prediction result, which includes each node of the predicted workflow path, the prediction delay, and the prediction failure rate.

[0056] Step S103: Based on the prediction results and the differences between historical records in the directed heterogeneous graph, calculate the topological correctness loss, delay penalty loss, and error rate penalty loss, and construct a joint loss to update the parameters of the graph convolutional neural network to obtain the application programming interface orchestration model.

[0057] In step S101, raw call logs are first retrieved in batches or in real-time from preset data sources such as API gateways, service meshes, or centralized log platforms. Then, data cleaning and format unification operations are performed, including missing value imputation, anomaly removal, timestamp unification to UTC (Coordinated Universal Time), and URL devariation, to ensure consistency in subsequent processing. Next, the logs are grouped by business content or user subject based on request_id / session_id or user_id, and sorted by timestamp within each group to complete sessionization, resulting in API call sequences representing complete business sessions. Finally, each unique API endpoint is mapped to a node in a graph. Node features include static and statistical characteristics such as HTTP method type, microservice, authentication level, historical average latency, error rate, and call frequency. Each call is mapped to a directed edge, with edge features including call time, interval since the last call, request / response size, and success / failure context information, thus constructing a directed heterogeneous graph with distinct node types, edge types, and attributes, providing a unified and rich structured input for subsequent learning.

[0058] In some embodiments, data cleaning and format unification are performed on application programming interface call logs obtained based on a preset data source, including steps S1011~S1013:

[0059] Step S1011: Obtain application programming interface (API) call logs using an API gateway, service mesh, application performance monitoring system, or application server log system as a preset data source. The API gateway may include Nginx, Kong, or Apache APISIX. The service mesh may include Istio or Linkerd. The application server log system may include ELK Stack, Splunk, or Alibaba Cloud SLS.

[0060] In this embodiment, the referenced log structure is a highly structured data format designed to comprehensively capture the complete context information of each API call. Its core fields include unique identifiers for tracking the distributed call chain (such as request_id), business identifiers for session reconstruction (such as session_id), precise timestamps, and key metadata describing the call itself, such as the caller (source_service), the target API endpoint (target_api_endpoint), the specific content and size of the request and response, the HTTP status code, and latency. This unified structure forms the basis for subsequent data cleaning, session reconstruction, feature engineering, and ultimately, the directed heterogeneous graph required to build the graph neural network.

[0061] Step S1012: Remove invalid fields from the application programming interface call log and fill in missing data, including filling missing numeric fields with mean, median or default value, and filling missing categorical fields with preset tags.

[0062] Step S1013: Convert the timestamps in the application programming interface call logs to a unified Coordinated Universal Time (UTC) format, mapping API paths with the same semantics but different parameter values ​​to a unique, unchanging, preset standard form.

[0063] When forming a directed heterogeneous graph, the node features include static category features and dynamic statistical features. Static category features include the application programming interface (API) function type, the microservice to which it belongs, and the authentication level. Dynamic statistical features include average latency, historical error rate degradation, and call frequency. Edge features include time features, context features, and result features. Time features include the call time and the time difference within the session. Context features include request / response size and request parameter features. Result features indicate whether the call was successful.

[0064] In step S102, based on one or more starting nodes specified by the user (such as the first API that triggers the business process), a business context subgraph is extracted from the global directed heterogeneous graph, which defines the currently recommended initial context environment.

[0065] Using this subgraph as input, the graph convolutional neural network begins iterative link prediction. The model calculates the probability that the most recently added frontier node in the current subgraph is connected to all other candidate nodes in the global graph. This probability incorporates historical call patterns of the topology and combines performance information from node and edge features. The model selects the candidate node with the highest probability as the next most likely and optimal API to add to the current subgraph, thereby updating the business context.

[0066] The above process is repeated iteratively, with the subgraph continuously growing until the model predicts an API that is identified as the business endpoint, such as a successful payment, or the sequence length reaches a preset limit. At this point, the model outputs the final predicted complete workflow path, i.e., the sequence of nodes, and provides the prediction latency and prediction failure rate of this path based on its statistical information in historical data. This process perfectly demonstrates how the model applies learned historical patterns to generate new and optimized orchestration schemes.

[0067] In some embodiments, the graph convolutional neural network is obtained by stacking multiple graph attention network layers, and the graph attention network layers are constructed based on a multi-head attention mechanism.

[0068] In step S103, during the training process, the prediction results output in step S102 are compared with the real historical records recorded in the heterogeneous graph, and three types of losses are calculated.

[0069] Topological correctness loss typically uses cross-entropy loss to measure the difference between the predicted API sequence and the true sequence, ensuring that the path recommended by the model is structurally correct and feasible.

[0070] In some embodiments, the formula for calculating the topological correctness loss is:

[0071]

[0072] in, Represents the loss for topological correctness. Indicates the actual next-hop node. This represents the i-th negative sample node among the candidate nodes, excluding the actual next-hop node. This represents the predicted probability of the actual next-hop node. represents the predicted probability of a negative sample node; k represents the total number of negative sample nodes.

[0073] Delay penalty loss typically uses mean squared error (MSE), which calculates the difference between the total delay of the predicted path and the historical best delay, penalizing paths that are correct but inefficient.

[0074] The formula for calculating the delay penalty loss is:

[0075]

[0076]

[0077] in, This indicates the penalty for delaying punishment. This indicates the prediction delay for predicting workflow paths. This represents the total historical latency of each edge within the predicted workflow path. Let represent the i-th edge, and n represent the total number of edges; This represents the historical average delay of the i-th edge.

[0078] The error rate penalty loss also uses MSE (Mean Sequence of Errors), calculating the difference between the predicted path's error rate and the ideal value, and penalizing paths with poor reliability and a high failure rate. The formula for calculating the error rate penalty loss is:

[0079]

[0080]

[0081] in, Indicates the penalty loss for error rate. This represents a prediction of the overall failure rate of the predicted workflow path. This indicates the historical overall failure rate of the predicted workflow path. This represents the probability of historical path failure for the i-th edge within the predicted workflow path.

[0082] The formula for calculating the joint loss is:

[0083]

[0084] in, Indicates the joint loss, and These are the weighting coefficients.

[0085] On the other hand, the present invention also provides an application programming interface orchestration method based on call history, the method comprising the following steps S201~S202:

[0086] Step S201: Construct an initial subgraph based on the user-specified application programming interface start node or the initial application programming interface call list contained in the user session.

[0087] Step S202: Input the initial subgraph into the application programming interface orchestration model in the application programming interface orchestration model training method based on call history described in steps S101~S103 above, and output each node of the predicted workflow path, the prediction delay and the prediction failure rate to form an application programming interface list.

[0088] In some embodiments, the method further includes: translating the application programming interface list into a corresponding workflow according to a preset format and deploying it through a CI / CD pipeline. The preset format includes: a declarative configuration file, a computer language script, and a visual workflow displayed on a visualization platform.

[0089] On the other hand, the present invention also provides an application programming interface orchestration device based on call history, including a processor, a memory, and a computer program / instructions stored in the memory. The processor is used to execute the computer program / instructions, and when the computer program / instructions are executed, the device implements the steps of the above method.

[0090] On the other hand, the present invention also provides a computer-readable storage medium having a computer program / instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0091] On the other hand, the present invention also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0092] The present invention will now be described with reference to a specific embodiment:

[0093] This embodiment provides an intelligent and automated API orchestration recommendation and generation system and method based on API call history. The objectives are: 1) To automate workflow discovery by automatically analyzing historical API call data to intelligently discover efficient, reliable, and business-logic-compliant API orchestration patterns, thereby freeing developers from tedious and error-prone manual design work. 2) To optimize workflow performance by learning from and recommending (or directly generating) the best-performing API orchestration scheme based on historical performance data (such as latency and success rate), thereby improving the response speed and stability of the entire business system. 3) To enhance developer productivity by transforming the API orchestration creation process from manual design to automatic generation, significantly shortening the development cycle, reducing development costs, and allowing developers to focus more on core business logic innovation. 4) To enhance system adaptability and resilience by creating a system that can continuously learn from newly generated runtime data. When underlying APIs change or system usage patterns evolve, the system can proactively suggest updated or alternative orchestration schemes, thereby building a more resilient and self-optimizing software system. 5) Provide a unified end-to-end solution, aiming to provide a seamlessly integrated system that covers the entire lifecycle from massive historical data acquisition and intelligent model training to the final generation of executable orchestration artifacts, eliminating the fragmentation problem of existing toolchains.

[0094] This embodiment treats the entire API interaction history within an organization or system as a database rich in tacit knowledge. This knowledge includes which API call sequences successfully complete business processes, which sequences are more efficient, and what complex dependencies exist between APIs. By applying advanced machine learning techniques, the entire API ecosystem and its interaction history are modeled as a dynamic, attributed graph. Then, a graph neural network (GNN) model, particularly well-suited for processing graph-structured data, is used to perform deep learning on this graph. Through this learning process, the system can automatically extract the underlying rules, dependencies, and performance characteristics for successfully completing complex business processes.

[0095] When a developer presents a high-level business intent—for example, a requirement to "open an account and configure initial resources for a new user" expressed through an initial API call or a natural language description—a well-trained model can recommend one or more API call sequences that are optimal in terms of success probability and performance metrics, i.e., a complete API orchestration scheme, based on its learned knowledge. Finally, the system represents this model-recommended, abstract orchestration scheme as an API call path or subgraph, automatically translating it into a concrete artifact that can be directly executed by a standard API orchestration engine, such as a configuration file or a script. This achieves end-to-end intelligent orchestration from data insights to automated deployment.

[0096] Figure 2 This embodiment demonstrates the overall architecture of the intelligent API orchestration and recommendation system. The system mainly consists of six core modules, which work together to form a complete data-driven decision-making closed loop.

[0097] 1. Data Ingestion and Preprocessing Module: Responsible for collecting raw API call logs from various sources and cleaning, transforming and standardizing them to prepare for subsequent analysis.

[0098] 2. Feature Engineering Module: This module is responsible for transforming preprocessed log data into structured features that machine learning models can understand, particularly for building graph data structures for GNN training.

[0099] 3. Intelligent Orchestration Recommendation Model: The intelligent core of the system, which mainly adopts deep learning models such as GNN, and is responsible for learning historical patterns and generating orchestration recommendations.

[0100] 4. Model Training and Management Module: Responsible for training, evaluating, versioning, and deploying models to ensure continuous iteration and optimization.

[0101] 5. Orchestration Generation and Execution Module: This module is responsible for converting the abstract recommendation results output by the model into concrete executable orchestration artifacts and deploying them into the actual execution environment.

[0102] 6. Feedback Loop Module: This module is responsible for collecting performance data of the orchestration workflows generated by this system during actual operation and feeding it back to the data acquisition module, forming a closed loop for continuous learning and optimization.

[0103] like Figure 3 This embodiment demonstrates the complete workflow from raw data to final execution, including steps S1 to S9:

[0104] Step S1: The data acquisition and preprocessing module pulls API call logs in real time or in batches from API gateway, service mesh, and application server log systems (such as Alibaba Cloud Log Service SLS, Elasticsearch, etc.).

[0105] Step S2: Clean the raw logs, handle missing and outlier values, and standardize data in different formats. The key step is session reconstruction, which involves associating discrete API call records into a call sequence representing a complete business interaction based on request ID, session ID or user ID, and time window.

[0106] Step S3: The feature engineering module receives the session sequence and converts it into a graph data structure. Each unique API endpoint becomes a node in the graph, and each API call becomes a directed edge connecting two nodes. Simultaneously, rich features are extracted and computed for the nodes and edges.

[0107] Step S4: The model training and management module uses the constructed historical interaction graph data to train the intelligent orchestration recommendation model (such as GNN). The training process aims to teach the model to predict the next most likely and efficient API call in a given context.

[0108] Step S5: During the inference phase, the system receives an initial input that represents a business intent (e.g., the user triggers the first API to "create an order").

[0109] Step S6: Based on the input and its learned knowledge, the intelligent orchestration recommendation model predicts a series of subsequent API calls in an iterative manner, forming a complete and recommended orchestration path (or subgraph).

[0110] Step S7: The orchestration generation and execution module translates the orchestration path recommended by the model into a format that the target execution engine (such as an API gateway) can recognize, such as a YAML configuration file.

[0111] Step S8: The generated orchestration artifact is deployed to the execution engine. When a new business request matches the orchestration, the engine will execute API calls according to the generated logic.

[0112] Step S9: The closed-loop feedback module monitors the execution performance (such as latency and success rate) of the new orchestration and feeds this new performance data back to the data lake as new training samples for the next round of model training.

[0113] Furthermore, the data acquisition and preprocessing module is the foundation of the entire system, and its processing quality directly affects the performance of subsequent models. It can access various log sources, including but not limited to: API gateways (such as Nginx, Kong, Apache APISIX), service meshes (such as Istio, Linkerd), application performance monitoring (APM) systems, and centralized log platforms (such as ELK Stack, Splunk, Alibaba Cloud SLS).

[0114] The log structure used in this embodiment is a structured or semi-structured log containing the following fields:

[0115] request_id / trace_id: Used to trace the complete call chain of a single request in a distributed system.

[0116] session_id / user_id: Used to identify the same user or business session.

[0117] timestamp: The precise timestamp of the API call.

[0118] source_service: The name of the service that initiated the call.

[0119] target_api_endpoint: A unique identifier for the API being called, such as HTTP_METHOD / path / to / resource.

[0120] request_payload: The content of the request body or its summary / size.

[0121] response_code: HTTP status code.

[0122] response_payload: The content of the response body or its summary / size.

[0123] latency_ms: The total time from when a request is sent to when a response is received, in milliseconds.

[0124] The data acquisition and preprocessing module performs data cleaning and normalization on the log data, including: handling missing values ​​by filling numeric fields (such as latency_ms) with the mean, median, or default value; and filling categorical fields with special markers. It also removes invalid records by discarding records with missing or incorrectly formatted key fields (such as target_api_endpoint and timestamp). Furthermore, it standardizes the format by converting all timestamps to a unified UTC format and normalizes API endpoints by removing variable parts from the paths to obtain a unified API identifier.

[0125] The data acquisition and preprocessing module performs session reconstruction, a crucial step in transforming unordered logs into ordered sequences. The system groups logs by session_id or user_id, then sorts them within each group based on timestamps, resulting in multiple API call sequences representing different business processes. This forms the basis for subsequent sequence modeling and graph construction.

[0126] The feature engineering module is responsible for transforming the cleaned data into a graph feature representation that the GNN model can effectively learn. Through graph construction, the entire system's API interaction history is built into a large-scale directed heterogeneous graph. Nodes represent a unique API endpoint, such as GET / users / {id}. Edges represent an actual call from source_service to target_api_endpoint. Edges have temporal attributes and are directed.

[0127] Node features compute a set of feature vectors for each API node, describing its static properties and long-term statistical characteristics.

[0128] Static attributes are represented by static categorical features, including: API function type (e.g., categorized as read, write, update, or delete operations based on HTTP methods); the microservice to which the API belongs; and the authentication level (e.g., the level of access required by the API, such as public, user, or administrator). These categorical features are typically converted into numerical vectors using one-hot encoding.

[0129] Long-term statistical properties are characterized by dynamic statistical features, including: average latency, which is the average response time of the API historically; historical error rate, which is the frequency with which the API has returned non-2xx status codes historically; and call frequency (popularity), which is the total number of times the API has been called or the average number of calls per unit time. These numerical features need to be normalized or standardized to avoid the impact of features at different scales on model training.

[0130] Edge features are a set of feature vectors calculated for each API call (i.e., each edge), describing the specific context of that call.

[0131] The intelligent orchestration and recommendation model is responsible for learning from the constructed graph and making recommendations, and mainly uses graph convolutional neural networks to build the model.

[0132] APIs and their calling relationships naturally form a graph. Compared to RNNs or Transformer models, which can only handle linear sequences, GNNs can more directly and effectively capture the complex, non-linear dependencies in the network topology. For example, a GNN can learn that the success rate of an API call is not only related to the previous API, but may also be related to the state of a non-adjacent API upstream in the entire call chain.

[0133] In this embodiment, the graph convolutional neural network uses a stack of graph attention networks (GAT), which allows the model to dynamically assign different importance weights to neighboring nodes. This is very much in line with the actual situation of API calls, that is, the importance of the preceding call is different in different contexts.

[0134] During inference, the model's input is a subgraph representing the current business context. This subgraph can consist of the starting API node specified by the developer, or it can be the first few API calls that have occurred in a user session, captured in real time. The model is composed of multiple stacked GAT layers. In each layer, for each node (API) in the graph, the model calculates the attention coefficient between it and all its neighboring nodes (APIs that have been directly called historically). This coefficient determines how much information should be absorbed from each neighbor when updating the current node's representation. Through the multi-head attention mechanism, the model can learn multiple dependencies from different perspectives.

[0135] The core task of the model is formalized as iterative link prediction, specifically as follows: given the current context subgraph G... tThe model calculates the probability of all possible new edges connecting the current leading edge node to any other API node in the graph. The edge with the highest probability and best performance (i.e., the next API call) is selected and added to the subgraph, forming a new context subgraph G. t+1 Repeat this process until a termination condition is met, such as reaching the business endpoint API or the sequence length reaching a preset limit, thereby constructing a complete recommended workflow path.

[0136] The model is trained on complete graph data containing all historical API interactions.

[0137] To enable the model to predict not only grammatically correct (i.e., historically known) sequences, but also high-performing sequences, this embodiment employs an innovative composite loss function, calculated as follows:

[0138]

[0139] in, and These are the weighting coefficients.

[0140] Topological correctness loss The goal is to ensure the model learns the grammatical rules of API calls, i.e., which API sequences are logically correct and have historically occurred. The loss is calculated based on a link prediction task. For each step in the training set, the connection from the current API node to the next actually occurring API node is considered a positive sample. Simultaneously, to help the model learn to distinguish between positive and negative samples, one or more API nodes that the current API node has never historically connected to are randomly selected from the graph, forming negative samples. The model outputs a probability distribution for all possible next-hop API nodes, maximizing the predicted probability of positive samples and minimizing the predicted probability of negative samples based on cross-entropy loss.

[0141] Suppose that in a certain training step, the actual next-hop API is The probability predicted by the model is Sample k negative samples The probability predicted by the model is Therefore, the formula for calculating the topological correctness loss in this step is:

[0142]

[0143] By minimizing this loss, the model is incentivized to assign higher probability scores to real, successful API call paths, thereby learning the correct topological connections between APIs.

[0144] Delay penalty loss The goal is to guide the model to favor historically faster paths among all grammatically correct paths. The expected latency of the entire recommended path is modeled as the sum of the historical average latency of all API calls (edges) along the path. During training, for each recommended path (or sub-path) currently predicted by the model, its historical total latency is calculated as the target value. Meanwhile, the model is designed to predict the performance of a path and output a prediction delay. The difference between predicted latency and historical actual latency is calculated based on mean squared error (MSE). For a given data set... Recommended path consisting of API calls Its total historical delay is If the model's prediction delay for this path is... The formula for calculating the delay penalty loss is:

[0145]

[0146] By minimizing this loss, the model implicitly considers the impact of the next API choice on the total latency of the final path when selecting the next API, thus tending to build a sequence of API calls with lower overall latency.

[0147] Error rate penalty loss The goal is to guide the model to avoid API calls or path combinations with historically high failure rates. Similar to latency loss, the historical composite error rate of a path is used as the penalty target. This value can be calculated in several ways, such as by taking the maximum historical failure rate among all API calls along the path, or by calculating a comprehensive failure probability. The model also needs to estimate the reliability of the path and output a predicted failure rate. The model is penalized for recommending high-risk paths based on regression loss (such as MSE or Huber Loss).

[0148] For the recommended path Its historical overall failure rate is , This represents the probability of path failure. If the model's prediction failure rate for this path is... The formula for calculating the error rate penalty loss is:

[0149]

[0150] By weighting and combining these three loss functions, this embodiment can train a system that understands both business logic and... And also focus on performance efficiency It also emphasizes stability and reliability. A smart API orchestration and recommendation model.

[0151] The orchestration generation and execution module serves as a bridge connecting intelligent recommendations with practical deployment, responsible for transforming the model's abstract output into concrete, executable artifacts. Specifically, it performs a translation process, receiving the recommended orchestration scheme (a graph of API nodes and edges) output by the model and translating it into a format understandable by the target execution environment. Supported output formats include:

[0152] Declarative Configuration File: Generates a structured configuration file (such as YAML or JSON) to drive the declarative API orchestration engine. For example, a configuration file conforming to the Apollo GraphQL Federation specification can be generated, defining entities, field resolvers, and how they map to the underlying REST API. This is the preferred output method because it offers good readability and maintainability.

[0153] Script generation: For traditional workflow engines that rely on scripts, scripts in Python, JavaScript, or domain-specific languages ​​(DSLs) can be generated automatically.

[0154] Visual workflow definition: Generate JSON or XML files that can be directly imported by visual orchestration platforms (such as Huawei Cloud, Methodot, etc.), so that the recommended workflows can be displayed and modified intuitively on these platforms.

[0155] The output workflow is automatically deployed to the target API gateway or workflow engine via a CI / CD pipeline. Once deployed, the orchestration logic takes effect immediately and can handle business requests that meet its triggering conditions.

[0156] The fundamental advantage of this embodiment lies in shifting the API orchestration paradigm from a human-guided, tool-assisted manual design model to a data-driven, machine-dominated automatic discovery model. Developers no longer need to spend days or even weeks studying API documentation, sorting out business logic, and manually building workflows. Instead, the system can automatically learn from historical data and generate optimized solutions, reducing development time from days / weeks to minutes, significantly improving R&D efficiency. This embodiment can discover non-intuitive optimal workflows, improving system performance. Machine learning models can explore a much broader solution space than human intuition. By learning from data containing performance metrics (latency, error rate), the model in this embodiment can discover non-intuitive but high-performance API call combinations that human developers might never think of. For example, the model might discover that by calling a seemingly unrelated API first to warm up the cache, the latency of subsequent critical APIs can be significantly reduced. This optimization capability directly translates into lower user response time, less system resource consumption, and lower operating costs. The system in this embodiment is a continuously learning system. Through a closed-loop feedback mechanism, it can continuously learn from newly generated API call data. When a low-level API experiences performance degradation, is deprecated, or a new, more efficient API emerges, the model can promptly capture these changes and proactively recommend updated orchestration schemes better suited to the current environment. This endows the entire software system with a degree of self-healing and self-optimization capabilities, significantly enhancing its resilience in dynamic environments. Since the recommendation model primarily learns patterns from historically successful and efficient execution cases, its generated workflows naturally inherit these excellent characteristics. Compared to poorly tested manual design schemes, workflows generated by this system have a lower expected error rate and higher execution reliability. This helps reduce failures in production environments and improve Quality of Service (QoS). This system embeds the collective wisdom and tacit knowledge inherent in all historical API interactions into the trained model. This means that even junior developers with limited experience can leverage this system to generate expert-level, highly optimized API orchestration schemes. This reduces reliance on senior architects, promotes the dissemination of advanced technical skills, and helps improve the average skill level of the entire development team.

[0157] Corresponding to the above method, the present invention also provides an apparatus / system including a computer device, the computer device including a processor and a memory, the memory storing computer instructions, the processor executing the computer instructions stored in the memory, and when the computer instructions are executed by the processor, the apparatus / system performs the steps of the method as described above.

[0158] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the aforementioned edge computing server deployment method. The computer-readable storage medium can be a tangible storage medium, such as random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, floppy disks, hard disks, removable storage disks, CD-ROMs, or any other form of storage medium known in the art.

[0159] In summary, the application programming interface (API) orchestration model training method, orchestration method, and apparatus described in this invention clean and reconstruct the original API call logs into a directed heterogeneous graph with node and edge features, fully preserving topology, performance, and error patterns. Subsequently, a graph convolutional neural network is used to perform iterative link prediction on the extracted context subgraph, automatically outputting the API call sequence with the highest probability, along with its prediction latency and failure rate, thus achieving automatic generation of orchestration schemes. The joint loss function simultaneously constrains topological correctness, latency, and error rate during the training phase, enabling the model not only to learn the syntactically correct call order but also to proactively pursue the path with optimal performance and lowest risk. This invention significantly shortens the workflow design cycle and reduces labor costs; simultaneously, relying on continuously flowing production data, the model can adaptively optimize as APIs evolve, improving system resilience and scalability.

[0160] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this invention are programs or code segments used to perform the desired tasks. The programs or code segments can be stored in a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave.

[0161] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0162] In this invention, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.

[0163] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, various modifications and variations of the embodiments of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A training method for an application programming interface orchestration model based on call history, characterized in that, The method includes the following steps: Data cleaning and format standardization are performed on application programming interface call logs obtained based on preset data sources. The logs are grouped according to business content or user subject and sorted by timestamp. A directed heterogeneous graph is constructed with application programming interfaces as nodes and their node characteristics recorded, and call relationships as edges and their edge characteristics recorded. Based on the call sequence between one or more specified starting nodes, a business context subgraph is extracted from the directed heterogeneous graph; using the business context subgraph as input, iterative link prediction is performed based on the execution graph convolutional neural network, calculating the probability that the leading node in the business context subgraph is connected to all other candidate nodes, selecting the one with the highest probability to add and update the business context subgraph, repeating the iteration until the business endpoint application programming interface or the node sequence length reaches a preset upper limit, and outputting the prediction result, which includes each node of the predicted workflow path, the prediction delay, and the prediction failure rate; Based on the prediction results and the differences between the historical records in the directed heterogeneous graph, the topology correctness loss, delay penalty loss, and error rate penalty loss are calculated, and a joint loss is constructed to update the parameters of the graph convolutional neural network, resulting in an application programming interface orchestration model.

2. The application programming interface orchestration model training method based on call history according to claim 1, characterized in that, Data cleaning and format standardization are performed on application programming interface call logs obtained from preset data sources, including: The application programming interface call logs are obtained using the application programming interface gateway, service mesh, application performance monitoring system, or application server log system as the preset data source. Invalid fields in the application programming interface call log are removed, and missing data is filled, including filling missing numeric fields with mean, median or default value, and filling missing categorical fields with preset markers. The timestamps in the application programming interface call logs are converted into a unified Coordinated Universal Time (UTC) format, mapping API paths with the same semantics but different parameter values ​​to a unique, unchanging, preset standard form.

3. The application programming interface orchestration model training method based on call history according to claim 1, characterized in that, The node features include static category features and dynamic statistical features; The static category features include the application programming interface function type, the microservice to which it belongs, and the authentication level; the dynamic statistical features include average latency, historical error rate degradation call frequency; The edge features include time features, context features, and result features. The time features include the call time point and the time difference within the session. The context features include the request / response size and request parameter features. The result feature indicates whether the call was successful.

4. The application programming interface orchestration model training method based on call history according to claim 1, characterized in that, The graph convolutional neural network is obtained by stacking multiple graph attention network layers, and the graph attention network layers are constructed based on a multi-head attention mechanism.

5. The application programming interface orchestration model training method based on call history according to claim 4, characterized in that, The formula for calculating the topological correctness loss is: in, This represents the loss in topological correctness. Indicates the actual next-hop node. This represents the i-th negative sample node among the candidate nodes, excluding the actual next-hop node. This represents the predicted probability of the actual next-hop node. represents the predicted probability of the negative sample node; k represents the total number of negative sample nodes; The formula for calculating the delay penalty loss is: in, This represents the delay penalty loss. The predicted delay represents the predicted workflow path. This represents the total historical latency of each edge within the predicted workflow path. Let represent the i-th edge, and n represent the total number of edges; This represents the historical average delay of the i-th edge; The formula for calculating the error rate penalty loss is: in, This represents the error rate penalty loss. This indicates a prediction of the overall failure rate of the predicted workflow path. This represents the historical overall failure rate of the predicted workflow path. This represents the historical path failure probability of the i-th edge within the predicted workflow path; The formula for calculating the joint loss is: in, Indicates the joint loss, and These are the weighting coefficients.

6. A method for orchestrating application programming interfaces based on call history, characterized in that, The method includes the following steps: Construct an initial subgraph based on the user-specified application programming interface (API) start node or the initial API call list contained in the user session; The initial subgraph is input into the application programming interface orchestration model in the application programming interface orchestration model training method based on call history as described in any one of claims 1 to 5, and the nodes of the predicted workflow path, the prediction latency, and the prediction failure rate are output to form an application programming interface list.

7. The application programming interface orchestration method based on call history according to claim 6, characterized in that, The method further includes: The application programming interface list is translated and output into corresponding workflows according to a preset format and deployed through a CI / CD pipeline. The preset format includes: declarative configuration files, computer language scripts, and visual workflows displayed on a visualization platform.

8. An application programming interface orchestration apparatus based on call history, comprising a processor, a memory, and computer programs / instructions stored in the memory, characterized in that, The processor is configured to execute the computer program / instructions, and when the computer program / instructions are executed, the device implements the steps of the method as described in any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method as described in any one of claims 1 to 7.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 7.

Images