Gateway API extension dynamic triggering method, system and device and storage medium

Abstract

The invention relates to the technical field of data processing, and particularly provides a gateway API extension dynamic triggering method, system and device and a storage medium, and the method comprises the steps: constructing a plurality of extension modules for each API, and establishing an association relationship between the API and the extension modules; configuring a trigger rule for each expansion module; monitoring behavior data of the API, and confirming that the behavior data is matched with any trigger rule; and determining a target extension module from the associated extension modules of the API based on the matched trigger rule, and executing the target extension module. According to the method, the gateway has self-adaptive capability, and the quick iteration requirement of the API in the cloud computing era is met.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology, specifically relating to a gateway API extension dynamic triggering method, system, device, and storage medium. Background Technology

[0002] With the rapid development of information technology, API interfaces with various protocol types, parameter types, and processing methods are emerging in an endless stream. This poses more challenges to API gateways, which need to provide more functions to meet the needs. However, traditional development methods are time-consuming and labor-intensive, making it difficult to meet the needs of scenarios requiring rapid use. Summary of the Invention

[0003] In view of the above-mentioned shortcomings of the prior art, the present invention provides a gateway API extension dynamic triggering method, system, device and storage medium to solve the above-mentioned technical problems.

[0004] In a first aspect, the present invention provides a method for dynamically triggering gateway API extensions, comprising: Build multiple extension modules for each API and establish the relationship between the API and the extension modules; Configure trigger rules for each type of extension module; Monitor the behavior data of the API and confirm that the behavior data matches any triggering rule; The target extension module is determined from the associated extension modules of the API based on the matching triggering rules, and the target extension module is executed.

[0005] In one optional implementation, multiple extension modules are built for each API, and the association between the API and the extension modules is established, including: The Groovy dynamic compiler is used to compile an extension module with a defined method body structure. The input parameter of the extension module is a context object, which includes the input parameters, output parameters, request address, and request header for the request runtime.

[0006] In one optional implementation, several extension modules include: The request preprocessing stage includes a request validity verification module, a flow control module, and a request parameter enhancement module. The interface dynamic processing phase includes a protocol conversion module, a Mock response module, and a request parameter dynamic reassembly module; The response post-processing stage includes a desensitization module, a response format unification module, and a log monitoring module.

[0007] In an optional implementation, the method further includes: The legality verification module is used to authenticate requests, filter IP addresses, and verify parameter formats before the API interface is actually called. The flow control module is used to perform rate limiting, circuit breaking, or priority routing on requests before the API interface is actually invoked. The request parameter enhancement module is used to add default parameters or encrypt and convert parameters to the request before the API interface is actually called. The protocol conversion module is used to convert the communication protocol during API calls; The Mock response module is used to return preset data based on conditions during API calls; The request parameter dynamic recombination module is used to aggregate multiple interfaces during API calls; The desensitization module is used to hide sensitive words in the response results after the API call is completed; The response format unification module is used to convert the format of the response result after the API call is completed; The log monitoring module is used to log and monitor the response results after an API call is completed.

[0008] In one optional implementation, trigger rules are configured for each extension module, including: The mandatory authentication rule triggers the legality verification module if the request matches the payment-related structure or is missing an authentication header. Rate limiting rules: If a request matches a file to be sent that is larger than a set threshold or a response file that is larger than the threshold, the flow control module will be triggered to perform rate limiting. The circuit breaker rule is that if the query rate per second of the interface exceeds a set threshold or the error rate exceeds a set threshold, the flow control module will be triggered to execute the circuit breaker mechanism. The parameter recombination rule, if a request is found to contain cross-border payment parameters, will trigger the request parameter enhancement module to perform parameter encryption conversion; The protocol conversion rule states that if a matching protocol request exists for another compatible protocol, the protocol conversion module is triggered to perform a communication protocol conversion. The response rule states that if the test environment Mock data is matched, the Mock response module will be triggered to return preset data according to the conditions. If the parameter reorganization rule matches the aggregation of multiple interfaces of the user profile, the request parameter dynamic reorganization module is triggered to perform multi-interface aggregation. The desensitization rule is that if the interface is a user information query interface or a non-administrator role, the desensitization module will be triggered to hide sensitive words in the response results. The format conversion rule will trigger the response format unification module to convert the response format to the required format if the matched response result is inconsistent with the required format. If the monitoring rules match a request execution error or delay, the log monitoring module will be triggered to record the error or delay.

[0009] In an optional implementation, the method further includes: Configure the execution order for the extension modules; Confirm that multiple extension modules have been triggered, and sort the multiple extension modules according to the execution order; Execute the sorted extension modules in sequence.

[0010] In an optional implementation, the method further includes: The sorted extension modules are flushed to the cache, and the extension modules in the cache are executed in sequence.

[0011] Secondly, the present invention provides a gateway API extension dynamic triggering system, comprising: Builder modules are used to build multiple extension modules for each API and establish the relationship between the API and the extension modules; The configuration module is used to configure trigger rules for each type of extension module. The monitoring module is used to monitor the behavior data of the API and confirm that the behavior data matches any triggering rule; An execution module is used to determine a target extension module from the associated extension modules of the API based on matching triggering rules, and to execute the target extension module.

[0012] Thirdly, a device is provided, comprising: Memory, used to store dynamic triggers for gateway API extensions; A processor is configured to implement the steps of the gateway API extension dynamic triggering method as provided in the first aspect when executing the gateway API extension dynamic triggering procedure.

[0013] Fourthly, a computer-readable storage medium is provided, on which a gateway API extension dynamic triggering program is stored, wherein when the gateway API extension dynamic triggering program is executed by a processor, the steps of the gateway API extension dynamic triggering method provided in the first aspect are implemented.

[0014] The beneficial effects of this invention are as follows: the gateway API extension dynamic triggering method, system, device, and storage medium provided by this invention achieve hot-swappable functions by independently constructing multiple extension modules and decoupling them from the API, avoiding repetitive development caused by traditional hard coding; dynamically calling extension modules based on behavioral data matching rules accurately responds to changes in business scenarios; rule-driven automated execution reduces manual intervention, shortening the traditional function iteration from several days to minutes. The overall technology enables the gateway to have adaptive capabilities, meeting the rapid API iteration needs of the cloud computing era.

[0015] Furthermore, the design principle of this invention is reliable, the structure is simple, and it has a very wide range of application prospects. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic flowchart of a method according to an embodiment of the present invention.

[0018] Figure 2 This is a schematic block diagram of a system according to an embodiment of the present invention.

[0019] Figure 3 This is a schematic diagram of the structure of a device provided in an embodiment of the present invention. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0022] The gateway API extension dynamic triggering method provided in this embodiment of the invention is executed by a computer device, and correspondingly, the gateway API extension dynamic triggering system runs in the computer device.

[0023] Figure 1 This is a schematic flowchart illustrating a method according to an embodiment of the present invention. Wherein, Figure 1 The executing entity can be a gateway API extension that dynamically triggers the system. Depending on different requirements, the order of steps in this flowchart can be changed, and some can be omitted.

[0024] like Figure 1 As shown, the method includes: S1. Build multiple extension modules for each API and establish the relationship between the API and the extension modules; S2. Configure trigger rules for each type of extension module; S3. Monitor the behavior data of the API and confirm that the behavior data matches any triggering rule; S4. Determine the target extension module from the associated extension modules of the API based on the matching triggering rules, and execute the target extension module.

[0025] In one embodiment of the present invention, based on step S1, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0026] The execution location and order mechanism of extended modules: The execution of extension modules is divided into three core phases: preAPI (before API call), inAPI (during API call), and afterAPI (after API call). This phased design pattern allows developers to perform fine-grained functional extensions for different stages of the API lifecycle. Each execution position is assigned an integer sequence number as an execution priority identifier. When multiple extension modules are triggered at the same position, the system will arrange them in ascending order according to this sequence number, ensuring that modules are executed sequentially according to their preset priorities. This mechanism effectively avoids functional conflicts caused by disordered module execution order, ensuring the stability and reliability of system operation. For example, in high-concurrency scenarios, multiple flow control modules may operate simultaneously in the preAPI phase. Precise sequencing of sequence numbers ensures that functions such as rate limiting strategies and circuit breaking mechanisms are executed in an orderly manner, achieving effective control over API call traffic. Application of Groovy language in extension modules: The extension modules are written in Groovy, a language highly compatible with Java syntax, allowing Java developers to quickly learn and develop features. Furthermore, Groovy leverages the API gateway's built-in dependency libraries, eliminating the need for complex environment configurations and significantly reducing development costs and deployment complexity. Extension modules are presented as Groovy methods, with method naming following strict conventions, uniformly using "handle" as the method name. Each method accepts a JSON-formatted context object as an input parameter, containing rich runtime request context information. By parsing the context object, developers can obtain key request information such as input parameters, output parameters, request URL, and request headers. This information provides a solid data foundation for the development of personalized extension modules, allowing developers to flexibly customize various extension functions according to actual business needs. For example, in the request validity verification module, authentication and parameter format verification are performed by retrieving authentication information and request parameters from the request header; in the response format unification module, targeted format conversion of the response result is performed based on the request URL and output parameter content. Technical implementation details of each stage of the expansion module: (1) Request pre-processing stage: Request Validation Module: Before the actual API call, the request validity verification module plays a crucial role in ensuring system security. It primarily validates requests from three dimensions: authentication, verifying the identity token and signature information in the request header to determine if the requester has legitimate access rights; IP filtering, based on pre-defined blacklists and whitelists, screens the IP addresses of the request source, rejecting access requests from unauthorized IPs; and parameter format validation, strictly checking the type, length, and value range of request parameters according to the API interface's definition specifications to ensure compliance with interface requirements. These validation mechanisms effectively prevent unauthorized requests and malicious attacks, ensuring the security and stability of the API interface. Traffic control module: The traffic control module plays a crucial role in the preAPI phase. It achieves precise management of API call traffic through strategies such as rate limiting, circuit breaking, and priority routing. Rate limiting employs classic algorithms like the token bucket and leaky bucket algorithms to limit the number of requests per unit time, preventing system overload due to excessive traffic. The circuit breaking mechanism automatically cuts off some requests when the API interface malfunctions or has excessively high response latency, preventing the failure from spreading. Priority routing forwards high-priority requests to backend services based on their priority identifiers, ensuring the smooth operation of critical business processes. The coordinated work of these strategies enables the system to maintain good performance and availability even in high-concurrency scenarios. Request Parameter Enhancement Module: This module optimizes and processes request parameters before API calls. It adds default parameters to requests based on business needs, simplifying parameter passing in front-end development. Simultaneously, it encrypts sensitive parameters using symmetric and asymmetric encryption algorithms to ensure data security during transmission. For example, before a payment interface call, it adds a default payment channel parameter to the request and encrypts the user's payment password, effectively preventing data leakage and tampering. (2) Interface dynamic processing stage: Protocol Conversion Module: During API calls, different systems and services may use different communication protocols, hence the need for a protocol conversion module. It can convert between various protocols such as HTTP, HTTPS, TCP, and UDP, ensuring smooth communication between the API gateway and backend services. The module parses the format and content of the request protocol, converts it to a protocol format recognizable by the backend service, and performs the reverse conversion in the response. This flexible protocol conversion mechanism allows the API gateway to seamlessly integrate with various heterogeneous systems, improving system compatibility and scalability. The Mock response module greatly facilitates API development and testing. During API calls, it can return pre-defined simulated data based on pre-set conditions, such as request parameters and request URLs. In the early stages of API development, before the backend service is fully developed, frontend developers can use the Mock response module to obtain simulated API response data for frontend page development and debugging. During the testing phase, the Mock response module can also be used to simulate various abnormal situations and boundary conditions, comprehensively testing the stability and fault tolerance of the API. Request Parameter Dynamic Reassembly Module: In real-world business scenarios, it's often necessary to call multiple API interfaces to obtain complete business data. This module is designed to solve this problem. During API calls, it aggregates and reassembles the parameters of requests from multiple interfaces. By analyzing the parameter requirements and data relationships of each interface, it merges multiple requests into one or more optimized requests. After obtaining the response data, it integrates and processes the data, returning complete business data to the caller. This functionality effectively reduces the number of API calls, improves data acquisition efficiency, and reduces system communication overhead. (3) Post-response processing stage: The data masking module: After the API call is completed, the data masking module processes sensitive information in the response results to protect user privacy and data security. It uses technologies such as regular expression matching and keyword recognition to hide sensitive information in the response results, such as ID card numbers, bank card numbers, and mobile phone numbers. Data masking methods can employ various forms, including partial character replacement and masking, to ensure that sensitive information is effectively protected without affecting business operations. Response Format Unification Module: To facilitate the processing and display of API response results by front-end applications and other systems, the response format unification module converts the format of response results after API calls are completed. It can uniformly convert response data in different formats, such as JSON, XML, and CSV, into a specified format and standardize the data structure and fields. This reduces the difficulty of front-end development and system integration, and improves data consistency and usability. Log monitoring module: After an API call is completed, the log monitoring module performs log entry and monitoring of the response results. It records key information about the API call, such as request time, request address, input parameters, output parameters, and response status code, and uses log analysis tools to monitor and analyze this data in real time. Through statistical analysis and mining of log data, anomalies and performance bottlenecks in the API call process can be identified in a timely manner, allowing for targeted optimization and adjustments to ensure the stable operation of the API service.

[0027] Using DI frameworks such as Spring Framework and Guice, the association between interfaces and extension modules is achieved through binding using the Qualifier annotation.

[0028] Dependency Injection (DI) is a design pattern that achieves loosely coupled component design by transferring object dependencies from within the object itself to an external container. The Spring Framework and Google Guice are widely used DI frameworks in the Java ecosystem, achieving automatic object wiring through reflection and configuration metadata. When an interface has multiple implementations, type alone cannot uniquely determine the implementation to be injected. The `@Qualifier` annotation, as a metadata marker, provides additional identification information during dependency injection, helping the container accurately select the required implementation class.

[0029] Spring uses the `@Qualifier` annotation to bind interfaces to their implementation classes, directly specifying the name: public interface PaymentProcessor { void processPayment();} @Component("creditCardProcessor") public class CreditCardProcessor implementsPaymentProcessor { @Override public void processPayment() {System.out.println("Processing credit card payment");}} @Component("paypalProcessor") public class PayPalProcessor implements PaymentProcessor{ @Override public void processPayment() { System.out.println("ProcessingPayPal payment");}} @Component public class OrderService { private finalPaymentProcessor paymentProcessor; @Autowired public OrderService(@Qualifier("creditCardProcessor") PaymentProcessor paymentProcessor) {this.paymentProcessor = paymentProcessor;}}.

[0030] In one embodiment of the present invention, based on step S2, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0031] First, select several extension modules to be activated. Then, specify rules for the scope of activation of the extension modules. Rules are prerequisites for the extension modules to take effect. Different conditions can be combined into a single rule, and all APIs covered by this rule will trigger these extension modules at runtime. Available conditions include, but are not limited to: all creators are the same person, the request URI begins with a certain string, the response timeout is greater than a certain time, the response value exceeds a certain value, the request parameter size exceeds a certain value, a request parameter equals a certain value, etc. Extension modules are not executed with all API calls; instead, they take effect only when a specific "rule," that is, one or more conditions, are met. For example, if an extension module prunes interfaces with large response values, the rule would be: the response value length is greater than a certain value. The triggering rules in this implementation include: The mandatory authentication rule triggers the legality verification module if the request matches the payment-related structure or is missing an authentication header. Rate limiting rules: If a request matches a file to be sent that is larger than a set threshold or a response file that is larger than the threshold, the flow control module will be triggered to perform rate limiting. The circuit breaker rule is that if the query rate per second of the interface exceeds a set threshold or the error rate exceeds a set threshold, the flow control module will be triggered to execute the circuit breaker mechanism. The parameter recombination rule, if a request is found to contain cross-border payment parameters, will trigger the request parameter enhancement module to perform parameter encryption conversion; The protocol conversion rule states that if a matching protocol request exists for another compatible protocol, the protocol conversion module is triggered to perform a communication protocol conversion. The response rule states that if the test environment Mock data is matched, the Mock response module will be triggered to return preset data according to the conditions. If the parameter reorganization rule matches the aggregation of multiple interfaces of the user profile, the request parameter dynamic reorganization module is triggered to perform multi-interface aggregation. The desensitization rule is that if the interface is a user information query interface or a non-administrator role, the desensitization module will be triggered to hide sensitive words in the response results. The format conversion rule will trigger the response format unification module to convert the response format to the required format if the matched response result is inconsistent with the required format. If the monitoring rules match a request execution error or delay, the log monitoring module will be triggered to record the error or delay.

[0032] After configuration, select an API for testing. Running this API in test mode will simultaneously execute this extension module. The two results will be output independently for easy comparison to confirm the extension module's effectiveness. Debugging is also possible, with runtime logs displayed in real-time on the debug page.

[0033] In one embodiment of the present invention, based on step S3, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0034] API monitoring is a crucial means of ensuring system stability and performance, and its implementation involves the integration of multiple technologies. At the access layer, API gateways (such as Kong and Spring Cloud Gateway) and load balancers (Nginx and HAProxy) are used to collect real-time metrics such as request traffic, response time, and error rate, outputting data through plugins or built-in modules. The service layer relies on application performance monitoring (APM) tools (SkyWalking and Pinpoint) to trace API method execution details using bytecode enhancement technology and capture anomalies using log analysis (ELK Stack and Sentry). At the data layer, for databases and caches, exporter tools (such as MySQL Exporter) and native monitoring interfaces are used to monitor query performance and storage resource usage. Data from all layers ultimately converges at the management layer, where it is aggregated through platforms such as Prometheus and Elasticsearch, and visualized and alerted using Grafana and Kibana. In recent years, the application of distributed tracing (OpenTelemetry), dynamic adaptive monitoring, and security compliance technologies has further improved the comprehensiveness and intelligence of API monitoring, driving its development towards a full-chain, automated approach.

[0035] Similarity calculation technology is used to match monitoring data with the conditions in the triggering rules.

[0036] In one embodiment of the present invention, based on step S4, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0037] The target extension module is determined from the associated extension modules of the API based on the matching triggering rules, and the target extension module is executed.

[0038] Specifically, the execution process of the extension module includes: Configure the execution order for the extension modules; confirm that multiple extension modules are triggered, and sort the multiple extension modules according to the execution order; refresh the sorted multiple extension modules to the cache, and execute the extension modules in the cache in sequence.

[0039] When dynamically executing extension modules, all active extension modules, APIs, and their associated relationships are periodically refreshed and cached. When an API is executed, the cache is checked to find the API and extension module relationships. Then, these relationships are used to find the list of extension modules to be executed based on the execution position. First, the `preAPI` extension module list is executed sequentially by number. Then, the `inAPI` extension module list is executed. If no such module is found, a request is sent to the original API using the default request format. If a such module is found, only those extension modules are executed, and the default request is not executed. Finally, the `afterAPI` extension module list is executed. When executing an extension module, GroovyShell is first initialized using the default class loader. Then, the global default configuration is loaded, and built-in functions for developer use are loaded as built-in functions for the extension module to use. The request context is added as a parameter. Finally, GroovyShell reads the extension module's content and executes it, saving the output to the context.

[0040] When running extension modules, security management of the API gateway is required. Specific methods include: When registering an extension module, strict syntax restrictions apply, prohibiting the use of commands related to the server shell, API gateway program, or virtual machine processes. Extension modules are launched in a secure sandbox mode during testing. Any malicious behavior detected can trigger an interruption and prevent the extension module from executing; the extension module can only be tested again after modification. Once an extension module is in use, its content cannot be changed to prevent malicious tampering. Loading the extension module's content into the process can only occur once.

[0041] Compared with commonly used methods, this invention offers the following advantages: 1) It provides rich extension module writing methods. The Groovy extension modules used are easy to use and compatible with Java. The extension module location is optional, allowing execution not only before or after requesting the original interface but also directly replacing the way the original interface is requested, greatly expanding the API types supported by the API gateway. 2) It supports online testing of extension modules, facilitating debugging and reducing execution errors. 3) It allows extension modules to be deployed and used immediately without downtime for upgrades, significantly reducing traditional deployment time. 4) It provides comprehensive security protection methods to prevent the use of malicious extension modules and ensure the security of the API gateway and sensitive data.

[0042] In some embodiments, the gateway API extension dynamic triggering system may include multiple functional modules composed of computer program segments. The computer programs of each program segment in the gateway API extension dynamic triggering system may be stored in the memory of a computer device and executed by at least one processor to perform (see details). Figure 1(Description) Gateway API extensions enable dynamically triggered functionality.

[0043] In this embodiment, the gateway API extension dynamic triggering system can be divided into multiple functional modules based on the functions it performs, such as... Figure 2 As shown. The module referred to in this invention is a series of computer program segments that can be executed by at least one processor and perform a fixed function, and is stored in memory. In this embodiment, the functions of each module will be described in detail in subsequent embodiments.

[0044] Builder modules are used to build multiple extension modules for each API and establish the relationship between the API and the extension modules; The configuration module is used to configure trigger rules for each type of extension module. The monitoring module is used to monitor the behavior data of the API and confirm that the behavior data matches any triggering rule; An execution module is used to determine a target extension module from the associated extension modules of the API based on matching triggering rules, and to execute the target extension module.

[0045] Figure 3 The gateway API extension dynamic triggering method provided in the embodiments of this application can be applied to devices. Those skilled in the art will understand that the device structure involved in the embodiments of this invention does not constitute a limitation on the device. A device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. In the embodiments of this invention, the device includes, but is not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments of this application described and / or claimed herein.

[0046] The device 300 may include a processor 310, a memory 320, and a communication unit 330. These components communicate via one or more buses. Those skilled in the art will understand that the server structure shown in the figure does not constitute a limitation of the present invention. It may be a bus topology or a star topology, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0047] The memory 320 can be used to store execution instructions of the processor 310. The memory 320 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. When the execution instructions in the memory 320 are executed by the processor 310, the device 300 is able to perform some or all of the steps in the above method embodiments.

[0048] The processor 310 serves as the control center of the storage device, connecting various parts of the electronic device via various interfaces and lines. It executes software programs and / or modules stored in the memory 320, and calls data stored in the memory to perform various functions of the electronic device and / or process data. The processor can be composed of integrated circuits (ICs), such as a single packaged IC or multiple packaged ICs with the same or different functions connected together. For example, the processor 310 may consist only of a central processing unit (CPU). In this embodiment of the invention, the CPU may have a single processing core or include multiple processing cores.

[0049] The communication unit 330 is used to establish a communication channel, enabling the storage device to communicate with other devices. It can receive user data sent by other devices or send user data to other devices.

[0050] The present invention also provides a computer storage medium, wherein the computer storage medium may store a program, which, when executed, may include some or all of the steps provided in the embodiments of the present invention. The storage medium may be a magnetic disk, an optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0051] Those skilled in the art will clearly understand that the techniques in the embodiments of the present invention can be implemented using software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solutions in the embodiments of the present invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, or any other medium capable of storing program code. It includes several instructions to cause a computer device (which may be a personal computer, a server, or a second device, network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0052] The same or similar parts between the various embodiments in this specification can be referred to mutually. In particular, the device embodiments are basically similar to the method embodiments, so the description is relatively simple, and the relevant parts can be referred to the description in the method embodiments.

[0053] In the embodiments provided by this invention, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between systems or modules may be electrical, mechanical, or other forms.

[0054] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0055] In addition, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0056] Although the present invention has been described in detail with reference to the accompanying drawings and preferred embodiments, the present invention is not limited thereto. Various equivalent modifications or substitutions can be made to the embodiments of the present invention by those skilled in the art without departing from the spirit and essence of the invention, and such modifications or substitutions should all be within the scope of the present invention. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should also be covered within the protection scope of the present invention.

Claims

1. A method for dynamically triggering gateway API extensions, characterized in that, include: Build multiple extension modules for each API and establish the relationship between the API and the extension modules; Configure trigger rules for each type of extension module; Monitor the behavior data of the API and confirm that the behavior data matches any triggering rule; The target extension module is determined from the associated extension modules of the API based on the matching triggering rules, and the target extension module is executed.

2. The method according to claim 1, characterized in that, Build multiple extension modules for each API and establish the relationship between the API and the extension modules, including: The Groovy dynamic compiler is used to compile an extension module with a defined method body structure. The input parameter of the extension module is a context object, which includes the input parameters, output parameters, request address, and request header for the request runtime.

3. The method according to claim 1, characterized in that, Various extension modules include: The request preprocessing stage includes a request validity verification module, a flow control module, and a request parameter enhancement module. The interface dynamic processing phase includes a protocol conversion module, a Mock response module, and a request parameter dynamic reassembly module; The response post-processing stage includes a desensitization module, a response format unification module, and a log monitoring module.

4. The method according to claim 3, characterized in that, The method further includes: The legality verification module is used to authenticate requests, filter IP addresses, and verify parameter formats before the API interface is actually called. The flow control module is used to perform rate limiting, circuit breaking, or priority routing on requests before the API interface is actually invoked. The request parameter enhancement module is used to add default parameters or encrypt and convert parameters to the request before the API interface is actually called. The protocol conversion module is used to convert the communication protocol during API calls; The Mock response module is used to return preset data based on conditions during API calls; The request parameter dynamic recombination module is used to aggregate multiple interfaces during API calls; The desensitization module is used to hide sensitive words in the response results after the API call is completed; The response format unification module is used to convert the format of the response result after the API call is completed; The log monitoring module is used to log and monitor the response results after an API call is completed.

5. The method according to claim 4, characterized in that, Configure trigger rules for each type of extension module, including: The mandatory authentication rule triggers the legality verification module if the request matches the payment-related structure or is missing an authentication header. Rate limiting rules: If a request matches a file to be sent that is larger than a set threshold or a response file that is larger than the threshold, the flow control module will be triggered to perform rate limiting. The circuit breaker rule is that if the query rate per second of the interface exceeds a set threshold or the error rate exceeds a set threshold, the flow control module will be triggered to execute the circuit breaker mechanism. The parameter recombination rule, if a request is found to contain cross-border payment parameters, will trigger the request parameter enhancement module to perform parameter encryption conversion; The protocol conversion rule states that if a matching protocol request exists for another compatible protocol, the protocol conversion module is triggered to perform a communication protocol conversion. The response rule states that if the test environment Mock data is matched, the Mock response module will be triggered to return preset data according to the conditions. If the parameter reorganization rule matches the aggregation of multiple interfaces of the user profile, the request parameter dynamic reorganization module is triggered to perform multi-interface aggregation. The desensitization rule is that if the interface is a user information query interface or a non-administrator role, the desensitization module will be triggered to hide sensitive words in the response results. The format conversion rule will trigger the response format unification module to convert the response format to the required format if the matched response result is inconsistent with the required format. If the monitoring rules match a request execution error or delay, the log monitoring module will be triggered to record the error or delay.

6. The method according to claim 1, characterized in that, The method further includes: Configure the execution order for the extension modules; Confirm that multiple extension modules have been triggered, and sort the multiple extension modules according to the execution order; Execute the sorted extension modules in sequence.

7. The method according to claim 6, characterized in that, The method further includes: The sorted extension modules are flushed to the cache, and the extension modules in the cache are executed in sequence.

8. A gateway API extension dynamic triggering system, characterized in that, include: Builder modules are used to build multiple extension modules for each API and establish the relationship between the API and the extension modules; The configuration module is used to configure trigger rules for each type of extension module. The monitoring module is used to monitor the behavior data of the API and confirm that the behavior data matches any triggering rule; An execution module is used to determine a target extension module from the associated extension modules of the API based on matching triggering rules, and to execute the target extension module.

9. A device, characterized in that, include: Memory, used to store dynamic triggers for gateway API extensions; A processor, configured to implement the steps of the gateway API extension dynamic triggering method as described in any one of claims 1-7 when executing the gateway API extension dynamic triggering procedure.

10. A computer-readable storage medium storing a computer program, characterized in that, The readable storage medium stores a gateway API extension dynamic trigger program, which, when executed by a processor, implements the steps of the gateway API extension dynamic trigger method as described in any one of claims 1-7.

Images