RESTful API intelligent application method and system based on large language model

Abstract

The invention discloses a RESTful API intelligent application method based on a large language model, and the method comprises the following steps: automatically extracting API endpoints, parameter entities and response code information from an OpenAPI standard document, a source code annotation, HAR flow data, a WITSML standard data stream of a petroleum drilling geological design system, and an SDK document of Landmark and Schlumberger platforms through employing a BERT series model in combination with a rule template; the method comprises the following steps of: vectorizing a natural language instruction input by a user through a Sension-BERT model; calculating a comprehensive score based on three dimensions of cosine similarity of a query vector and an API description vector, a Jaccard similarity coefficient of a parameter set and a historical calling frequency; an API calling request is constructed and executed, a dynamic timeout threshold value based on a historical response time P95 quantile is set, and a backspacing strategy related to the field is configured for a key API. According to the method, end-to-end intelligent API calling is realized, multidisciplinary data islands such as geology and engineering are effectively broken through, and the automation level and service continuity of complex system integration are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of interdisciplinary technology of artificial intelligence and software development, and in particular to a method and system for intelligent application of RESTful API based on a large language model. Background Technology

[0002] With the popularization of microservice architecture, RESTful APIs have become the mainstream method for inter-system communication. In professional fields such as oil drilling geology design, engineers need to frequently call scattered and terminologically complex interfaces such as geological data APIs, well trajectory calculation APIs, and drilling fluid performance APIs, which presents significant technical pain points: traditional calling methods rely heavily on expert experience, requiring manual concatenation of multiple APIs and handling of complex parameter mappings, a cumbersome and error-prone process; API documentation is outdated and often disconnected from internal algorithm versions; existing tools lack the ability to understand domain semantics (such as "collapse prevention" and "friction torque"), making it difficult to handle ambiguous natural language commands; at the same time, there is a lack of intelligent API combination recommendation, execution optimization, and fault tolerance mechanisms oriented towards business scenarios, resulting in a serious "data silo" phenomenon between geological and engineering software, requiring the repetitive writing of large amounts of code for similar design logic in different projects, leading to low integration efficiency.

[0003] While large language models have made progress in code generation, existing technologies such as Toolformer and LangChain are primarily geared towards general scenarios, mainly addressing single API call issues and failing to deeply adapt to the specific needs of complex industrial systems. Existing API management patents, although involving technologies such as knowledge graph construction and semantic matching, lack dynamic evolution capabilities for API version iterations, adaptive fault-tolerance strategies based on historical performance, and cross-disciplinary parameter-dependent graph neural network combinatorial optimization methods. Therefore, there is an urgent need for an intelligent API application solution that deeply integrates domain knowledge and possesses dynamic learning and industrial-grade reliability. Summary of the Invention

[0004] The purpose of this invention is to provide a method and system for intelligent application of RESTful API based on a large language model, thereby solving the aforementioned problems existing in the prior art.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0006] A method for intelligent application of RESTful APIs based on a large language model includes the following steps:

[0007] The BERT series models are used in combination with rule templates to automatically extract API endpoint, parameter entity and response code information from OpenAPI specification documents, source code comments, HAR flow data and WITSML standard data flow of oil drilling geological design system, Landmark and Schlumberger platform SDK documents.

[0008] The extracted API entities are constructed into a knowledge graph. The GraphSAGE incremental learning algorithm is used to update the subgraph embedding representation by sampling neighbor nodes when API changes are detected, thereby realizing the dynamic evolution of the graph.

[0009] The natural language commands input by the user are vectorized using the Sentence-BERT model, and the fine-tuned large language model is used to identify key entities and operation intentions. The execution order is determined by semantic role labeling.

[0010] The comprehensive score is calculated based on three dimensions: cosine similarity between the query vector and the API description vector, Jaccard similarity coefficient of the parameter set, and historical call frequency. The optimal combination sequence is selected based on parameter dependencies in the API combination graph using a scoring function.

[0011] Construct and execute API call requests, set dynamic timeout thresholds based on the 95th percentile of historical response times, dynamically adjust the maximum number of retries based on the recent success rate ρ, and configure domain-specific fallback strategies for critical APIs.

[0012] Preferably, the node types of the knowledge graph include APIEndpoint, Parameter, ResponseCode, and extended GeologicalFormation and EngineeringOperation professional nodes;

[0013] Relation types include HAS_PARAMETER, RETURNS, OF_TYPE, and extended LOCATED_IN and AFFECTS domain relations;

[0014] The dynamic evolution follows the formula G_{t+1}=Update(G_t,ΔG).

[0015] Preferably, for the instruction "obtain the pore pressure of well XX at 3500 meters and calculate the equivalent circulating density", the system identifies the entities "well XX", "3500 meters", "pore pressure", and "equivalent circulating density", and the intent is "obtain" and "calculate". The execution order is to obtain the pressure first and then calculate the density.

[0016] Preferably, the comprehensive score adopts the formula S_total=α·S_semantic+β·S_functional+γ·S_popularity, and the weight coefficients α,β,γ are determined by training a linear regression model on the labeled dataset.

[0017] Preferably, the scoring function is:

[0018] Score(C) = w1·Coverage(C) + w2·ParameterMatch(C) + w3·(1 / Length(C)) + w4·Reliability(C), where the weight coefficients w1~w4 are determined by reinforcement learning or ranking models.

[0019] Preferably, in the oil drilling geological design scenario, for the instruction "design horizontal well trajectory and evaluate friction torque", the system automatically finds the execution path GetGeologicalTarget→CalculateWellPath→SimulateTorqueDrag in the knowledge graph and uses the output of the upstream API as the input of the downstream API.

[0020] Preferably, the dynamic retry count K_max is set as follows: K_max=2 when ρ<0.9, and K_max=5 when ρ≥0.95, where ρ represents the recent historical call success rate of the API.

[0021] Preferably, the fallback strategy is as follows: when the API for obtaining real-time logging-while-drilling data fails, it automatically switches to the backup API for obtaining the most recent valid cached data.

[0022] Based on the same concept, a RESTful API intelligent application system based on a large language model includes:

[0023] The API entity extraction module is configured to perform data source extraction and entity recognition.

[0024] The dynamic knowledge graph module is configured to perform incremental updates to GraphSAGE.

[0025] The semantic understanding module is configured to perform vectorization and intent recognition.

[0026] The API recommendation module is configured to perform multi-dimensional matching and combined recommendations.

[0027] The fault-tolerant execution module is configured to implement dynamic optimization and rollback mechanisms.

[0028] In another embodiment, a computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the above-described method.

[0029] The beneficial effects of this invention are:

[0030] End-to-end intelligence: It realizes full-process automation from natural language instruction parsing, intelligent API matching, combination recommendation to reliable execution, without human intervention, which greatly reduces the professional threshold for cross-disciplinary API calls.

[0031] Dynamic knowledge evolution: Employing the GraphSAGE incremental learning algorithm, it supports local embedding updates and graph alignment fusion when API versions change, ensuring real-time synchronization between the knowledge base and API documentation, effectively solving the problem of lag in traditional static documentation.

[0032] Precise Combination Recommendation: By using graph neural networks to search for paths based on parameter dependencies in the API combination graph, and combining multi-dimensional scoring such as coverage, parameter matching degree, path length and reliability, the rationality and execution success rate of API sequences in complex tasks are significantly improved.

[0033] Industrial-grade fault tolerance: A dynamic timeout mechanism based on historical performance percentiles, a retry strategy that adaptively adjusts based on recent success rates, and predefined fallback paths for critical business operations in the oil industry are designed to ensure business continuity of the system in unstable network environments.

[0034] Domain-level deep adaptation: By expanding the types and relationships of professional nodes such as geological strata and engineering operations, and combining the WITSML standard data stream with the automated extraction of professional software SDKs, deep semantic support for special industrial scenarios such as oil drilling geological design is achieved, breaking through the domain limitations of general tools. Attached Figure Description

[0035] Figure 1 This is the overall system architecture diagram of the present invention;

[0036] Figure 2 This is a flowchart of the dynamic knowledge graph construction and updating process of this invention;

[0037] Figure 3 This is a schematic diagram of the API combination recommendation and execution sequence generation of the present invention;

[0038] Figure 4 This is a flowchart illustrating the fault tolerance and retry mechanism of the present invention.

[0039] Figure 5 This is a flowchart of the method of the present invention. Detailed Implementation

[0040] 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. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0041] Reference Figures 1 to 5 The method for intelligent application of RESTful API based on a large language model, as shown, includes the following steps:

[0042] S1. From the OpenAPI specification document, source code comments, HAR flow data, and WITSML standard data stream of the oil drilling geological design system, as well as the SDK documents of the Landmark and Schlumberger platforms, the BERT series models combined with rule templates are used to automatically extract API endpoint, parameter entity and response code information.

[0043] This step specifically aims to comprehensively capture API metadata information from diverse heterogeneous data sources and build a structured API knowledge foundation through automated means. The implementation process involves the following three levels of technical processing:

[0044] First, at the data source access level, the system supports parallel scanning and parsing of six typical data sources. The first category is standardized interface description documents, namely OpenAPI specification documents (formerly Swagger documents). These documents typically define the API access path, request methods, input / output parameter structures, and data type constraints in a machine-readable format. The second category is source code-level comments. Through static code analysis, the system deeply traverses the project codebase to identify interface description comments added by developers, especially tag-based comments for key metadata such as parameter definitions and return value descriptions. The third category is network traffic capture data. The system can parse HAR format message records to reconstruct the API call patterns, parameter passing methods, and status code distribution characteristics from actual HTTP requests and responses. Categories four through six are proprietary data sources in the field of oil drilling geological design, including drilling data streams conforming to the WITSML international standard, secondary development SDK interface documents provided by mainstream professional software platforms in the industry (such as Landmark and Schlumberger), and API documentation for self-built geological model microservices within the oilfield. These sources contain a large number of domain-specific technical parameters and business logic definitions.

[0045] Secondly, at the entity extraction technology implementation level, the system adopts a hybrid architecture that combines deep learning models and a rule engine. A BERT-based named entity recognition model serves as the core component. Pre-trained on massive API document corpora, it gains the ability to understand the semantics of technical text, automatically recognizing key information such as interface names, parameter variables, and data constraints described in the documents. Simultaneously, the system incorporates a configurable rule template engine that sets matching rules for common annotation formats (e.g., JavaDoc-style parameter annotations) and protocol patterns (e.g., RESTful path parameter naming conventions), achieving accurate parsing of structured text. The protocol analysis tool handles raw network traffic, extracting runtime data such as endpoint addresses, request methods, authentication information, and response status from the HTTP message headers, bodies, and status lines. These three technologies complement each other, ensuring efficient extraction across data sources of varying quality.

[0046] Finally, in terms of the scope of content extraction, the system comprehensively identifies five core entities: first, API endpoint information, including complete access paths and supported HTTP methods; second, parameter entities, covering the name, data type, whether it is required, and value range of input parameters; third, response code information, including various status codes and their business meaning explanations; fourth, logical relationships between parameters, such as dependency relationships and mutual exclusion relationships; and fifth, business attribute tags, such as the unit of measurement and geological engineering meaning of parameters. In the specific application of the oil drilling geological design system, it can accurately extract the CalculateWellTrajectory endpoint of the well trajectory calculation API and its required well inclination parameter inclination, azimuth parameter, as well as the GetFormationTop interface of the formation data service and the corresponding formation pressure parameter formationPressure. At the same time, it identifies the physical units and data accuracy requirements of these parameters in engineering practice, thereby establishing a computable and reasonable API metadata foundation.

[0047] S2. Construct the extracted API entities into a knowledge graph and use the GraphSAGE incremental learning algorithm to update the subgraph embedding representation by sampling neighbor nodes when API changes are detected, so as to realize the dynamic evolution of the graph.

[0048] Specifically, this step aims to construct a knowledge graph with semantic expressive capabilities from the extracted API entities and their inherent relationships, and to achieve dynamic updates of the graph as the API version evolves through an incremental learning mechanism, ensuring the continuous effectiveness of the knowledge base.

[0049] First, in the ontology construction phase of the knowledge graph, the system abstracts API metadata into various types of nodes and relationships. At the node level, APIEndpoint nodes are defined to represent each interface endpoint, with attributes carrying the interface's access path, HTTP method type, and functional description text; Parameter nodes are defined to describe input and output parameters, including parameter names, data types, and whether they are required; ResponseCode nodes are defined to record HTTP status codes and their corresponding business meanings. Considering the professional characteristics of oil drilling geological design, the system further expands the node types, adding GeologicalFormation nodes to characterize geological stratigraphic features and EngineeringOperation nodes to describe engineering operation types, enabling the graph to express concepts specific to the geological engineering field. At the relationship level, HAS Parameter relationships are established to connect API endpoints with their associated parameters, RETURNS relationships are established to connect API endpoints with possible response codes, and OF_TYPE relationships are established to declare the data type affiliation of parameters. At the same time, domain-specific relationships are expanded, such as the LOCATED IN relationship used to describe the spatial association between wellbore location and formation horizon, and the AFFECTS relationship used to characterize the influence path of engineering parameters on calculation results, thereby constructing a semantic network that supports complex reasoning.

[0050] Secondly, regarding the dynamic evolution mechanism of the knowledge graph, the system employs an incremental learning algorithm based on the GraphSAGE architecture to address iterative changes in the API. When the monitoring mechanism detects an update to the API documentation version or a modification to the source code interface definition, the system does not reconstruct the entire knowledge graph. Instead, it precisely identifies the local subgraph regions affected by the change. Specifically, for each changed node, the algorithm performs impact propagation analysis only within its local neighborhood. This process involves sampling the set of neighboring nodes of the node, recalculating the embedding representation of the affected region, and then using an alignment mechanism to perform semantic consistency matching and fusion between the updated subgraph embedding and the existing embeddings of the unchanged parts of the knowledge graph, thereby achieving smooth evolution of the knowledge graph. This incremental approach significantly reduces computational overhead, enabling the knowledge graph to keep pace with the rapid iteration of API versions.

[0051] Finally, in the specific practice of the oil drilling geological design system, the dynamic knowledge graph successfully established semantic associations between cross-disciplinary APIs. For example, when the GetGeologicalTarget interface adds a target layer prediction confidence parameter due to a geological model upgrade, the system immediately detects the change, locates the GetGeologicalTarget node and its downstream dependent CalculateWellPath node, updates the embedding representation of these two nodes through neighbor sampling, and adjusts the weight distribution of the HASParameter relationship. The recalculated graph still maintains overall semantic alignment with the original graph, ensuring that the subsequent API recommendation module can accurately identify the role of the new parameters in the well trajectory design process, maintaining the robustness and timeliness of the entire intelligent application system.

[0052] S3. Vectorize the natural language commands input by the user through the Sentence-BERT model, and use the fine-tuned large language model to identify key entities and operation intentions, and determine the execution order through semantic role labeling.

[0053] This step specifically involves converting natural language instructions into a machine-understandable structured semantic representation, enabling precise intent parsing and execution logic sequencing.

[0054] First, the system employs Sentence-BERT as its core semantic embedding engine, mapping user-input text commands into high-dimensional vector representations. Considering the specific characteristics of the oil drilling field, the model undergoes domain-adaptive training: a massive corpus of drilling design reports, engineering operation instructions, and geological analysis documents is collected. A contrastive learning mechanism is used to enhance the semantic representation capabilities of technical terms, enabling the vector representations of terms such as "frictional torque" and "equivalent cyclic density" to accurately capture their technical connotations within the engineering context. This significantly improves the matching accuracy with domain interface descriptions in the API knowledge base.

[0055] Secondly, a fine-tuned large language model is used to perform deep semantic understanding tasks. Based on the Qwen or LLaMA architecture, this model is supervised and fine-tuned on thousands of manually annotated petroleum engineering instruction samples to develop sequence labeling capabilities. The model parses the input text word by word, identifying three types of key information: entity tags (such as well number, depth, geological parameters, and engineering indicators), intent tags (such as verbs like "acquire," "calculate," "optimize," and "evaluate"), and constraints (such as numerical range and unit requirements). Simultaneously, semantic role labeling technology is used to analyze predicate-argument structures, identify verb-object dependencies, and automatically infer the potential execution sequence of "first...then...".

[0056] Finally, the parsing effect is illustrated using a typical drilling scenario as an example: When the input is "Get the pore pressure of well XX at 3500 meters and calculate the equivalent circulating density", the system first generates a query vector that integrates geological semantics through Sentence-BERT, and then the fine-tuned LLM labels the entities "well XX", "3500 meters", "pore pressure", "equivalent circulating density" and the intents "get" and "calculate" to identify them. Then, through semantic role analysis, the result of the "get" action is determined as the input of the "calculate" action, forming an immutable execution order constraint, which provides an accurate decision basis for subsequent API combination recommendations.

[0057] S4. Calculate the comprehensive score based on three dimensions: cosine similarity between the query vector and the API description vector, Jaccard similarity coefficient of the parameter set, and historical call frequency. Then, select the optimal combination sequence based on parameter dependencies in the API combination graph using a scoring function.

[0058] Specifically, this step involves using a two-stage intelligent decision-making mechanism to achieve accurate API matching and optimal combination sequence recommendation.

[0059] In the single API matching phase, the system comprehensively evaluates the fit between candidate APIs and instructions from three complementary dimensions. The first dimension calculates the cosine of the spatial angle between the query vector and the API description text, measuring semantic similarity to ensure the recommended interface is highly relevant to the user's intent in terms of functional description. The second dimension uses set operations to compare the set of parameter names extracted from the user instruction with the set of parameters in the API definition, calculating the intersection ratio to evaluate the interface's functional matching degree at the parameter level. The third dimension statistically analyzes the historical call frequency of the interface, assigning appropriate weights to frequently used, mature APIs to reflect the reliability of practical verification. The scores from these three dimensions are dynamically weighted and fused using a pre-trained linear regression model to form the final similarity ranking.

[0060] In the combinatorial recommendation phase, the system constructs an API call dependency graph as the search space. Each node in the graph represents a candidate API. If there is a data dependency between two interfaces (i.e., the output parameter of one API can be used as the input parameter of another API), a directed connection is established. For multiple operation intentions identified in complex tasks, the system searches the graph for the shortest dependency path that covers all operations, prioritizing connections with complete parameter type matching. Path scoring comprehensively considers instruction entity coverage, the quality of parameter connection between adjacent APIs, the reasonableness of path length, and the historical reliability performance of each node. The weight allocation of each scoring item is dynamically optimized through reinforcement learning algorithms.

[0061] Taking the oil drilling scenario as an example, when the instruction is "design horizontal well trajectory and evaluate friction torque", the system first identifies the well trajectory calculation and friction torque simulation interfaces in the similarity ranking. Then, it detects in the combined graph that the trajectory point data structure output by the former exactly matches the input requirements of the latter, forming a natural dependency chain. The finally recommended three-interface combination GetGeologicalTarget→CalculateWellPath→SimulateTorqueDrag performs best in terms of coverage, matching degree, and reliability score, achieving seamless integration of geological target acquisition, wellbore trajectory calculation, and engineering risk simulation.

[0062] S5. Construct and execute API call requests, set a dynamic timeout threshold based on the 95th percentile of historical response time, dynamically adjust the maximum number of retries according to the recent success rate ρ, and configure domain-related fallback strategies for critical APIs.

[0063] This step specifically involves: completing the actual construction, scheduling, execution, and industrial-grade reliability assurance of the API request.

[0064] During the request construction phase, the system automatically extracts corresponding values ​​from the parameter pool and maps them to the data format defined by the interface, based on the entity, operation intent, and recommended API combination parsed from the preceding modules. This generates a complete request message that conforms to the HTTP protocol specification, including dynamic URL path filling, injection of authentication information into the request header, and JSON serialization of the request body. For API sequences with dependencies, a topology sorting algorithm is used to determine a strict execution order, ensuring that the output parameters of the upstream interface are correctly passed to the input domain of the downstream interface. For independent interface calls, a parallel scheduling strategy is adopted to shorten the overall response time, and a semaphore mechanism is used to control the maximum concurrency to prevent server overload.

[0065] In terms of dynamic fault tolerance, the system maintains an independent performance baseline for each API. The timeout threshold is set based on the statistical distribution of the API's historical response time, selecting the 95th percentile as the boundary value. This avoids premature timeouts that discard normal requests while promptly interrupting abnormal calls. The retry strategy is dynamically linked to API quality, continuously tracking recent call success rates. More retries are allowed for stable APIs to handle occasional failures, while retries are reduced for frequently failing APIs to avoid resource waste. For critical business scenarios in oil drilling, a tiered fallback plan is pre-configured: when an API for real-time logging data acquisition fails due to downhole signal interruption, the system automatically switches to reading the most recently cached valid data; if the cache is still unavailable, it reverts to using historical data from neighboring wells for estimation, ensuring that the drilling design process can obtain acceptable computational input under any circumstances, thereby maintaining overall business continuity.

[0066] Preferably, the node types of the knowledge graph include APIEndpoint, Parameter, ResponseCode, and extended GeologicalFormation and EngineeringOperation professional nodes;

[0067] Relation types include HAS_PARAMETER, RETURNS, OF_TYPE, and extended LOCATED_IN and AFFECTS domain relations;

[0068] The dynamic evolution follows the formula G_{t+1}=Update(G_t,ΔG).

[0069] Preferably, for the instruction "obtain the pore pressure of well XX at 3500 meters and calculate the equivalent circulating density", the system identifies the entities "well XX", "3500 meters", "pore pressure", and "equivalent circulating density", and the intent is "obtain" and "calculate". The execution order is to obtain the pressure first and then calculate the density.

[0070] Preferably, the comprehensive score adopts the formula S_total=α·S_semantic+β·S_functional+γ·S_popularity, and the weight coefficients α,β,γ are determined by training a linear regression model on the labeled dataset.

[0071] Preferably, the scoring function is:

[0072] Score(C) = w1·Coverage(C) + w2·ParameterMatch(C) + w3·(1 / Length(C)) + w4·Reliability(C), where the weight coefficients w1~w4 are determined by reinforcement learning or ranking models.

[0073] Preferably, in the oil drilling geological design scenario, for the instruction "design horizontal well trajectory and evaluate friction torque", the system automatically finds the execution path GetGeologicalTarget→CalculateWellPath→SimulateTorqueDrag in the knowledge graph and uses the output of the upstream API as the input of the downstream API.

[0074] Preferably, the dynamic retry count K_max is set as follows: K_max=2 when ρ<0.9, and K_max=5 when ρ≥0.95, where ρ represents the recent historical call success rate of the API.

[0075] Preferably, the fallback strategy is as follows: when the API for obtaining real-time logging-while-drilling data fails, it automatically switches to the backup API for obtaining the most recent valid cached data.

[0076] Based on the same concept, a RESTful API intelligent application system based on a large language model includes:

[0077] The API entity extraction module is configured to perform data source extraction and entity recognition.

[0078] The dynamic knowledge graph module is configured to perform incremental updates to GraphSAGE.

[0079] The semantic understanding module is configured to perform vectorization and intent recognition.

[0080] The API recommendation module is configured to perform multi-dimensional matching and combined recommendations.

[0081] The fault-tolerant execution module is configured to implement dynamic optimization and rollback mechanisms.

[0082] In another embodiment, a computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the above-described method.

[0083] In this embodiment, the aforementioned RESTful API intelligent application method based on a large language model is solidified in the form of a computer program on a physical storage medium, forming a distributable and deployable software product, thereby realizing the transformation of the technical solution of the method claims into a product form.

[0084] The storage medium is manufactured using non-volatile storage technology, including but not limited to physical forms such as flash memory chips, magnetic storage disks, or optical storage disks. Internally, the medium is divided into multiple logical storage areas, each housing one of the five core program modules required for system operation: the API entity extraction module stores the data in binary instruction sequences, including BERT model weight parameters, rule template libraries, and a protocol parsing engine; the dynamic knowledge graph module stores the graph neural network structure definition, incremental update algorithm logic, and graph serialization data; the semantic understanding module incorporates a Sentence-BERT vectorization engine and fine-tuned large language model inference code; the API recommendation module stores similarity calculation routines, combined path search algorithms, and reinforcement learning weight adjustment mechanisms; and the fault-tolerant execution module encapsulates a dynamic timeout timer, a success rate statistician, and a backoff strategy decision tree.

[0085] When the storage medium is connected to a general-purpose computer system, the processor reads the boot program from the storage medium through the bus interface and loads the various functional modules into the memory partition. During loading, the processor first initializes the API entity extraction module, establishing a data source connection pool and model inference context in memory; then it activates the dynamic knowledge graph module, deserializing the graph structure data in the storage medium into an adjacency list and node feature matrix in memory; next, it starts the semantic understanding module, completing the loading of language model weights and vector cache warm-up; then it instantiates the API recommendation module, constructing a linear regressor for the scoring function and a reinforcement learning agent; finally, it runs the fault-tolerant execution module, creating a parallel task scheduler and a fallback policy registry. Each module exchanges data in memory through a message queue, forming a complete runtime instance.

[0086] In oil drilling geological design scenarios, this storage medium can be deployed on physical servers in oilfield data centers or burned onto solid-state drives in edge computing devices. When deployed in a data center, the program accesses centrally stored WITSML data streams and SDK documentation via a fiber optic network to handle concurrent design requests from multiple users. When deployed on edge devices, the program parses a lightweight knowledge graph copy locally, providing on-site engineers with intelligent API invocation capabilities in an offline environment. The rollback policy configuration table in the storage medium can be dynamically updated according to the deployment environment, ensuring that the data center version prioritizes the use of real-time data APIs, while the edge version enables cached rollback paths by default.

[0087] Version management of this computer program product is achieved through digital signatures bound to the storage medium. A new version image is generated after each map update or model optimization and written to a write-protected storage area to prevent accidental tampering during operation. Logs and performance statistics generated during program runtime are asynchronously written to a separate partition of the storage medium, providing training data for subsequent algorithm iterations.

[0088] Protecting the technical solution of this invention in the form of a storage medium has legal significance in transforming the method claim into a quasi-product claim, covering commercial activities such as software distribution, pre-installation sales, and cloud image deployment, effectively preventing unauthorized program copying and reverse engineering. The industry can obtain the complete functionality of this invention by purchasing storage media containing the program or downloading the official image file, without needing to build complex model training and algorithm optimization environments, significantly reducing the technical threshold and implementation cost of digital transformation for petroleum companies.

[0089] In another embodiment, the present invention constructs a three-layer architecture of "semantic understanding - knowledge fusion - dynamic decision-making" (e.g.) Figure 1As shown, this system enables end-to-end intelligent conversion from natural language to API calls. It innovatively combines deep learning models with knowledge graph technology, solving technical challenges in traditional API calls such as semantic gaps, parameter adaptation, and combinatorial optimization. This invention is particularly suitable for complex business systems such as drilling geological design, automatically converting engineers' natural language instructions (e.g., "Design a horizontal well and evaluate friction torque") into a series of ordered, parameter-matched API call sequences, greatly improving design efficiency and quality.

[0090] Specifically, the following steps are included:

[0091] Step 1: API Entity Extraction and Structuring

[0092] Automatically identify and structure API endpoints and their parameter information from multiple data sources.

[0093] 1. Data sources: These include, but are not limited to, the system's OpenAPI (Swagger) specification documentation, source code comments, and network traffic capture data (such as HAR files). In drilling geological design system applications, data sources specifically include WITSML standard data streams, SDK documentation for professional software (such as Landmark and Schlumberger platforms), and API documentation for internal geological model services.

[0094] 2. Extraction technology: A named entity recognition model based on the BERT series is adopted, and a combination of rule templates (such as parsing @param comments) and protocol analysis tools (such as parsing HTTP requests / responses) is used for joint extraction.

[0095] 3. Extracted Entities: These include API endpoints, parameter entities, data types, HTTP methods (such as GET, POST), and response codes (such as 200, 404). [Example Application] In a drilling geology design system, extracted entities include: API endpoints such as CalculateWellTrajectory and GetFormationTop, and parameter entities such as inclination (well inclination angle parameter) and formationPressure (formation pressure parameter).

[0096] Step 2: Construction and Update of Dynamic Knowledge Graph

[0097] 1. Knowledge Graph Construction: Construct a semantically rich knowledge graph from the entities and their relationships extracted in step one.

[0098] Node type:

[0099] APIEndpoint: Represents an API endpoint, with attributes including path, method, and description.

[0100] Parameter: Represents input / output parameters, with attributes including name, type, and required.

[0101] ResponseCode: Represents the HTTP status code, with attributes including code and meaning.

[0102] To support domain applications, it can be expanded to include specialized node types such as GeologicalFormation and EngineeringOperation.

[0103] Relationship types include: HAS_PARAMETER (endpoint has parameters), RETURNS (endpoint returns status code), OF_TYPE (parameter belongs to a certain type), etc. It can be extended to relationships in areas such as LOCATED_IN (wellbore is located in the formation) and AFFECTS (parameter affects the result).

[0104] 2. Dynamic update mechanism: To adapt to the iteration and changes of API versions, an incremental update algorithm for knowledge graph based on graph neural network embedding representation is designed.

[0105] Algorithm formula: G_{t+1}=Update(G_t,ΔG).

[0106] Specific implementation: An incremental learning approach based on GraphSAGE is adopted. When an API document or code change (ΔG) is detected, the model updates the embedding representation of the affected subgraph by sampling neighbor nodes and aligns and merges it with the original graph G_t to achieve dynamic evolution of the knowledge graph.

[0107] Step 3: Semantic Understanding and Intent Parsing

[0108] 1. Semantic Embedding: User-input natural language commands are vectorized using a dedicated semantic embedding model (such as Sentence-BERT) to obtain a high-dimensional query vector Q. For specialized domains, the model needs to be trained with domain-adaptive corpora such as drilling design reports and engineering instructions, or the semantic similarity weights need to be adjusted during the retrieval process.

[0109] 2. Intent and Entity Recognition: Sequence labeling is performed using a finely tuned large language model (or a small BERT variant) to extract key information from instructions.

[0110] Entity recognition: Identify entities in the instruction.

[0111] Intent recognition: Identify the operational intent and identify the potential execution order through semantic role labeling.

[0112] [Example of Domain Application] For the instruction "Get the pore pressure of well XX at 3500 meters and calculate the equivalent circulating density", the system should identify the entities: "well XX", "3500 meters", "pore pressure", and "equivalent circulating density"; the intent: "get", "calculate"; the order: get the pressure first, then calculate the density.

[0113] Step 4: Intelligent API Matching and Recommendation

[0114] 1. Multi-dimensional similarity calculation: A fusion strategy is adopted to comprehensively evaluate the matching degree between candidate APIs and user instructions.

[0115] ①Comprehensive scoring formula: S_total=α·S_semantic+β·S_functional+γ·S_popularity

[0116] Semantic similarity (S_semantic): Calculated based on the cosine similarity between the query vector Q and the API endpoint description vector.

[0117] Functional similarity (S_functional): Measured by comparing the Jaccard similarity coefficients of parameters extracted from user commands with the set of API parameters.

[0118] Popularity similarity (S_popularity): based on historical call data,

[0119] S_popularity=log(1+count(api_call)).

[0120] ② Weight determination: The weight coefficients α, β, γ are determined by training a linear regression model on a labeled dataset or by using grid search.

[0121] 2. API combination recommendation based on graph neural networks (suitable for complex tasks):

[0122] ① Construct an API Combination Graph: Extend and construct an API combination graph within the knowledge graph, with nodes representing candidate API endpoints. If there is a parameter dependency between two API endpoints (i.e., the output parameter of one API is the input parameter of another API), then establish a directed edge between them.

[0123] ② Finding candidate combinations: Based on the operation execution order identified in step 3, find paths or directed acyclic graphs in the API combination graph that can cover all operations and satisfy parameter dependencies.

[0124] ③ Combination ranking and selection: Score the candidate combination C and select the highest-scoring combination.

[0125] Scoring function: Score(C) = w1·Coverage(C) + w2·ParameterMatch(C) +

[0126] w3·(1 / Length(C))+w4·Reliability(C)

[0127] Coverage: The proportion of operations and entities in a combined covered instruction.

[0128] Parameter Match: The degree to which parameter types and names match between adjacent APIs in a combination.

[0129] Path length: The number of APIs in the combination.

[0130] Reliability: An average reliability score calculated based on the API's historical call success rate and version stability.

[0131] Weight coefficients (w1~w4): determined through reinforcement learning or by training a ranking model on historical interaction data.

[0132] [Example of application in the field]: For the instruction "Design horizontal well trajectory and evaluate friction torque", the system may find the path in the knowledge graph: GetGeologicalTarget→CalculateWellPath→SimulateTorqueDrag, and automatically use the output of the upstream API (such as trajectory points) as the input of the downstream API.

[0133] Step 5: Dynamic Execution and Optimization

[0134] 1. Request Construction: Based on the parsed entities, operations, and recommended APIs, automatically extract and concatenate request parameters to construct a compliant HTTP request (including URL, Header, and Body).

[0135] 2. API Execution and Scheduling:

[0136] Dependency analysis: API composition is modeled as a dependency graph G=(V,E), and the execution sequence S of APIs with dependencies is determined by topological sorting.

[0137] Dynamic scheduling: For APIs with no dependencies, parallel execution is used to reduce latency, and a semaphore mechanism is used to set the maximum concurrency C_max to prevent resource overload. The executor monitors the response time and status code of each request.

[0138] 3. Multi-layered fault tolerance mechanism:

[0139] ① Error detection:

[0140] Real-time monitoring: Set a dynamic timeout threshold t_timeout (based on the P95 quantile of the API’s historical response time) for each request Request_i.

[0141] Status code verification: Classify the response status code s into retryable errors (s≥500 or s=429) and non-retryable errors (s∈[400,499]).

[0142] Content validation: Use JSONSchema to perform schema validation on the response body.

[0143] ② Error handling strategy:

[0144] Fallback mechanism: Predefine alternative APIs for critical APIs. For example, when the API that retrieves real-time logging-while-drilling (LWD) data fails, automatically switch to the backup API that retrieves the most recent valid cached data to ensure that the design process is not interrupted.

[0145] Local retry: The intelligent retry policy is only triggered for retryable errors.

[0146] Request downgrade: If all alternatives fail, return cached historical results or preset default values.

[0147] ③ Intelligent retry strategy:

[0148] Retry condition: It is only initiated if error e belongs to the retryable error set E_retry={network error,5xx,429}.

[0149] Adaptive retries: The retry controller dynamically adjusts the maximum number of retries K_max based on the recent historical success rate ρ (the success rate of the most recent N calls) of the API. For example, if ρ < 0.9, then K_max = 2; if ρ ≥ 0.95, then K_max = 5.

[0150] By adopting the above-disclosed technical solution of this invention, the following beneficial effects are obtained:

[0151] End-to-end intelligence: It realizes full-process automation from natural language instruction parsing, intelligent API matching, combination recommendation to reliable execution, without human intervention, which greatly reduces the professional threshold for cross-disciplinary API calls.

[0152] Dynamic knowledge evolution: Employing the GraphSAGE incremental learning algorithm, it supports local embedding updates and graph alignment fusion when API versions change, ensuring real-time synchronization between the knowledge base and API documentation, effectively solving the problem of lag in traditional static documentation.

[0153] Precise Combination Recommendation: By using graph neural networks to search for paths based on parameter dependencies in the API combination graph, and combining multi-dimensional scoring such as coverage, parameter matching degree, path length and reliability, the rationality and execution success rate of API sequences in complex tasks are significantly improved.

[0154] Industrial-grade fault tolerance: A dynamic timeout mechanism based on historical performance percentiles, a retry strategy that adaptively adjusts based on recent success rates, and predefined fallback paths for critical business operations in the oil industry are designed to ensure business continuity of the system in unstable network environments.

[0155] Domain-level deep adaptation: By expanding the types and relationships of professional nodes such as geological strata and engineering operations, and combining the WITSML standard data stream with the automated extraction of professional software SDKs, deep semantic support for special industrial scenarios such as oil drilling geological design is achieved, breaking through the domain limitations of general tools.

[0156] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for intelligent application of RESTful APIs based on a large language model, characterized in that, Includes the following steps: The BERT series models are used in combination with rule templates to automatically extract API endpoint, parameter entity and response code information from OpenAPI specification documents, source code comments, HAR flow data and WITSML standard data flow of oil drilling geological design system, Landmark and Schlumberger platform SDK documents. The extracted API entities are constructed into a knowledge graph. The GraphSAGE incremental learning algorithm is used to update the subgraph embedding representation by sampling neighbor nodes when API changes are detected, thereby realizing the dynamic evolution of the graph. The natural language commands input by the user are vectorized using the Sentence-BERT model, and the fine-tuned large language model is used to identify key entities and operation intentions. The execution order is determined by semantic role labeling. The comprehensive score is calculated based on three dimensions: the cosine similarity between the query vector and the API description vector, the Jaccard similarity coefficient of the parameter set, and the frequency of historical calls. Based on the parameter dependency relationship in the API combinatorial graph, the optimal combinatorial sequence is selected by a scoring function. Construct and execute API call requests, set dynamic timeout thresholds based on the 95th percentile of historical response times, dynamically adjust the maximum number of retries based on the recent success rate ρ, and configure domain-specific fallback strategies for critical APIs.

2. The method according to claim 1, characterized in that, The knowledge graph's node types include APIEndpoint, Parameter, ResponseCode, and extended GeologicalFormation and EngineeringOperation professional nodes; Relation types include HAS_PARAMETER, RETURNS, OF_TYPE, and extended LOCATED_IN and AFFECTS domain relations; The dynamic evolution follows the formula G_{t+1}=Update(G_t,ΔG).

3. The method according to claim 1, characterized in that, For the instruction "Get the pore pressure of well XX at 3500 meters and calculate the equivalent circulating density", the system recognizes the entities "well XX", "3500 meters", "pore pressure", and "equivalent circulating density", and the intents are "get" and "calculate". The execution order is to get the pressure first and then calculate the density.

4. The method according to claim 1, characterized in that, The comprehensive score is calculated using the formula S_total=α·S_semantic+β·S_functional+γ·S_popularity, where the weight coefficients α, β, and γ are determined by training a linear regression model on the labeled dataset.

5. The method according to claim 1, characterized in that, The scoring function is: Score(C) = w1·Coverage(C) + w2·ParameterMatch(C) + w3·(1 / Length(C)) + w4·Reliability(C), where the weight coefficients w1~w4 are determined by reinforcement learning or ranking models.

6. The method according to claim 1, characterized in that, In the oil drilling geological design scenario, for the instruction "Design horizontal well trajectory and evaluate friction torque", the system automatically finds the execution path GetGeologicalTarget→CalculateWellPath→SimulateTorqueDrag in the knowledge graph and uses the output of the upstream API as the input of the downstream API.

7. The method according to claim 1, characterized in that, The rule for setting the dynamic retry count K_max is as follows: when ρ<0.9, K_max=2; when ρ≥0.95, K_max=5, where ρ represents the recent historical call success rate of the API.

8. The method according to claim 1, characterized in that, The rollback strategy is as follows: when the API for obtaining real-time logging-while-drilling data fails, it automatically switches to the backup API for obtaining the most recent valid cached data.

9. A RESTful API intelligent application system based on a large language model, characterized in that, include: The API entity extraction module is configured to perform data source extraction and entity recognition. The dynamic knowledge graph module is configured to perform incremental updates to GraphSAGE. The semantic understanding module is configured to perform vectorization and intent recognition; The API recommendation module is configured to perform multi-dimensional matching and combined recommendations. The fault-tolerant execution module is configured to implement dynamic optimization and rollback mechanisms.

10. A computer-readable storage medium, characterized in that, The device contains a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1-8.

Images