API configuration template and function sample dual library matching extension method

Abstract

The application relates to the technical field of API gateway operation control, in particular to an API configuration template and function sample double-database matching expansion method.The method comprises the following steps: obtaining a configuration request and current configuration information of a target API; determining a basic configuration template from an API configuration template database according to operation environment information and the current configuration information; comparing a target function set with configured functions to determine state change items and configuration gaps; matching function samples or combined function sample chains from a function sample database according to the configuration gaps; inserting executable configuration nodes into function slots and supplementing missing dependent configuration nodes; generating an incremental configuration package after performing conflict detection on the configuration nodes; and verifying the incremental configuration package by using a function verification case in a mirror operation environment, and sending the incremental configuration package to the target API gateway after verification is passed.The application can realize fine-grained, combinable and verifiable API configuration incremental expansion, and guarantees the integrity and operation safety of configuration expansion.

Description

Technical Field

[0001] This application relates to the field of API gateway operation control technology, and in particular to a dual-library matching and extension method for API configuration templates and function samples. Background Technology

[0002] In modern software systems such as microservice architectures, open platforms, and enterprise service buses, Application Programming Interfaces (APIs) serve as the core hub connecting different business modules with external services. The accuracy and flexibility of their configuration directly affect the system's stability and response efficiency. Existing API configuration management typically relies on pre-built fixed configuration templates or standardized configuration files. Operations personnel manually select parameters such as interface protocol type, authentication mechanism, routing rules, rate limiting strategies, and data transformation logic in a predetermined interface or file based on specific business needs. When new business scenarios emerge, if a perfectly matching preset template exists, the system can directly reuse it. However, if only a partial match exists or new functions are involved that are not pre-defined, developer intervention is usually required to modify the underlying configuration code, develop dedicated plugins, or rewrite the adaptation logic to achieve customized functionalities.

[0003] However, in the face of increasingly complex and differentiated API functional requirements, the existing configuration extension methods are difficult to automatically identify and fill configuration gaps while ensuring the stable operation of the original business. They also lack an automatic completion mechanism for implicit dependencies of new functions and comprehensive executability verification before release. As a result, the configuration extension process relies on human experience and is prone to problems such as routing conflicts, version incompatibility or runtime anomalies. Summary of the Invention

[0004] This application provides a dual-library matching extension method for API configuration templates and function samples to solve the above problems. The method includes: S1. Obtain the configuration request and current configuration information of the target API. The configuration request includes the target function set and runtime environment information. S2. Based on the runtime environment information and current configuration information, determine the basic configuration template from the API configuration template library. The basic configuration template includes configured functions and function slots. S3. Compare the target function set with the configured functions to determine the status change items and the configuration gaps not covered by the basic configuration template; S4. Match functional samples from the functional sample library according to the configuration gap, and when a single functional sample cannot cover the configuration gap, combine multiple functional samples with execution dependencies into a functional sample chain. The functional sample includes an executable configuration node, node dependencies, and functional verification test cases. S5. Insert the matched executable configuration node into the corresponding function slot, and supplement the missing dependency configuration nodes in the basic configuration template according to the node dependency relationship. S6. Perform conflict detection on the inserted and supplemented configuration nodes, and generate an incremental configuration package based on the state change items and configuration nodes after the detection is passed; S7. In the image runtime environment built based on the current configuration information, the incremental configuration package is verified using the functional verification test case. When both the newly added function and the original function of the target API are verified to pass, the incremental configuration package is sent to the API gateway corresponding to the target API.

[0005] Optionally, determining the basic configuration template from the API configuration template library includes: Based on the target protocol, deployment environment, and API gateway version in the runtime environment information, the API configuration templates in the API configuration template library are screened for compatibility. The selected API configuration templates are compared with the current configuration information to determine the number of existing configuration nodes that can be reused for each API configuration template. The API configuration template with the most reusable existing configuration nodes is determined as the basic configuration template. When there are multiple corresponding API configuration templates, the API configuration template with the fewest newly added configuration nodes is determined as the basic configuration template.

[0006] Optionally, the determination of status change items and configuration gaps not covered by the basic configuration template includes: Each target function in the target function set is compared with the configured functions in the basic configuration template one by one; When a corresponding configured function exists in the basic configuration template, the difference between the enabled state, disabled state, or function parameter of the target function and the current configuration value is determined as the state change item. When there is no corresponding configured function in the basic configuration template, the configuration gap is generated based on the functional semantics, input and output field constraints and execution stage of the target function.

[0007] Optionally, matching a functional sample from the functional sample library based on the configuration gap includes: Based on the functional semantics of the configuration gap, candidate functional samples corresponding to the functional semantics are selected from the functional sample library; Each candidate function sample is tested to see if its applicable protocol, input / output fields, and applicable function slots match the configuration gap. Candidate function samples that are consistent with the applicable protocol, whose input and output fields can be mapped, and whose applicable function slots correspond to the execution phase of the configuration gap are identified as function samples that match the configuration gap.

[0008] Optionally, combining multiple functional samples with execution dependencies into a functional sample chain includes: If no functional sample that can independently cover the configuration gap is matched, the configuration gap is decomposed into multiple sub-functions with sequential execution relationships; Each sub-function is matched with a corresponding functional sample. Based on the pre-dependencies recorded by each functional sample, a directed connection relationship is established between the functional samples, and the execution order of each functional sample is determined according to the directed connection relationship to obtain the functional sample chain.

[0009] Optionally, inserting the matched executable configuration node into the corresponding function slot includes: Generate field fingerprints based on the field name, data type, hierarchical path, and functional semantics of the configured fields; Based on the field fingerprint, establish a mapping relationship between the input and output fields in the functional sample chain and the configuration fields in the basic configuration template; When data types are inconsistent and type conversion is allowed, add a field type conversion node before or after the corresponding executable configuration node; According to the mapping relationship, the executable configuration node is inserted into the position corresponding to its applicable function slot.

[0010] Optionally, supplementing the missing dependency configuration nodes in the basic configuration template includes: A configuration dependency graph is established using the configuration nodes in the basic configuration template and the inserted executable configuration nodes as graph nodes, and the execution dependencies between each configuration node as directed edges. Starting from the inserted executable configuration node, recursively query the dependency configuration nodes required by the functional sample chain along the direction of the preceding dependencies; Add the dependent configuration nodes that are found in the query and do not exist in the basic configuration template to the set of new configuration nodes, and merge dependent configuration nodes with the same function.

[0011] Optionally, the conflict detection of the inserted and supplemented configuration nodes includes: The system detects whether there are duplicate routing paths, incompatible processing results for the same configuration field, contradictory execution orders of configuration nodes, incompatibility between the function sample version and the API gateway version, or runtime resource requirements exceeding available resources between the inserted and supplemented configuration nodes and the current configuration information. When there is a conflict in the execution order of configuration nodes, the execution order of the corresponding configuration nodes is re-determined according to the configuration dependency graph; In the event of version compatibility conflicts, alternative function samples with the same functional semantics and compatible with the API gateway version are selected from the function sample library.

[0012] Optionally, generating the incremental configuration package and verifying the incremental configuration package includes: Write the status change items, the new configuration nodes to be added, the execution order of configuration nodes and the field mapping relationship into the incremental configuration package, and record the configuration values ​​before and after the change for each configuration change record; The incremental configuration package is loaded into the image runtime environment, and the functional verification test cases and the original functional verification test cases generated based on the current configuration information of the target API are executed respectively. When the execution result of the functional verification test case meets the corresponding expected result, and the execution result of the original functional verification test case is consistent with that before loading the incremental configuration package, the incremental configuration package is determined to have passed verification. The rollback operation corresponding to the incremental configuration package is generated based on the configuration values ​​before the change.

[0013] Optional, also includes: If no corresponding functional sample is found, or if the incremental configuration package fails verification, the corresponding configuration gap, basic configuration template, field mapping relationship and verification result will be sent to the API management console. Receive the manual configuration results returned by the API management console. The manual configuration results include executable configuration nodes, node dependencies, and field mapping relationships used to cover the configuration gaps. After the manual configuration result is verified in the image runtime environment, the manual configuration result and the corresponding functional verification test cases are written into the functional sample library to form a new functional sample.

[0014] Through the above technical solution, this application achieves the following beneficial effects: This application automatically determines reusable basic configuration templates by matching the configuration requests of the target API with configuration templates in the API configuration template library, and identifies status change items in the existing configuration that need to be adjusted. This eliminates the need for manual configuration for each customer requirement, reducing the amount of manual operation and human error in the configuration process.

[0015] This application does not directly determine a matching failure when the configuration template cannot fully cover the target requirements. Instead, it compares the target function with the already configured functions in the basic configuration template and extracts the configuration gaps not covered by the basic configuration template. This allows the complete configuration requirements to be broken down into two parts: changes to existing functions and extensions to missing functions, improving the granularity of configuration requirement identification.

[0016] This application uses configuration gaps as the retrieval criteria for the functional sample library, enabling the functional sample matching process to focus on functions not yet covered by the basic configuration template, avoiding repeated matching and addition of existing configuration functions, thereby improving the efficiency of dual-library matching and the accuracy of configuration results.

[0017] When a single functional sample cannot fully cover the configuration gap, this application combines multiple functional samples into a functional sample chain based on the execution dependencies between functional samples, so that multiple local functional samples can work together to achieve the target function in a determined order, reducing the situation where complex configuration requirements cannot be directly met due to the small granularity of functional samples.

[0018] Based on the node dependency relationships recorded in the functional samples, this application supplements the missing dependency configuration nodes in the basic configuration template, avoiding the omission of pre- or post-node nodes such as identity resolution, field conversion, protocol adaptation, or exception handling while only adding target functional nodes, thereby improving the completeness and executability of the extended API configuration.

[0019] Before generating extended configurations, this application performs conflict detection on the inserted and supplemented configuration nodes. It can identify problems such as duplicate routes, incompatible field processing, contradictory node execution order, version incompatibility, and insufficient runtime resources, preventing conflicting configurations from being directly loaded into the API gateway and improving the stability of API operation.

[0020] This application generates incremental configuration packages based on status change items and newly added configuration nodes. It only processes the configuration content that needs to be added or modified in the target API, without replacing the current configuration of the target API as a whole. It can retain the original configuration structure and running parameters, reducing the risk of configuration overwrite, configuration loss and version confusion.

[0021] This application loads the incremental configuration package in a runtime environment built based on the current configuration information of the target API, and uses functional verification test cases corresponding to the functional samples to verify the newly added functions and the original functions respectively. Only when the newly added functions achieve the expected results and the original functions remain normal, is the incremental configuration package sent to the API gateway, thereby reducing interface anomalies caused by directly deploying unverified configurations.

[0022] Incremental configuration packages can record configuration changes and corresponding rollback operations. When configuration loading fails or runtime anomalies occur after deployment, the configuration state before the change can be restored based on the rollback operation, shortening the recovery time of API configuration anomalies and reducing the continuous impact of configuration extensions on online services.

[0023] When no matching configuration gap exists in the configuration sample library, this application sends the configuration gap and related information to the API management console. After the manual configuration result is verified, it is written into the configuration sample library to form a new configuration sample. This transforms manual processing experience into reusable configuration resources, reducing the duplication of development for the same or similar configuration requirements. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This is a schematic diagram of an application scenario provided in an embodiment of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0027] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article, unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0028] The embodiments of this application will now be described in further detail with reference to the accompanying drawings.

[0029] Example 1 This example uses an order query API deployed in production cluster A to illustrate the complete process of dual-database matching extension. The target API uses the HTTP / 1.1 protocol and REST call method, running on API Gateway version v2.5. The currently active request path is " / api / order / query", the request method is POST, available memory is 512MB, and the maximum allowed concurrent connections is 1000.

[0030] The current configuration of the target API includes, in sequence, a route matching node N01, an OAuth2 token verification node N02, a request log node N03, an IP rate limiting node N04, an upstream service forwarding node N05, a response serialization node N06, and a response return node N07. Specifically, the IP rate limiting node N04 has a 1-second time window and a rate limiting limit of 200 requests; the order data returned by the upstream service is in object format, and the response serialization node N06 converts this object into a JSON response.

[0031] The operations and maintenance personnel submitted a configuration request through the API management console, requesting that the IP rate limiting limit be adjusted from 200 requests per second to 100 requests per second, and that tenant-level rate limiting and response phone number anonymization be added. The requirements for tenant-level rate limiting are: obtain the tenant identifier from the X-Tenant-ID header, and allow a maximum of 60 requests per second for the same tenant; the requirements for response phone number anonymization are: for the 11-digit phone number with the path data.customer.phone in the response data, retain the first three and last four digits, and replace the middle four digits with asterisks.

[0032] Step 1: Obtain the configuration request and current configuration information of the target API.

[0033] The system organizes the above configuration requests into a set of target functions and runtime environment information. The set of target functions includes three items: IP rate limiting parameter adjustment, tenant-level rate limiting, and response mobile number anonymization. The runtime environment information includes HTTP / 1.1 protocol, REST call method, production cluster A, gateway version v2.5, 252MB of remaining available memory, and 400 remaining connections. The system also reads the current configuration version number V18, as well as the node type, execution stage, input / output fields, and current parameters of nodes N01 to N07.

[0034] Step 2: Based on the runtime environment information and current configuration information, determine the basic configuration template from the API configuration template library.

[0035] The API configuration template library contains templates T01, T02, and T03. Template T01 is suitable for HTTP / 1.1 and gateways v2.0 to v2.6, and includes routing, token verification, request logging, IP rate limiting, forwarding, and response return nodes. Template T02 is suitable for HTTP / 1.1 and gateways v2.3 to v2.7, and in addition to T01, it sets up slots for request processing before processing, authentication after verification, upstream forwarding after forwarding, and response serialization before serialization. Template T03 is suitable for the gRPC protocol and does not meet the requirements of the target protocol.

[0036] The system first excludes template T03, then compares T01 and T02 with the currently configured nodes. T01 can directly reuse six nodes: N01, N02, N03, N04, N05, and N07, but requires additional slots before response serialization. T02 can directly reuse seven nodes: N01 to N07, and already includes slots required for tenant rate limiting and data masking nodes. Therefore, the system determines template T02 as the basic configuration template. The basic configuration template is only used to provide standard node topology and functional slots, and does not replace the current configuration of the target API; nodes in the template corresponding to the current configuration are bound to the original node identifier, and template nodes without a corresponding identifier are not directly loaded.

[0037] Step 3: Compare the target feature set with the configured features in the basic configuration template to identify status change items and configuration gaps.

[0038] The system detected that the basic configuration template already has IP rate limiting functionality, but the current limit is 200 requests, while the target limit is 100 requests. Therefore, a status change item C01 is generated, recording the target node as N04, the change type as parameter modification, the original value as 200, and the new value as 100. The basic configuration template lacks tenant-level rate limiting and response phone number anonymization functionality, therefore configuration gaps G01 and G02 are generated.

[0039] The configuration gap G01 record's functional semantics are tenant-level rate limiting. The input field is the request header X-Tenant-ID, the field type is string, the processing stage is after OAuth2 token verification and before upstream forwarding, the time window is 1 second, and the rate limiting limit is 60 times. The configuration gap G02 record's functional semantics are response field masking. The input field path is data.customer.phone, the field type is string, the processing stage is after the upstream service returns and before response serialization, and the processing rule is to retain the first three and last four digits and replace the middle four digits.

[0040] Step 4: Match functional samples from the functional sample library based on the configuration gap, and form a functional sample chain when a single sample cannot cover the configuration gap.

[0041] In the functional sample library, sample F101 is used to parse request headers, supporting HTTP / 1.1 and gateway v2.1 to v2.7; sample F102 is used to obtain the tenant identifier from the parsed request headers; sample F103 is used to normalize the tenant identifier into a rate limiting key; sample F104 is used to perform fixed-time window rate limiting according to the rate limiting key, supporting gateway v2.3 to v2.7; sample F201 is used to perform digit-reserved desensitization on specified string fields in a JSON object, supporting insertion after upstream forwarding and before response serialization. Each sample records the input and output fields, applicable slots, prerequisite dependencies, resource requirements, and at least one set of functional verification test cases.

[0042] For configuration gap G01, there is no single sample in the sample library that can simultaneously complete request header parsing, tenant identifier retrieval, rate limiting key generation, and rate limiting execution. The system decomposes G01 into four sub-functions: request header parsing, tenant identifier extraction, rate limiting key normalization, and rate limiting execution, matching F101, F102, F103, and F104 respectively, and forming directed connections from F101 to F102, F102 to F103, and F103 to F104 based on prerequisite dependencies. For configuration gap G02, sample F201 can independently cover the required functions, and the protocol, field type, and slot all match; therefore, it is directly determined as the matching sample.

[0043] Step 5: Insert the matched executable configuration node into the corresponding function slot and supplement any missing dependency configuration nodes.

[0044] The system establishes field mappings after standardizing field names, data types, hierarchical paths, and functional semantics. The input of F101 is mapped to the request header set; the target field of F102 is mapped to X-Tenant-ID; the output of F103 is mapped to the tenant_key (the rate limiting key); and F104 uses tenant_key as the counting key. The input field of F201 is mapped to data.customer.phone in the upstream response object. Rate limiting samples record time windows in milliseconds, while configuration requests record time windows in seconds. The system adds a time window conversion node before F104 to convert 1 second to 1000 milliseconds.

[0045] The system establishes a configuration dependency graph based on the current node and the node to be inserted. Recursive queries reveal that F102 depends on F101. Since the current configuration lacks a request header structure parsing node, the node N08 corresponding to F101 is added to the set to be added. F102 and F103 form the tenant identifier extraction node N09 and the rate limiting key normalization node N10, respectively. The time window conversion node forms N11. F104 forms the tenant rate limiting node N12. The response desensitization node forms N13. The node chain from F101 to F104 is inserted after N02 and before N05, and N13 is inserted after N05 and before N06.

[0046] Step 6: Perform conflict detection on the inserted and supplemented configuration nodes and generate an incremental configuration package.

[0047] The routing test results show that the new node does not add a new request path, and there is no duplicate route; the field read / write test results show that N13 only modifies data.customer.phone, and the original configuration node did not encrypt, delete, or convert the format of this field, so there is no conflict in the processing results; the dependency graph does not have a hard dependency cycle, and the execution order can be determined as N01, N02, N08, N09, N10, N11, N12, N03, N04, N05, N13, N06, and N07; all samples support gateway v2.5.

[0048] The current continuous memory usage is 260MB, the total continuous memory requirement for new nodes is 38MB, the peak temporary memory requirement during the verification period is 24MB, and the expected peak is 322MB, which is less than 80% of the 512MB resource limit, i.e., 409.6MB; the new connection requirement is 40, which does not exceed the remaining connection limit of 400. Therefore, the conflict detection passed.

[0049] The system generates an incremental configuration package P20260702-01. This configuration package is loaded based on the current configuration version V18. It includes operations to change the rate limit of N04 from 200 to 100, operations to add N08 to N13, records the execution order of each node, field mapping, time window conversion relationship, and the values ​​before and after the change of each operation, and generates the corresponding reverse rollback operation.

[0050] Step 7: Verify the incremental configuration package in the image runtime environment.

[0051] The system selects the same gateway v2.5 runtime image as the production environment, loads the current configuration V18 and the same version of authentication, rate limiting, and logging plugins, sets up 512MB of memory and a maximum of 1000 connections as in the production environment, and replaces the real upstream address with a simulated service that returns fixed order test data. Before loading the incremental configuration package, the system first executes the original functional baseline test cases and saves the status codes, response structures, and performance baselines.

[0052] After loading the incremental configuration package, the system performs the following verifications: 101 valid requests are sent consecutively within 1 second from the same IP address; the first 100 requests pass, and the 101st request returns a 429 error. 61 requests are sent consecutively within 1 second using three different IP addresses but with the same tenant identifier; the first 60 requests pass, and the 61st request returns a 429 error. A simulated upstream return of a mobile phone number is executed, with the final response being 138****5678. Accessing the order query interface with a valid token returns a 200 error, while accessing it with an invalid token still returns a 401 error. When the phone field is not present in the response, the de-identified node maintains the original response structure and does not generate an empty field.

[0053] In the regression testing of the original functionality, the order number, order status, and amount fields remained consistent with those before loading. Dynamic timestamps and request serial numbers were not compared value-by-value according to preset rules. The 95th percentile response time before loading was 42 milliseconds, and after loading it was 45 milliseconds, an increase of less than 10%. No gateway anomalies or configuration node errors occurred during the test. Therefore, it was determined that both the new and original functions passed verification, and the system sent the incremental configuration package P20260702-01 to the API gateway corresponding to the target API.

[0054] This embodiment illustrates the input-output relationship between configuration requests, template selection, gap generation, sample matching, node insertion, dependency completion, conflict detection, incremental packaging, and image verification using a set of continuous data, enabling each step to be executed based on clear data and rules.

[0055] Example 2 This embodiment, based on embodiment 1, further explains the process of determining the API configuration template library, the function sample library, and the basic configuration template.

[0056] Each template record in the API configuration template library includes at least the template identifier, applicable protocol, deployment environment, gateway version range, template node set, configured function set, function slot set, basic resource usage, and template version. Each template node record includes the node identifier, node type, execution stage, input fields, output fields, and default parameters. Each function slot record includes the slot identifier, execution stage, allowed node types, adjacent upstream nodes, adjacent downstream nodes, and whether multiple consecutive nodes are allowed.

[0057] Each sample record in the functional sample library includes at least a sample identifier, standard functional semantics, applicable protocols, applicable gateway version range, input field set, output field set, applicable slot, executable configuration node, pre-dependencies, post-dependencies, resource requirements, functional verification test cases, historical verification count, and credibility. Functional verification test cases record test request conditions, expected status codes, expected field changes, and allowed performance fluctuation range.

[0058] Step 1: Perform compatibility screening of the template based on the target protocol, deployment environment, and API gateway version.

[0059] For the target API in Example 1, the system reads the protocol as HTTP / 1.1, the deployment environment as production cluster A, and the gateway version as v2.5. Templates T01 and T02 both use HTTP / 1.1, and their deployment environment tags both allow production clusters, with version ranges of v2.0 to v2.6 and v2.3 to v2.7 respectively, and are therefore retained. Template T03 uses gRPC as its protocol and is directly excluded. The version range is determined using a boundary-inclusive approach; that is, version compatibility is determined when the target gateway version is not lower than the lowest version of the template and not higher than the highest version of the template.

[0060] Step 2: Compare the filtered template nodes with the currently configured nodes.

[0061] Whether a node can be directly reused is determined based on at least the node type, standard functional semantics, required input fields, output fields, execution stage, and version requirements. If the above conditions are met and the node parameters do not need modification, it is considered a directly reusable node. If the node type and functional semantics are the same but the parameters are different, and the parameters can be modified independently, it is considered a reusable node that requires modification. Nodes with missing required fields, different execution stages, or version incompatibility are not considered reusable nodes.

[0062] After comparison, template T01 can directly reuse 5 nodes: N01, N02, N03, N05, and N07. N04 is a reusable node that needs to be modified. N06 does not explicitly respond to the slot before serialization in the template, and it is expected that one new slot-associated node will be needed. Template T02 can directly reuse 6 nodes: N01, N02, N03, N05, N06, and N07. N04 is a reusable node that needs to be modified, and no new slot-associated node is needed. Therefore, based on the sum of directly reused nodes and reusable nodes that need to be modified, both T01 and T02 can reuse 6 nodes, but T02 is expected to add fewer nodes.

[0063] Step 3: Determine the basic configuration template.

[0064] The system first selects the template with the most reusable nodes. If templates with the same number of nodes exist, it then selects the template that provides the required slots for the target function and has the fewest expected new nodes. If the above conditions are still the same, it prioritizes the template with a newer version and a higher number of historical successful verifications. In this embodiment, the expected number of new nodes for T02 is less than that for T01, therefore T02 is determined to be the basic configuration template. After determination, the system establishes a correspondence between the standard topology of T02 and the current configuration, and the nodes in the current configuration are still used as the basis for the final incremental calculation.

[0065] Example 3 This embodiment, based on embodiment 1, further explains the generation process of state change items and configuration gaps.

[0066] Step 1: Compare each target function in the target function set with the configured functions in the basic configuration template one by one.

[0067] The system pre-configures a standard functional semantic dictionary, categorizing expressions such as "tenant rate limiting," "merchant-level rate limiting," and "caller quota control" under tenant-level rate limiting semantics, and expressions such as "phone number hiding" and "phone number field masking" under response field desensitization semantics. When a configuration request enters the system, it first obtains the standard functional semantics based on the function name, function description, and target field, and then compares it with the configured functions in the basic configuration template, taking into account the protocol type and execution stage.

[0068] For IP rate limiting, the target function corresponds to N04 in the basic template in terms of functional semantics, protocol, and execution phase; therefore, the status and parameters are further compared. For tenant-level rate limiting and response mobile number anonymization, there are no functions in the basic template that correspond to both functional semantics and execution phase; therefore, they are respectively entered into the configuration gap generation process.

[0069] Step 2: Generate status change items.

[0070] The system reads N04's current status as "Enabled," with a 1-second time window and a rate limiting limit of 200 cycles. The target function requires the status to remain "Enabled," with the time window still at 1 second and a rate limiting limit of 100 cycles. The system only writes the changed rate limiting limit to the status change item C01, while also recording node N04, the current configuration version V18, the previous value of 200, and the new value of 100. Since the enabled status and time window remain unchanged, they are not repeatedly written to the incremental configuration package.

[0071] Step 3: Generate configuration gaps.

[0072] The configuration gap G01 consists of standard functional semantics, input / output constraints, execution phase, and functional parameters. Its standard functional semantics is tenant-level rate limiting; the input constraint is that the request header must contain a string field that can be mapped to the tenant identifier; the output is whether the request is allowed to continue execution and the remaining quota; the execution phase is after token verification and before upstream forwarding; the parameter is a maximum of 60 requests per second.

[0073] The standard functional semantics of the configuration gap G02 are response field desensitization; the input constraint is that the upstream response object contains a string field with the path data.customer.phone; the output constraint is that the field length and field type remain unchanged; the execution phase is after upstream forwarding and before response serialization; the processing rule is to retain the first three and last four digits. The system confirms from the response structure definition of the target API that this field is not a required field, therefore it also records that when the field is missing, it skips processing and does not generate an empty field.

[0074] When the basic template only covers a part of the target function, the system does not treat the entire target function as a gap again. For example, if the template already has a general fixed window rate limiting node, but the tenant identifier cannot be obtained from the request header, the system will deduct the existing fixed window counting capability from the target atomic function set, and only include the request header parsing, tenant identifier extraction, and adaptation capability using the tenant identifier as the counting key in the configuration gap, thereby avoiding the duplication of adding existing nodes.

[0075] Example 4 This embodiment further explains the functional sample matching process based on Embodiment 1.

[0076] Step 1: Filter candidate function samples based on the functional semantics of the configuration gap.

[0077] The system merges the standard functional semantics, input field semantics, output results, and execution stage of the configuration gap to form a description to be matched, and converts this description and the corresponding description of the functional sample into normalized semantic features of the same dimension. The system calculates the semantic similarity between the two and selects samples with a semantic similarity of not less than 0.75 as candidate samples. This threshold is set based on historically confirmed matching results and can also be adjusted without changing the matching logic.

[0078] Taking the configuration gap G02 as an example, the function of sample F201 is to de-identify the mobile phone number in the response, with a semantic similarity of 0.94; the function of sample F202 is to de-identify the mobile phone number in the request message, with a semantic similarity of 0.89; the function of sample F203 is to encrypt the response field, with a semantic similarity of 0.78. All three are included in the candidate set.

[0079] Step 2: Detect the protocol, fields, and slots of the candidate samples.

[0080] Sample F201 supports HTTP / 1.1, requires string fields from the response object as input, and is applicable to the slot after upstream forwarding and before response serialization, consistent with G02. Sample F202, while having similar field processing, is applicable to the request initiation phase, inconsistent with G02. Sample F203 has a suitable slot, but its output field status is encrypted, failing to meet the constraint of maintaining the original length and replacing intermediate characters with asterisks. Therefore, F202 and F203 are excluded.

[0081] Step 3: Determine the matching results among multiple compatible samples.

[0082] When multiple samples are compatible across protocols, fields, and slots, the system calculates the overall matching score based on a weighted average of 55% semantic similarity, 30% completeness of required field mapping, and 15% version and slot compatibility. If all required fields can be mapped, the field mapping completeness is 1; if any protocol or slot is incompatible, the sample is not included in the overall ranking.

[0083] For the rate limiting execution sub-function in configuration gap G01, samples F104 and F105 both passed the compatibility test. F104 had a semantic similarity of 0.92, all required fields were mappable, and it supported gateways v2.3 to v2.7, with a comprehensive score of 0.96. F105 had a semantic similarity of 0.90, all required fields were mappable, but it supported gateways v2.6 and above, not the current v2.5, and was therefore excluded. The system ultimately selected F104.

[0084] If two samples have the same overall matching score, the system compares the number of successful historical verifications, average resource consumption, and the time of the most recent verification in sequence, prioritizing samples with more successful verifications, lower resource consumption, and recent successful verifications. This makes the sample selection criteria clear, rather than relying solely on sample names or human experience.

[0085] Example 5 This embodiment, based on embodiment 1, further explains the decomposition of complex configuration gaps and the process of combining functional sample chains.

[0086] Step 1: Determine whether a single functional sample can independently cover the configuration gap.

[0087] The system breaks down the configuration gap G01 into its set of essential atomic capabilities, including reading the request header, obtaining the tenant identifier, normalizing the tenant identifier, generating the rate limiting key, and executing fixed-time-window rate limiting. A candidate sample is considered capable of independently covering the configuration gap only if it simultaneously covers all the necessary atomic capabilities and its inputs and outputs are interconnected. If no single sample in the sample library meets these conditions, gap decomposition is triggered.

[0088] The system decomposes G01 into four sequential sub-functions according to functional decomposition rules: Sub-function A1 is request header parsing, outputting a structured request header set; Sub-function A2 is tenant identifier extraction, obtaining the original tenant identifier from X-Tenant-ID; Sub-function A3 is tenant identifier normalization and generating rate limiting keys; Sub-function A4 is rate limiting executed according to the rate limiting key and time window. A1 must precede A2, A2 must precede A3, and A3 must precede A4.

[0089] Step 2: Match functional samples to each sub-function.

[0090] The system matches sample F101 for A1, sample F102 for A2, sample F103 for A3, and sample F104 for A4. The request header set output by F101 contains the fields required by F102; F102 outputs the tenant identifier as a string; F103 unifies leading and trailing spaces and capitalization, and outputs `tenant_key`; F104 receives `tenant_key`, a 1000-millisecond time window, and a 60-time limit, and outputs a pass or reject result.

[0091] Step 3: Establish directed connections based on dependencies and determine the execution order.

[0092] The prerequisites for each functional sample are recorded as follows: F101 has no prerequisite sample; F102 depends on the request header being parsed; F103 depends on the tenant identifier being obtained; and F104 depends on the rate limiting key being generated. Based on this, the system establishes directed edges from F101 to F102, F102 to F103, and F103 to F104, and obtains a unique execution order according to the directed relationships.

[0093] Dependencies are categorized into hard dependencies and soft order constraints. Hard dependencies include conditions such as input fields not yet generated by predecessor nodes or nodes requiring identity verification before execution. Soft order constraints are those used solely to reduce redundant parsing or optimize performance. If only soft order constraints form a loop during topology sorting, the system deletes the lowest-priority soft constraint and reorders. If hard dependencies form a loop, or if any required sub-function lacks a matching sample, the system stops automatic combination and transfers the corresponding configuration gap to the manual configuration process.

[0094] Through the above processing, each node in the functional sample chain has clear inputs, outputs, and preconditions, avoiding the problem of data transmission failure or incorrect execution order caused by simply chaining multiple samples together based on function names.

[0095] Example 6 This embodiment, based on embodiment 1, further explains the field fingerprinting, field mapping, type conversion, and node insertion process.

[0096] Step 1: Standardize the configuration fields and generate field fingerprints.

[0097] The system first standardizes field names to lowercase, splits camelCase and underscores, and removes connectors that do not affect meaning; it converts data types such as integers, long integers, strings, objects, and arrays into a unified type identifier; it standardizes hierarchical paths to a standardized path starting from the message root node; and then determines the field semantics based on a standard functional semantic dictionary.

[0098] The system combines standard field names, standard data types, normalized hierarchical paths, and functional semantic encodings into precise field fingerprints. Precise field fingerprints are used to determine if fields are completely identical, not for directly comparing semantic similarity. For cases where field names differ but may have the same meaning, the system separately compares field name semantics, functional semantics, hierarchical paths, data types, and data flow.

[0099] Step 2: Establish mapping relationships based on field characteristics.

[0100] In the overall score of approximate field mapping, field name semantics accounts for 35%, functional semantics for 25%, hierarchical path for 20%, data type for 15%, and input / output direction for 5%. Mapping is automatically established when the overall score is not lower than 0.85; when the score is between 0.70 and 0.85, it is retained as a candidate mapping and further judged in combination with the relationship of required fields; when the score is lower than 0.70, no mapping is established.

[0101] In Example 1, sample F102 uses the field name `client_id` to represent the caller's tenant identifier, while the target API uses the request header `X-Tenant-ID`. Both are string data types, functionally represent tenant identity, and are both input requests, with paths `requestheader.client_id` and `requestheader.X-Tenant-ID` respectively. After standardization and alias dictionary correction, the overall score is 0.91, therefore a mapping from `X-Tenant-ID` to `client_id` is established.

[0102] Sample F201 uses the field name "mobile_number," and the target API uses the path "data.customer.phone." Both names semantically refer to a mobile phone number, both are of string data type, and both are output responses. The overall score is 0.93, therefore a field mapping is established. The system also records that this field is not mandatory; if the field does not exist, the field writing operation in the de-identified node is skipped.

[0103] Step 3: Add a type conversion node when data types are inconsistent and conversion is allowed.

[0104] The type conversion rule base records the source type, target type, allowed conditions, and failure handling methods. For example, seconds can be converted to milliseconds, integers can be converted to strings without losing value, and date strings are only allowed to be converted to timestamps if they conform to a specified format. Conversions that cannot guarantee the data meaning remains unchanged will not be executed automatically.

[0105] In Example 1, the configuration request uses a 1-second time window, while sample F104 requires a millisecond integer time window. The system adds a time window conversion node N11, multiplies 1 by 1000 to get 1000 milliseconds, and terminates configuration loading if the conversion fails. If the source field is unparseable text, no conversion node is generated, and the field mapping is determined to be incompatible.

[0106] Step 4: Insert the configuration node into the function slot.

[0107] The system reads the applicable slots for nodes and the conditions of adjacent nodes. F101 to F104 require execution after identity verification and before upstream forwarding, so they are inserted into the slots after identity verification in the basic template. The node inputs the authenticated request for connection N02, and the node outputs N05 after connection N03 and N04. F201 requires execution after obtaining the upstream response object and before response serialization, so it is inserted between N05 and N06.

[0108] After insertion, the system checks again whether all required inputs for each new node were generated by the preceding node and whether each output can be received by the following node. Only when both the data connection and execution phases meet the requirements is the node added to the set of nodes to be added for configuration.

[0109] Example 7 This embodiment, based on embodiment 1, further explains the recursive query and merging process of dependent configuration nodes.

[0110] Step 1: Establish a configuration dependency graph.

[0111] The system uses the currently configured nodes N01 to N07, the sample nodes to be inserted, and the type conversion nodes as graph nodes, and the data transfer relationships, execution order relationships, and functional preconditions as directed edges. Each dependency edge records the type of the preceding node, the type of the succeeding node, the required fields, the version range, and the dependency type. Dependency types include hard dependencies that cannot be deleted and soft order constraints that can be adjusted.

[0112] Step 2: Recursively query along the preceding dependencies from the node to be inserted.

[0113] The system starts querying the rate-limiting node corresponding to F104 and finds that its prerequisite dependency is the tenant rate-limiting key; continuing to query F103, it finds that its prerequisite dependency is the original tenant identifier; continuing to query F102, it finds that its prerequisite dependency is the parsed request header; there is no request header structure parsing node in the current configuration, so the node N08 corresponding to F101 is marked as a missing dependency node. F101 only depends on the original request formed after route matching, and N01 can provide this input, so the recursion stops at N01.

[0114] During the recursive process, the system maintains the set of visited nodes and the current query path. When a node reappears in the current query path, a circular dependency is determined; if the cycle contains a hard dependency, autocomplete stops; if the duplicate node is only visited again in a different branch, the node is not created again, and the recorded query results are reused.

[0115] Step 3: Add the missing dependency nodes to the set to be added and merge them.

[0116] Two dependent nodes are only directly merged into the same node instance if they are identical in node type, supported version, normalization parameters, execution phase, and input / output mode. For example, if both tenant rate limiting and auditing functions need to parse request headers during the request entry phase and use the same parsing parameters, they can share a single request header parsing node. However, if one node requires preserving the original case while the other requires converting all field names to lowercase, their parameters differ, and they are not directly merged.

[0117] In this embodiment, N08 only needs to be added once, and F102 and other nodes that may use the request header can connect to the output of N08. N09, N10, N11, N12, and N13 have different functions, parameters, or execution stages, and are not merged. The final set to be added includes N08 to N13, and each node has a unique upstream connection and a clear downstream usage relationship.

[0118] Example 8 This embodiment further explains the determination and handling process of configuration conflicts based on embodiment 1.

[0119] Step 1: Detect route, field, order, version, and resource conflicts.

[0120] Routing conflicts are determined based on the request method, host range, path matching range, and request headers or query conditions. Two routes are considered to have overlapping ranges only if their request methods, host ranges, and path rules match the same request, and other conditions cannot distinguish between the requests. If overlapping routes have clear and distinct priorities and can uniquely determine the route to execute, they are recorded as a valid inclusion relationship and not considered a conflict. In Example 1, the newly added node did not add routing rules, therefore the route detection passed.

[0121] Field processing conflicts are determined by the nodes' read field set, write field set, delete field set, required input state, and output state. A conflict occurs when two nodes write to the same field, and the processing order cannot be interchanged, or when the output state of the preceding node does not satisfy the input state of the following node. For example, if an encryption node converts the "phone" field to ciphertext, while a de-identification node requires plaintext input, the encryption node cannot precede the de-identification node. In Example 1, only N13 writes to the "phone" field, so there is no mutual exclusion operation.

[0122] Execution order conflicts are determined by configuring the dependency graph. The system first performs topological sorting according to hard dependencies, and then adds soft order constraints. If a soft constraint causes a loop, the soft constraint with the lowest priority is deleted and the order is reordered; if a hard dependency itself forms a loop, the dependency edges are not automatically cut off, but the automatic configuration is deemed a failure and manual processing is initiated. The execution order obtained in this embodiment does not contain loops.

[0123] Version compatibility is determined by comparing the lowest and highest versions supported by the samples. Candidate sample F105 only supports gateway v2.6 and above, and is incompatible with the current v2.5; the system re-searches with the same functional semantics and selects F104, which supports v2.3 to v2.7. In addition to version compatibility, alternative samples must also meet the requirements of the same required fields, the same slots, and the same functional output.

[0124] Resource conflicts are assessed by considering both persistent memory usage and potential concurrent peak usage. The system adds up the currently configured persistent memory, the persistent memory of all newly added nodes, and the maximum temporary memory that may occur simultaneously on the same execution path, and compares this sum with 80% of the resource limit. In Example 1, the expected peak memory is 322MB, which is lower than 409.6MB; the expected maximum number of connections is 640, which is lower than 1000, therefore the resource detection passes.

[0125] Step 2: Re-determine the execution order if there are correctable conflicts.

[0126] For example, if the response desensitization sample is initially placed after the response serialization node N06, and this sample requires the input to be a response object and does not accept already serialized strings, then the system adjusts N13 to between N05 and N06 based on the input-output dependencies. After adjustment, the field types and subsequent node inputs are rechecked, and the adjustment result is retained if all conditions are met.

[0127] Step 3: Select an alternative sample when there is a version conflict.

[0128] The system uses the standard functional semantics and required inputs and outputs of the original sample as search criteria, excludes samples that do not support the current gateway version, and re-performs field and slot matching on the remaining samples. Only after a replacement sample passes all conflict detections will the original sample be replaced; if no replacement sample is found, an incomplete incremental configuration package is not generated, but the cause of the conflict and the original configuration gaps are sent to the API management console.

[0129] After all five types of tests pass, the system will write the conflict detection results and node sorting results into the incremental configuration package to generate a record, so that the corresponding node and judgment basis can be located when subsequent verification fails.

[0130] Example 9 This embodiment, based on embodiment 1, further explains the incremental configuration package, image verification, and rollback operation.

[0131] Step 1: Generate an incremental configuration package.

[0132] The incremental configuration package P20260702-01 records the target API identifier, configuration package identifier, pre-load configuration version V18, target configuration version V19, configuration operation set, node execution order, field mapping set, loading preconditions, rollback operation set, and integrity verification value. During loading, the gateway's current configuration version must still be V18; if it has been updated by other configuration changes, loading will stop and the incremental configuration package will be regenerated.

[0133] The configuration operation set includes: changing the rate limit cap of N04 from 200 to 100; adding request header parsing node N08, tenant identifier extraction node N09, rate limit key normalization node N10, time window conversion node N11, tenant rate limit node N12, and response masking node N13; updating the node execution order; adding a mapping from X-Tenant-ID to tenant identifier input and a mapping from data.customer.phone to masked fields. Each operation records the operation type, target node, preceding operations, and the content before and after the change.

[0134] Step 2: Build the image runtime environment and load the incremental configuration package.

[0135] The system selects the gateway v2.5 image based on the current configuration snapshot, loads the same version of OAuth2 authentication, logging, and rate limiting plugins as the production environment, configures the routing topology and resource limits according to the production environment, and replaces the real upstream service address with a simulated order service. The simulated service can return fixed order information, order information lacking a phone number, and abnormal status information according to test requests, thereby preventing test access to real production data.

[0136] Before loading the incremental configuration package, the system first executes a baseline test case, recording the 200 response for a valid token request, the 401 response for an invalid token request, the original IP rate limiting rules, the response field structure, and the 95th percentile response time. Then, it verifies the configuration package syntax, dependencies, the version before loading, and the integrity check value. If all verifications pass, the configuration is loaded all at once; if any operation fails, the configuration version is not updated.

[0137] Step 3: Perform verification of the new features and regression verification of the existing features.

[0138] The new feature use cases include: sending 101 requests from the same IP address within 1 second, expecting a 429 response on the 101st request; sending 61 requests from the same tenant identifier via different IP addresses within 1 second, expecting a 429 response on the 61st request; receiving a phone number from the upstream, expecting the output to be 138****5678; when the upstream does not receive a phone number, expecting no new "phone" field in the response; and when the tenant identifier is empty, returning a 400 response according to the sample's preset rules and recording the missing field.

[0139] The existing functional regression test cases include: a valid token returning a 200 error and an invalid token returning a 401 error; existing log nodes being able to generate request records; and the order number, status, and amount fields being consistent with the baseline results. For dynamic fields such as request serial number and timestamp, only the field type and format are compared, not the specific numerical values. In terms of performance, the 95th percentile response time increase should not exceed 10%, and the error rate should not be higher than the baseline value before loading.

[0140] The actual verification results are as follows: all the newly added feature test cases meet expectations; the original feature status codes and business fields all meet the baseline; the 95th percentile response time increased from 42 milliseconds to 45 milliseconds, an increase of approximately 7.1%; and no configuration node anomalies were observed during the test. Therefore, the incremental configuration package verification is successful.

[0141] Step 4: Generate and execute the rollback operation.

[0142] Rollback operations for parameter modification restore the parameters to their original state. Rollback operations for newly added nodes delete the corresponding node and its connections. Rollback operations for disabled nodes restore the enabled state. Rollback operations for deleted nodes recreate the node based on the snapshot before the change. When node order and field mappings change, the original order and mappings are restored respectively. Rollback operations are executed in the reverse order of forward operations.

[0143] The main rollback sequence generated by the system for P20260702-01 is as follows: restore the original field mapping and node order, delete N13, N12, N11, N10, N09, and N08, restore the rate limit cap of N04 from 100 to 200, and restore the configuration version to the version corresponding to the rollback result. After the rollback, the original functional verification test cases are executed again; the rollback is only confirmed to be complete after the verification passes.

[0144] To prevent duplicate loading, the gateway records the identifiers of configuration packages that have already been successfully processed. When the same configuration package is submitted again, only the original processing result is returned, and the add or modify operation is not repeated. This avoids the creation of duplicate nodes due to network retries.

[0145] Example 10 This embodiment further explains the manual configuration and function sample entry process when automatic matching or verification fails.

[0146] Suppose the operations and maintenance personnel request that the `bank_account` field in the response be encrypted using the national standard SM4 encryption, and require the key to be obtained from the existing key service using the key alias `order-key`. Since the functional sample library does not contain a sample that simultaneously meets the requirements of SM4 encryption, key service invocation, and pre-serialization insertion of the response, the system triggers a manual configuration process.

[0147] Step 1: Send the configuration gap and related information to the API management console.

[0148] The system sends the following information: standard functional semantics: response field is SM4 encrypted; input field path is data.bank_account, type is string; output field type is also string; execution stage is after upstream forwarding and before response serialization; basic configuration template T02; confirmed field mappings; gateway version v2.5; currently available resources; reasons for non-matches and reasons for protocol, version, or field incompatibility of excluded candidate samples. If triggered by verification failure, the system also sends the failure test case, actual results, and involved nodes.

[0149] Step 2: Receive the manual configuration results.

[0150] In the management console, operations and maintenance personnel configure controlled node types, including field selection nodes, key alias reading nodes, SM4 encryption nodes, and encoding nodes. The execution order is set to field selection, key retrieval, encryption, and encoding. An input mapping is established from `data.bank_account` to the field selection node. Manual configuration results are only allowed to use node types and parameter items already registered with the gateway; unverified arbitrary program code is not directly accepted.

[0151] The manual configuration results also record prerequisites: the key alias reading node depends on the availability of the gateway key service connection; the SM4 encryption node depends on the obtained key and original fields; and the encoding node depends on the encryption result. The operations and maintenance personnel supplement the functional verification test cases, with the test input being a fixed account string and the expected output being a decryptable ciphertext string. After decryption using the same test key, the original input should be restored; if a field is missing, encryption should be skipped without creating an empty field.

[0152] Step 3: Verify the manual configuration results in the mirror runtime environment and generate new samples.

[0153] The system loads the manually configured results in a mirror environment with the same version as the target gateway, and executes normal encryption, missing field, unavailable key, and original interface regression test cases using the isolated test key. If the normal encryption and decryption results are consistent, the response structure remains unchanged when fields are missing, a preset error is returned when the key is unavailable and unencrypted sensitive fields are not output, and the original order query function is unaffected, then the manual configuration result is considered verified.

[0154] Before being added to the database, the system generates sample comparison identifiers based on standard functional semantics, node types, normalized parameters, execution stages, and input / output modes, and performs duplicate checks against existing samples. If identical samples exist, only the version applicable scope or verification record is added, without re-creating them; if identical samples do not exist, manually configured nodes, dependencies, field mappings, resource requirements, and verification test cases are written into the functional sample database to form a new sample F301.

[0155] The confidence level is set to 0.6 when a new sample is created, and adjusted to 0.8 after the current image verification is completed. For each subsequent successful use with a target API and passing verification, the confidence level increases by 0.02, up to a maximum of 1. If verification fails, the confidence level decreases by 0.1, and the reason for the failure is recorded. The sample's historical verification count, most recent verification time, and applicable gateway version are updated based on usage results for ranking and selection among multiple candidate samples.

[0156] Through the above human-machine collaboration process, the results of manual processing are transformed into reusable functional samples with complete fields, clear dependencies, and accompanying verification test cases, instead of simply saving a piece of operation instructions that cannot be directly reused.

[0157] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for expanding API configuration templates and functional samples through dual-library matching, characterized in that, include: S1. Obtain the configuration request and current configuration information of the target API. The configuration request includes the target function set and runtime environment information. S2. Based on the runtime environment information and current configuration information, determine the basic configuration template from the API configuration template library. The basic configuration template includes configured functions and function slots. S3. Compare the target function set with the configured functions to determine the status change items and the configuration gaps not covered by the basic configuration template; S4. Match functional samples from the functional sample library according to the configuration gap, and when a single functional sample cannot cover the configuration gap, combine multiple functional samples with execution dependencies into a functional sample chain. The functional sample includes an executable configuration node, node dependencies, and functional verification test cases. S5. Insert the matched executable configuration node into the corresponding function slot, and supplement the missing dependency configuration nodes in the basic configuration template according to the node dependency relationship. S6. Perform conflict detection on the inserted and supplemented configuration nodes, and generate an incremental configuration package based on the state change items and configuration nodes after the detection is passed; S7. In the image runtime environment built based on the current configuration information, the incremental configuration package is verified using the functional verification test case. When both the newly added function and the original function of the target API are verified to pass, the incremental configuration package is sent to the API gateway corresponding to the target API.

2. The method according to claim 1, characterized in that, The step of determining the basic configuration template from the API configuration template library includes: Based on the target protocol, deployment environment, and API gateway version in the runtime environment information, the API configuration templates in the API configuration template library are screened for compatibility. The selected API configuration templates are compared with the current configuration information to determine the number of existing configuration nodes that can be reused for each API configuration template. The API configuration template with the most reusable existing configuration nodes is determined as the basic configuration template. When there are multiple corresponding API configuration templates, the API configuration template with the fewest newly added configuration nodes is determined as the basic configuration template.

3. The method according to claim 2, characterized in that, The identified status change items and configuration gaps not covered by the basic configuration template include: Each target function in the target function set is compared with the configured functions in the basic configuration template one by one; When a corresponding configured function exists in the basic configuration template, the difference between the enabled state, disabled state, or function parameter of the target function and the current configuration value is determined as the state change item. When there is no corresponding configured function in the basic configuration template, the configuration gap is generated based on the functional semantics, input and output field constraints and execution stage of the target function.

4. The method according to claim 1, characterized in that, Matching functional samples from the functional sample library based on the configuration gaps includes: Based on the functional semantics of the configuration gap, candidate functional samples corresponding to the functional semantics are selected from the functional sample library; Each candidate function sample is tested to see if its applicable protocol, input / output fields, and applicable function slots match the configuration gap. Candidate function samples that are consistent with the applicable protocol, whose input and output fields can be mapped, and whose applicable function slots correspond to the execution phase of the configuration gap are identified as function samples that match the configuration gap.

5. The method according to claim 4, characterized in that, The step of combining multiple functional samples with execution dependencies into a functional sample chain includes: If no functional sample that can independently cover the configuration gap is matched, the configuration gap is decomposed into multiple sub-functions with sequential execution relationships; Each sub-function is matched with a corresponding functional sample. Based on the pre-dependencies recorded by each functional sample, a directed connection relationship is established between the functional samples, and the execution order of each functional sample is determined according to the directed connection relationship to obtain the functional sample chain.

6. The method according to claim 5, characterized in that, The step of inserting the matched executable configuration node into the corresponding function slot includes: Generate field fingerprints based on the field name, data type, hierarchical path, and functional semantics of the configured fields; Based on the field fingerprint, establish a mapping relationship between the input and output fields in the functional sample chain and the configuration fields in the basic configuration template; When data types are inconsistent and type conversion is allowed, add a field type conversion node before or after the corresponding executable configuration node; According to the mapping relationship, the executable configuration node is inserted into the position corresponding to its applicable function slot.

7. The method according to claim 6, characterized in that, The missing dependency configuration nodes in the basic configuration template include: A configuration dependency graph is established using the configuration nodes in the basic configuration template and the inserted executable configuration nodes as graph nodes, and the execution dependencies between each configuration node as directed edges. Starting from the inserted executable configuration node, recursively query the dependency configuration nodes required by the functional sample chain along the direction of the preceding dependencies; Add the dependent configuration nodes that are found in the query and do not exist in the basic configuration template to the set of new configuration nodes, and merge dependent configuration nodes with the same function.

8. The method according to claim 7, characterized in that, The conflict detection for the inserted and supplemented configuration nodes includes: The system detects whether there are duplicate routing paths, incompatible processing results for the same configuration field, contradictory execution orders of configuration nodes, incompatibility between the function sample version and the API gateway version, or runtime resource requirements exceeding available resources between the inserted and supplemented configuration nodes and the current configuration information. When there is a conflict in the execution order of configuration nodes, the execution order of the corresponding configuration nodes is re-determined according to the configuration dependency graph; In the event of version compatibility conflicts, alternative function samples with the same functional semantics and compatible with the API gateway version are selected from the function sample library.

9. The method according to claim 8, characterized in that, The process of generating and validating the incremental configuration package includes: Write the status change items, the new configuration nodes to be added, the execution order of configuration nodes and the field mapping relationship into the incremental configuration package, and record the configuration values ​​before and after the change for each configuration change record; The incremental configuration package is loaded into the image runtime environment, and the functional verification test cases and the original functional verification test cases generated based on the current configuration information of the target API are executed respectively. When the execution result of the functional verification test case meets the corresponding expected result, and the execution result of the original functional verification test case is consistent with that before loading the incremental configuration package, the incremental configuration package is determined to have passed verification. The rollback operation corresponding to the incremental configuration package is generated based on the configuration values ​​before the change.

10. The method according to claim 9, characterized in that, Also includes: If no corresponding functional sample is found, or if the incremental configuration package fails verification, the corresponding configuration gap, basic configuration template, field mapping relationship and verification result will be sent to the API management console. Receive the manual configuration results returned by the API management console. The manual configuration results include executable configuration nodes, node dependencies, and field mapping relationships used to cover the configuration gaps. After the manual configuration result is verified in the image runtime environment, the manual configuration result and the corresponding functional verification test cases are written into the functional sample library to form a new functional sample.

Images