Interface request parameter integration method and device, equipment and storage medium

Abstract

The invention discloses an interface request parameter integration method and device, equipment and a storage medium. The method comprises the following steps: when a service layer initiates an API request, an adaptation layer obtains a protocol type according to the request and routes the protocol type to a corresponding request interceptor; the request interceptor receives and analyzes an API request, obtains an HTTP request header, a URL and an operation behavior parameter, calls a strategy factory to query through a strategy mapping table, and obtains a corresponding strategy class from a strategy registration center; instantiating the strategy class to obtain a strategy instance and sending the strategy instance to the request interceptor; the request interceptor calls a parameter generation interface of the strategy instance to generate a standardized parameter object; and dynamically injecting the standardized parameter object into an HTTP request header to obtain a new API request, and sending the new API request to a back-end interface. According to the method, factory and strategy modes are combined, unified, dynamic and configurable management of interface request parameters is realized, code redundancy is reduced, and maintainability, expansibility and consistency of the system are improved.

Description

Technical Field

[0001] This application relates to the field of system architecture, and more specifically, to a method, apparatus, device, and storage medium for integrating interface request parameters. Background Technology

[0002] Currently, the traditional approach is to explicitly and hard-code these parameters in the business code of each front-end interface call. For example, separate code is written to set the corresponding operation object and behavior identifier for different business functions such as user list query, user information addition, and user information submission. As system complexity and the number of interfaces increase, this decentralized parameter management approach has gradually revealed many drawbacks.

[0003] Therefore, existing technologies suffer from problems such as code redundancy and maintenance difficulties due to duplicate parameter generation code, high coupling between business logic and parameter generation logic, poor system scalability, the need to intrude into business code to add or modify interface parameters, and difficulty in ensuring parameter consistency. Summary of the Invention

[0004] The main objective of this application is to provide a method, apparatus, device, and storage medium for integrating interface request parameters, in order to solve the technical problems existing in the prior art, such as high code redundancy, maintenance difficulties, insufficient scalability, difficulty in ensuring consistency, and excessive coupling, thereby promoting centralized management, configurable management, and dynamic management of parameter generation logic.

[0005] To achieve the above objectives, the first aspect of this application proposes a method for integrating interface request parameters, comprising: When the business layer initiates an API request, the adaptation layer parses the corresponding protocol type according to the API request and routes the request to the appropriate request interceptor based on the protocol type. The request interceptor receives and parses the API request, extracts the HTTP request header, Uniform Resource Locator (URL), and operation behavior parameters, and transmits the URL and operation behavior parameters to the policy factory. The strategy factory obtains the corresponding strategy class from the strategy registry by querying the strategy mapping table based on the received URL and operation behavior parameters. Perform an instantiation operation on the strategy class, generate a strategy instance, and return it to the request interceptor; The request interceptor calls the parameter generation interface of the strategy instance to generate a standardized parameter object; The standardized parameter object is dynamically injected into the HTTP request header to form a new API request and forward it to the backend interface.

[0006] In some embodiments of this disclosure, the policy mapping table contains mapping records of the mapping relationship between the URL, the operation behavior parameters and the policy class.

[0007] In some embodiments of this disclosure, the policy mapping table supports a two-dimensional matching mechanism: The first dimension performs path matching based on the URL; The second dimension performs enumeration value matching based on the operational behavior parameters.

[0008] In some embodiments of this disclosure, the step of obtaining the corresponding policy class from the policy registry by querying the policy mapping table specifically includes: Perform a first-dimensional match based on the URL. If the match result is a direct mapping, then directly read the strategy class from the mapping record. If the matching result is a behavior mapping, then perform a second-dimensional matching based on the operation behavior parameters; If the second dimension matches successfully, then read the strategy class from the mapping record; If no strategy class corresponding to the URL and operation behavior parameters is found, a fallback scheme is executed to inject predefined default parameters or basic parameters into the API request.

[0009] In some embodiments of this disclosure, prior to the step of dynamically injecting the standardized parameter object into the HTTP request header, the method further includes: The standardized parameter object is validated using a parameter validation engine. If the verification fails, the API request will be intercepted and a parameter verification error will be displayed. If the verification passes, proceed with the subsequent parameter injection steps.

[0010] In some embodiments of this disclosure, dynamically injecting the standardized parameter object into the HTTP request header includes: Based on the HTTP method type of the API request, the standardized parameter object is injected differentially. For GET requests, inject the standardized parameter object into the query string; For POST, PUT, and PATCH requests, the standardized parameter object is injected into the request body or request header.

[0011] In some embodiments of this disclosure, it also includes: The policy registration center provides a dynamic registration interface mechanism for the policy mapping table; The policy registry provides a dynamic deregistration interface mechanism for the policy mapping table; During system operation, the policy registration center supports dynamic updates of the policy mapping table.

[0012] A second aspect of this application proposes an interface request parameter integration device, comprising: The routing module is used to parse the corresponding protocol type according to the API request when the business layer initiates an API request, and then route the request to the corresponding request interceptor according to the protocol type. The interception and parsing module is used to receive and parse the API request, extract the HTTP request header, URL and operation behavior parameters, and transmit the URL and operation behavior parameters to the policy factory. The policy query module is used to obtain the corresponding policy class from the policy registry by querying the policy mapping table based on the received URL and operation behavior parameters. The strategy instantiation module is used to perform an instantiation operation on the strategy class, generate a strategy instance, and return it to the request interceptor. The parameter generation module is used to generate standardized parameter objects by calling the parameter generation interface of the strategy instance; The parameter injection module is used to dynamically inject the standardized parameter object into the HTTP request header, forming a new API request and forwarding it to the backend interface.

[0013] In some embodiments of this disclosure, the policy mapping table contains mapping records of the mapping relationship between the URL, the operation behavior parameters and the policy class.

[0014] In some embodiments of this disclosure, the policy mapping table supports a two-dimensional matching mechanism: The first dimension performs path matching based on the URL; The second dimension performs enumeration value matching based on the operational behavior parameters.

[0015] In some embodiments of this disclosure, the strategy query module is specifically used to perform a first-dimensional matching based on the URL. If the matching result is a direct mapping, the strategy class in the mapping record is directly read. If the matching result is a behavior mapping, a second-dimensional matching is performed based on the operation behavior parameters. If the second-dimensional matching is successful, the strategy class in the mapping record is read. If no strategy class corresponding to the URL and operation behavior parameters is found, a fallback scheme is executed to inject predefined default parameters or basic parameters into the API request.

[0016] In some embodiments of this disclosure, the system further includes: a verification module, configured to perform validity verification on the standardized parameter object through a parameter verification engine; if the verification fails, the API request is intercepted and a parameter verification error is indicated; if the verification passes, subsequent parameter injection steps are executed.

[0017] In some embodiments of this disclosure, the parameter injection module is specifically used to inject the standardized parameter object in a differentiated manner according to the HTTP method type of the API request; for GET requests, the standardized parameter object is injected into the query string; for POST, PUT, and PATCH requests, the standardized parameter object is injected into the request body or request header.

[0018] In some embodiments of this disclosure, it further includes: an interface management module, used to provide a dynamic registration interface mechanism for the policy mapping table through the policy registration center; and to provide a dynamic deregistration interface mechanism for the policy mapping table through the policy registration center; In some embodiments of this disclosure, a policy mapping table management module is also included, which supports dynamic updates of the policy mapping table through the policy registry center during system operation.

[0019] A third aspect of this application provides a computer device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method as described in any of the above embodiments.

[0020] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method as described in any of the above embodiments.

[0021] The technical solutions provided by the embodiments of this application may include the following beneficial effects: This application employs the strategy pattern to encapsulate parameter generation methods for different interfaces or operational behaviors, with each method encapsulated within an independent strategy instance. Simultaneously, the factory pattern is used to uniformly manage and schedule these strategy instances. Combined with API request interceptor technology, strategy selection, parameter generation, and injection operations are automatically and non-intrusively completed before the request is issued. This method offers the following advantages: Through centralized interceptors and strategy factories, hard-coded parameter logic in business code is eliminated. Practice shows that this method can reduce redundant code by 80%–92%. When parameter logic changes, only the corresponding strategy implementation class needs modification, eliminating the need for global search and replacement, significantly improving maintenance efficiency. When adding a new interface, only a new strategy class needs to be written and the mapping relationship registered in the factory; no modification to the business code is required, strictly adhering to the open / closed principle. All interface parameters are generated through a unified strategy interface, ensuring consistency in parameter names, formats, and generation logic, improving the standardization of interaction with the backend. Decoupling the cross-cutting concern of parameter generation from core business logic makes the business code have a single responsibility and a clear structure, significantly improving code readability and testability. Based on a two-dimensional matching (interface and operation) and dynamic registration mechanism, it supports fine-grained parameter control for different operations on the same interface and can adapt to runtime configuration changes. Built-in parameter validation and exception handling mechanisms effectively intercept illegal parameters, prevent erroneous requests from reaching the backend, and ensure the availability of core business operations through degradation strategies.

[0022] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of the embodiments of this application and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of this application are described below. Attached Figure Description

[0023] The accompanying drawings, which form part of this application, are used to provide a further understanding of the application and to make other features, objects, and advantages of the application more apparent. The illustrative embodiments and descriptions of this application are used to explain the application and do not constitute an undue limitation of the application. In the drawings: Figure 1 A schematic diagram of the interface request parameter integration system provided in this application; Figure 2 A flowchart of the interface request parameter integration method provided for this application; Figure 3 A schematic diagram of the strategy matching logic provided in this application; Figure 4 A flowchart illustrating the workflow provided for this application; Figure 5 Another workflow diagram provided for this application; Figure 6A schematic diagram of the interface request parameter integration device provided in this application; Figure 7 This is a schematic diagram of the structure of a computer device provided in this application.

[0024] In the accompanying diagram, markers with the same last two digits correspond to the same elements. It should be noted that the elements in the diagram are schematic and not drawn to scale. Detailed Implementation

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

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0027] In this application, the terms "upper," "lower," "left," "right," "front," "rear," "top," "bottom," "inner," "outer," "middle," "vertical," "horizontal," "lateral," and "longitudinal" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. These terms are primarily for the purpose of better describing this application and its embodiments, and are not intended to limit the indicated device, element, or component to having a specific orientation, or to be constructed and operated in a specific orientation.

[0028] Furthermore, in addition to indicating location or positional relationship, some of the aforementioned terms may also have other meanings. For example, the term "above" may also be used in some cases to indicate a certain dependency or connection relationship. Those skilled in the art can understand the specific meaning of these terms in this application based on the specific circumstances.

[0029] Furthermore, the terms "installation," "setup," "equipped with," "connection," "linked," and "socketing" should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral structure; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium, or an internal connection between two devices, components, or parts. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0030] In the description of this application, unless otherwise stated, "multiple" means two or more (including two), and similarly, "multiple groups" means two or more (including two groups).

[0031] Terminology Explanation: URL: Uniform Resource Locator, is a unique address identifier for standard resources on the Internet, supporting access to various resources such as web pages, files, and services; API: Application Programming Interface. It is a predefined collection of functions in a program or related component that allows developers to create applications without knowing the internal implementation, simply by calling the function prototypes. HTTP: Hypertext Transfer Protocol.

[0032] Figure 1 A schematic diagram of the system architecture for integrating interface request parameters provided in this application. The system includes the following core components: 1. Policy Registry: As a centralized policy management component, it is responsible for centrally storing and managing the mapping relationship between URLs, actions, and policy classes. It provides dynamic registration and deregistration interfaces and supports runtime dynamic updates of the policy mapping table.

[0033] 2. Policy Factory: As the core routing component, it connects to the policy registry center. Its functions include: receiving the target URL and operation behavior parameters; accessing the policy mapping table of the policy registry center; obtaining the corresponding policy class based on the mapping relationship and instantiating it; maintaining the policy mapping table, associating the URL with the policy class, and the registration interface URL with the policy mapping relationship; implementing the policy retrieval method, and returning the policy instance based on the URL and operation behavior parameters.

[0034] 3. Strategy Implementation Objects: These are pre-registered with the strategy registry. Each strategy implementation class must implement at least one unified parameter generation interface, and can extend the `validate()` method to implement custom validation logic and generate parameter objects.

[0035] 4. Request Interceptor: Configured in the HTTP request library, it automatically identifies HTTP methods (such as GET, POST, PUT, etc.). Its functions include: intercepting API requests; invoking the policy factory; executing parameter injection logic; and supporting exception handling and service degradation schemes. Specific implementations can be integrated into request interceptors in request libraries such as axios.

[0036] 5. Parameter Validation Engine: Associated with the strategy implementation class, it performs basic rule validation (such as mandatory field checks and format verification) on parameter objects generated by the strategy implementation class, and supports custom validation rules to intercept the generation of illegal parameters. The strategy implementation object can override or extend the validation rules of the parameter validation engine.

[0037] 6. Adapter Layer: This layer encapsulates the interceptor interfaces for different HTTP request libraries, enabling the installation and execution of these interceptors across various libraries. It supports multiple request protocols, such as axios, fetch, and the built-in request methods of the uni-app framework.

[0038] 7. Business layer: Call standard API interfaces, pass operation behavior (`action`) parameters, and achieve non-intrusive integration of business logic.

[0039] Optionally, request interceptors (such as `request.js`) are built on top of HTTP clients (such as Axios) and automatically and non-intrusively complete strategy selection, parameter generation, and injection before the request is sent. They are responsible for intercepting API requests initiated by the business layer, automatically extracting the target URL and operation parameters, calling the strategy factory to obtain the parameter generation strategy, dynamically injecting the generated parameters into the HTTP request header, and implementing exception handling and degradation schemes to ensure system availability.

[0040] The strategy factory (such as `HeaderStrategyFactory`) is integrated into the Axios request interceptor to achieve unified management of strategies. Specifically, it includes: maintaining a strategy mapping table (`strategyMap`) to define mapping records between URLs, operation behavior parameters and strategy implementation classes; providing a strategy retrieval method to perform two-dimensional matching based on the target URL and operation behavior parameters; and instantiating strategy implementation classes to generate strategy instances.

[0041] In the strategy instance module, each strategy instance encapsulates a specific parameter generation interface, implementing a unified generation method (`generate`) and returning a standardized parameter object (e.g., `{customOperateObject:'xxx',customOperateBehavior:'xxx'}`). It also supports an optional parameter validation method (`validate`) to verify the validity of the generated parameters. Strategy instances generate parameters based on request context information. This system encapsulates the parameter generation logic for different interfaces or operational behaviors using the StrategyPattern pattern and manages and schedules strategy instances uniformly using the FactoryPattern pattern.

[0042] Example 1 Figure 2 This is a flowchart illustrating an interface request parameter integration method provided in an embodiment of this disclosure. Figure 2 As shown, the execution process of this method includes: S210, When the business layer initiates an API request, the adaptation layer parses the corresponding protocol type according to the API request and routes the request to the corresponding request interceptor according to the protocol type; In practice, the business layer (e.g., the `UserService.getUserList()` method calls `request.get(' / user / list')`) initiates an API request carrying the URL and `Action` parameters. This request is captured by the adapter layer, which then obtains its protocol type and routes it to the corresponding request interceptor.

[0043] The adaptation layer is a multi-protocol adaptation layer, providing multi-protocol extension capabilities.

[0044] It should be noted that the following initialization steps must be completed before executing step S210: S2001, Initialize the policy factory and registry center. Specifically, it is necessary to create a policy factory and pre-configure or dynamically register policy mapping relationships.

[0045] In 2002, a strategy interface and a basic strategy class were defined. Specifically, a unified strategy interface and an abstract class containing basic validations were defined.

[0046] The interface specification is as follows: Example of a strategy implementation class (Strategies): The personnel search strategy returns `{customOperateObject:'memberList',customOperateBehavior:'memberList_search'}` Strategy Factory Interface: register(url: string, strategy: Strategy|Object): void / / Strategy registration unregister(url: string): boolean / / Policy unregistration getStrategy(url: string, action?: string): Strategy / / Get strategy Strategy Interface: interface IStrategy { generate(config: RequestConfig): ParameterObject; / / Parameter generation validate?(params: object): boolean; / / Parameter validation (optional) } Request interceptor interface: const interceptor = { onRequest: (config: RequestConfig) =>{ / / Parameter injection logic return enrichedConfig; } } S2003 is a concrete strategy class that implements specific strategies for different interfaces and operations.

[0047] In 2004, a registration strategy mapping relationship was established, which associates the URL and Action with the strategy class during application initialization.

[0048] 2005, integrated request interceptors, integrating strategy invocation and parameter injection logic into the request interceptors of Axios (or other request libraries).

[0049] In 2006, the business layer made calls, and the business layer code became very concise. You only need to focus on the business itself and do not need to worry about the generation of operation identifier parameters.

[0050] S220, the request interceptor receives and parses the API request, extracts the HTTP request header, Uniform Resource Locator (URL), and Action parameter, and transmits the URL and Action parameter to the policy factory.

[0051] In practice, a request interceptor is configured from the front-end application's HTTP request library (such as Axios). When the business layer initiates an API request, the request is captured by the interceptor before it is actually sent. The interceptor parses the HTTP request headers, URL (such as ' / user / list'), and action parameters from the request configuration (RequestConfig).

[0052] After parsing, the `getStrategy` method of the strategy factory is called, passing in the URL and Action parameters. The transmission process incorporates a lightweight fault-tolerance mechanism, including parameter validity validation and exception handling; if no URL, URL format errors, or invalid operations are detected, the system switches to the original process, ensuring compatibility with the original workflow.

[0053] Specifically, the Action parameter can be obtained in the following ways: Retrieve the declared action from the request configuration; Query a specific field from the data body or query parameters in the request configuration as an action; If not specified, the action is inferred based on the HTTP method.

[0054] Each API request is parsed using a request interceptor to obtain the information needed for policy matching.

[0055] Optionally, exception protection for policy matching can be added to the request interceptor.

[0056] S230. The policy factory obtains the corresponding policy class from the policy registry by querying the policy mapping table based on the received URL and operation behavior parameters.

[0057] In practice, the strategy factory (e.g., `HeaderStrategyFactory`) queries the strategy registry based on the received URL (e.g., ` / user / list`) to obtain a strategy mapping table (e.g., `strategyMap`). This strategy mapping table defines the mapping relationship between URLs, action parameters, and strategy classes, containing corresponding mapping records. This mapping table supports two modes: direct mapping and action mapping. Direct mapping is suitable for interface scenarios with unified parameter logic, directly associating a single URL with a specific strategy class. Action mapping, on the other hand, uses a nested structure to implement the correspondence between different action parameters and strategy classes under the same URL (e.g., the URL maps to an object that contains mappings from different Actions to strategy classes), to meet complex business needs.

[0058] Specifically, the policy mapping table employs a two-dimensional matching mechanism: 1. First dimension: URL-based execution path matching; 2. Second dimension: Perform enumeration value matching based on operation behavior parameters.

[0059] This two-dimensional matching mechanism supports precise matching based on URL and Action, allowing the same URL (e.g., ` / user / save`) to be associated with different parameter generation strategies based on different operation behaviors (e.g., `'add'` and `'submit'`), thus adapting to the needs of complex business scenarios.

[0060] The step of retrieving the corresponding policy class from the policy registry by querying the policy mapping table specifically includes: 1. Perform first-dimensional matching based on the URL: If the matching result is a direct mapping, then the strategy class in that mapping record is read directly; If the matching result is a behavior mapping, then perform a second-dimensional matching based on the operation behavior parameters.

[0061] 2. If the second dimension matches successfully, then read the strategy class from the mapping record; 3. If no strategy class corresponding to the URL and operation behavior parameters is found, a fallback scheme is executed to inject predefined default parameters or basic parameters into the API request.

[0062] Optionally, the strategy mapping table can support queries of different dimensions based on the input information.

[0063] Optionally, the strategy mapping table can be designed as a single-dimensional, two-dimensional, or multi-dimensional unified structure. A unified structure means that all records in the mapping table use the same structure: Single-dimensional structure: contains only directly associated formats, i.e., strategy classes directly associated via URL.

[0064] Two-dimensional structure: It only contains non-directly related formats, that is, all records contain URL, operation behavior and policy class information, and the policy class is associated by hierarchical matching through URL and operation behavior.

[0065] Structures with two or more levels: Hierarchical levels exceeding two. For example, a three-level structure adds sub-operation levels on top of URLs and operation behaviors, and associates strategy classes through URLs, operation behaviors, and sub-operation information.

[0066] Optionally, the policy mapping table can also be designed as a hybrid-dimensional structure. A hybrid structure means that the mapping table can simultaneously contain records of different dimensions: It contains zero or one or more one-dimensional direct association format records (direct association strategy class via URL).

[0067] It contains zero or one two-dimensional non-directly associated records (containing URL, operation behavior and policy class information, with policy class associated through URL and operation behavior).

[0068] It contains zero or more two-dimensional or higher non-directly related records. For example, a three-dimensional non-directly related record (containing URL, operation behavior, sub-operation behavior, and policy class information, with policy class associated through URL, operation behavior, and sub-operation behavior).

[0069] Specific implementation methods also include: The policy registration center provides a dynamic registration interface mechanism for policy mapping tables. The policy registry provides a dynamic deregistration interface mechanism for the policy mapping table; During system operation, the policy registration center supports dynamic updates of the policy mapping table.

[0070] The policy mapping table can be preset during module initialization and supports dynamic updates at runtime (including registration updates, deletion updates, and modification updates): Registration Update: Implemented through the registration method provided by the strategy factory, adding a new record to the mapping table based on the URL, operation behavior, and strategy class.

[0071] Deletion and Update: Implemented through the deletion method provided by the strategy factory, which deletes records in the mapping table based on the URL, operation behavior, and strategy class.

[0072] Modification and update: This is achieved through the modification methods provided by the strategy factory, which modify records in the mapping table based on the URL, operation behavior, and strategy class.

[0073] This application adopts dynamic policy management: the policy registry provides dynamic registration (`register`) and unregister (`unregister`) interfaces, allowing the application to dynamically add, update or remove policy mapping records at runtime, realizing hot policy updates, and adapting to interface changes without restarting the application.

[0074] The policy factory, through the policy mapping table and policy retrieval methods maintained by the policy registry, transforms the requested URL and operation parameters into specific policy instances, providing a unified scheduling center for parameter generation. It supports precise matching based on both URL and Action, allowing the same URL (e.g., ` / user / save`) to be associated with different parameter generation policies depending on different operation behaviors (e.g., `'add'` and `'submit'`).

[0075] Figure 3 A schematic diagram of the strategy matching logic provided for this application.

[0076] S240. Perform an instantiation operation on the strategy class, generate a strategy instance, and return it to the request interceptor.

[0077] In practice, after obtaining a matching strategy class, the strategy factory instantiates it, creating a specific strategy instance. Each strategy instance is created through a standard process (such as constructor calls and initialization), forming an executable instance object that matches the URL and operation behavior. The system provides a unified configuration interface for strategy instances to simplify development complexity.

[0078] Strategy class instantiation can be achieved using reflection. The specific process includes: dynamically obtaining class information (class object) through the fully qualified name of the target strategy class, then obtaining and calling its constructor to complete the instance initialization operation, and finally obtaining the strategy instance.

[0079] When an exception occurs during the policy instantiation process, exception handling is performed.

[0080] S250. The request interceptor calls the parameter generation interface of the strategy instance to generate a standardized parameter object.

[0081] In a specific implementation, the request interceptor invokes the parameter generation interface (such as the `generate(config)` method) of the policy instance. This interface executes specific parameter generation logic and returns a standard parameter object conforming to a predetermined format (e.g., `{customOperateObject:'xxx',customOperateBehavior:'xxx'}`).

[0082] Specifically, the generation of the standardized parameter object includes: Generate a parameter object containing an operation object identifier (`customOperateObject`) and an operation behavior identifier (`customOperateBehavior`); The parameter object is in the format `{customOperateObject:[Operation object identifier],customOperateBehavior:[Operation behavior identifier]}`.

[0083] Each strategy instance encapsulates specific parameter generation logic by implementing a unified generation interface.

[0084] The system defines a parameter object format specification: each parameter object must contain `customOperateObject` and `customOperateBehavior` fields. Policies can add extended fields according to business needs, and all extended fields follow a unified naming convention to ensure that parameters generated by different policies maintain structural consistency.

[0085] When an error occurs during parameter generation, exception handling is performed.

[0086] S260. Dynamically inject the standardized parameter object into the HTTP request header to form a new API request and forward it to the backend interface.

[0087] In practice, the system selects an appropriate injection strategy based on the HTTP method type and content format of the API request to ensure that the original request functionality is preserved while complying with the HTTP protocol specifications.

[0088] Optionally, the standardized parameter object can be injected differentially based on the HTTP method type of the API request: For GET requests, inject the parameter object into the query string (`params`); For POST, PUT, and PATCH requests, inject the parameter object into the request body (`data`) or the request header (`headers`).

[0089] Specifically, the request interceptor dynamically merges the key-value pairs of the parameter object into the HTTP header field of the original API request, or injects them into the appropriate location according to the rules mentioned above. Ultimately, a complete HTTP request carrying the required operation identifier parameters is formed and sent to the backend interface. The frontend business code does not need to handle this injection process.

[0090] Optionally, the system provides an injection verification function to verify whether the parameters have been set correctly after the injection is completed, so as to ensure the reliability of the system.

[0091] It should be noted that a parameter verification step is included before step S260: A validation mechanism is introduced after parameter generation and before injection. The strategy class can implement or inherit an optional validation interface (such as the `validate(params)` method). The parameter validation engine performs basic validations (such as checking the existence of required fields and the correctness of data types) as well as strategy-specific custom validation logic.

[0092] The standardized parameter object is validated using a parameter validation engine. If the verification fails, the API request will be intercepted and a parameter verification error will be displayed. If the verification passes, proceed with the subsequent parameter injection steps.

[0093] If the verification fails, the request will be blocked and an error will be reported.

[0094] In practice, the newly generated API request is returned and further processed by the Axios library. Finally, the request, carrying complete operation identifier parameters, is sent to the backend interface ` / user / list`, forming a request instance that conforms to the backend specification.

[0095] Request instances that conform to backend specifications ensure the availability, compatibility, and security of the interface primarily through structured constraints, unified core parameters, and standardized formats. Following these specifications can significantly reduce frontend and backend integration costs, decrease interface anomalies, and improve the ease of future maintenance and expansion.

[0096] Optionally, before sending a request, the system performs a consistency check to verify the correctness of the input parameters and whether their format meets the requirements of the backend interface. If a problem is found, the system logs a warning and determines whether to block the request from being sent based on the warning level.

[0097] The system employs an exception handling and default mechanism: throughout the process, it captures and handles exceptions such as policy matching failure, policy instantiation errors, parameter generation errors, and parameter validation failures. For example, when policy matching fails, a default solution can be used to set a set of predefined basic parameters for the request, or the request can be forwarded normally after logging, thereby ensuring system availability.

[0098] The proposed method for integrating API request parameters utilizes a request interceptor to intercept and process API requests. It obtains parameter generation strategies through a strategy factory and dynamically injects the generated parameters into the HTTP request header of the API request. Based on a modular architecture and standardized processes, this method automates the management of API request parameters, effectively improving the maintainability and scalability of the system.

[0099] Example 2 Figure 4 A flowchart illustrating the workflow provided for this application; such as Figure 4 As shown, it includes the following steps: Step 401: The business layer initiates an API request.

[0100] Step 402: Policy Configuration Determination. Parse the API request based on the message type and format to determine if policy configuration is supported. If not, proceed to step 408 (Send Request); if yes, proceed to step 403.

[0101] Step 403: Extracting URL and Action Parameters. After completing the API message parsing, extract the URL and action parameters based on the message type and format.

[0102] Step 404: Strategy Factory Invocation. The strategy functionality is obtained through the HeaderStrategyFactory.getStrategy method. The specific process is as follows: based on the input URL and action parameter, all mapping records are queried in the strategy mapping table, and the URL and action parameter are matched.

[0103] Step 405: Policy Matching Determination. Check if a mapping record exists in the policy mapping table that matches the URL and action parameter. If no match is found, proceed to step 408; if a match is found, proceed to step 406.

[0104] Step 406: Parameter object generation. Parse the matched mapping record to obtain the corresponding strategy class, instantiate the strategy class, call the strategy.generate method to generate the parameter object, and then execute step 407.

[0105] Step 407: Request Header Parameter Injection. Add the generated parameter object to the HTTP request header of the API request, forming a new API request with the injected standardized parameter object.

[0106] Step 408: Send Request. Send the new API request (with the injected standardized parameter object) or the original API request to the backend interface.

[0107] Example 3 Figure 5 Another workflow diagram provided for this application; such as Figure 5 As shown, the process includes the following steps: Step 501: The front-end application sends an API request message to the request interceptor. This message includes the HTTP request header, URL, and operation parameters. Step 502: After receiving the API request, the request interceptor parses it, extracts the HTTP request header, URL and operation behavior parameters, and passes the URL and operation behavior parameters to the strategy factory through the `getStrategy` message. Step 503: The strategy factory queries the strategy mapping table based on the received URL and operation behavior parameters to obtain the strategy class corresponding to the URL and operation behavior; Step 504: Based on the obtained strategy class, perform instantiation to generate a strategy instance; Step 505: Return the generated policy instance to the policy factory; Step 506: After receiving the policy instance, the policy factory returns it to the request interceptor; Step 507: After the request interceptor receives the policy instance, it calls its `generateParams` method to generate a standardized parameter object. Step 508: After the request interceptor obtains the standardized parameter object, it dynamically writes it into the HTTP request header to generate a new API request containing the standardized parameters. Step 509: Send the new API request to the backend interface.

[0108] Example 4 A bank has achieved remarkable results after implementing a new generation of core business systems. The system covers over 300 front-end modules, processes over 500,000 transactions daily, and calls over 2,000 APIs. Before the upgrade, the system suffered from numerous hard-coded parameters, high code duplication, complex audit rule changes, and slow deployment of new services.

[0109] After implementing this solution, the bank integrated a request interceptor to handle all API requests and added signature encryption functionality. The strategy factory adopts a distributed deployment, synchronizing over 5000 mapping rules through a distributed cache and managing them in groups by business domain. Basic strategy classes and business strategy classes were developed to handle general parameters and scenario-specific parameters, respectively, such as generating differentiated parameters for loan approval processes based on factors like amount and customer level.

[0110] Parameter validation performs a rigorous three-layer verification: format validation, business rule validation, and compliance validation. Failure to validate results in request blocking and an alert being issued. The dynamic management function allows business personnel to configure simple rules themselves, while the technical team handles complex logic, reducing the new business launch cycle from weeks to days.

[0111] The results include: a 40% reduction in codebase size and a 92% reduction in parameter-related code; a reduction in global change implementation time from 3-5 days to 2 hours; zero production incidents caused by parameter errors, with 15-20 illegal parameter attempts intercepted daily; and a 25% improvement in server resource utilization efficiency. Taking the loan approval process as an example, the parameter generation logic at each stage is centrally managed through strategy groups, improving risk control efficiency and system modernization.

[0112] Example 5 Taking a specific "user management" scenario as an example, the system collaboration mechanism will be explained in detail: 1. System initialization: When the application starts, it registers all predefined strategies and mapping relationships with the registry center through `strategyRegistration.js`.

[0113] 2. Business layer initiates request: When a user clicks the "Add User" button in `UserManage.vue`, the operation identifier (such as `'add') is passed through `$action`, making the business code concise and focused.

[0114] 3. Request interception and matching: The interceptor captures the `httpClient.post` call, parses the URL and action, and queries and instantiates the corresponding strategy class (such as `MemberListAddStrategy`) through `HeaderStrategyFactory.getStrategy()`.

[0115] 4. Parameter generation and validation: The interceptor calls the `generate(config)` method of the strategy instance to generate parameters (such as the operation object and behavior identifier), and passes the validation through `validate()`.

[0116] 5. Parameter Injection and Sending: The interceptor merges the parameters into the request header (such as `Custom-Operate-Object` and `Custom-Operate-Behavior`) and sends them to the backend.

[0117] 6. Dynamic Expansion Scenarios: Adding new features (such as "batch import") only requires creating a new strategy class and registering the mapping, without modifying existing code. The system implements multiple optimizations: eliminating hard coding and reducing code volume by 92%; improving maintenance efficiency by 65%; centralizing parameter logic management and eliminating formatting issues; the validation engine intercepts illegal parameters, resulting in a near-zero error rate; supporting multiple HTTP methods and runtime environments; reducing the time for adding interface configurations to a few minutes, with low risk; and ensuring clear business development responsibilities and efficient collaboration.

[0118] Example 6 Based on the above embodiments, this disclosure also provides an interface request parameter integration device, such as... Figure 6 As shown, the interface request parameter integration device includes: The routing module 601 is used to, when the business layer initiates an API request, parse the corresponding protocol type according to the API request, and route the request to the corresponding request interceptor according to the protocol type. The interception and parsing module 602 is used to receive and parse the API request, extract the HTTP request header, URL and operation behavior parameters, and transmit the URL and operation behavior parameters to the policy factory. The policy query module 603 is used to obtain the corresponding policy class from the policy registry by querying the policy mapping table based on the received URL and operation behavior parameters. The strategy instantiation module 604 is used to perform an instantiation operation on the strategy class, generate a strategy instance and return it to the request interceptor; The parameter generation module 605 is used to generate a standardized parameter object by calling the parameter generation interface of the strategy instance; The parameter injection module 606 is used to dynamically inject the standardized parameter object into the HTTP request header, form a new API request, and forward it to the backend interface.

[0119] In a specific implementation, the strategy mapping table contains mapping records of the mapping relationship between the URL, the operation behavior parameters and the strategy class.

[0120] In a specific implementation, the strategy mapping table supports a two-dimensional matching mechanism: The first dimension performs path matching based on the URL; The second dimension performs enumeration value matching based on the operational behavior parameters.

[0121] In a specific implementation, the strategy query module 603 is specifically used to perform a first-dimensional matching based on the URL. If the matching result is a direct mapping, the strategy class in the mapping record is directly read. If the matching result is a behavior mapping, a second-dimensional matching is performed based on the operation behavior parameters. If the second-dimensional matching is successful, the strategy class in the mapping record is read. If no strategy class corresponding to the URL and operation behavior parameters is found, a fallback scheme is executed to inject predefined default parameters or basic parameters into the API request.

[0122] In a specific implementation, it also includes: a verification module 607, used to perform validity verification on the standardized parameter object through a parameter verification engine; if the verification fails, the API request is intercepted and a parameter verification error is indicated; if the verification passes, the subsequent parameter injection steps are executed.

[0123] In a specific implementation, the parameter injection module 606 is specifically used to inject the standardized parameter object in a differentiated manner according to the HTTP method type of the API request; for GET requests, the standardized parameter object is injected into the query string; for POST, PUT, and PATCH requests, the standardized parameter object is injected into the request body or request header.

[0124] In a specific implementation, it also includes: an interface management module 608, used to provide a dynamic registration interface mechanism for the policy mapping table through the policy registration center; and to provide a dynamic deregistration interface mechanism for the policy mapping table through the policy registration center; In a specific implementation, it also includes: a policy mapping table management module 609, which supports the dynamic updating of the policy mapping table through the policy registration center during system operation.

[0125] This application employs the strategy pattern to encapsulate parameter generation methods for different interfaces or operational behaviors, with each method encapsulated within an independent strategy instance. Simultaneously, the factory pattern is used to uniformly manage and schedule these strategy instances. Combined with API request interceptor technology, strategy selection, parameter generation, and injection operations are automatically and non-intrusively completed before the request is issued. This method offers the following advantages: Through centralized interceptors and strategy factories, hard-coded parameter logic in business code is eliminated. Practice shows that this method can reduce redundant code by 80%–92%. When parameter logic changes, only the corresponding strategy implementation class needs modification, eliminating the need for global search and replacement, significantly improving maintenance efficiency. When adding a new interface, only a new strategy class needs to be written and the mapping relationship registered in the factory; no modification to the business code is required, strictly adhering to the open / closed principle. All interface parameters are generated through a unified strategy interface, ensuring consistency in parameter names, formats, and generation logic, improving the standardization of interaction with the backend. Decoupling the cross-cutting concern of parameter generation from core business logic makes the business code have a single responsibility and a clear structure, significantly improving code readability and testability. Based on a two-dimensional matching (interface and operation) and dynamic registration mechanism, it supports fine-grained parameter control for different operations on the same interface and can adapt to runtime configuration changes. Built-in parameter validation and exception handling mechanisms effectively intercept illegal parameters, prevent erroneous requests from reaching the backend, and ensure the availability of core business operations through degradation strategies.

[0126] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the present invention according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0127] This application also provides a computer device. Please refer to the following for details. Figure 7 , Figure 7 This is a basic structural block diagram of the computer device in this embodiment.

[0128] The computer device includes a memory 710 and a processor 720 that are interconnected via a system bus. It should be noted that only a computer device with components 710-720 is shown in the figure; however, it should be understood that it is not required to implement all the shown components, and more or fewer components may be implemented alternatively. Those skilled in the art will understand that the computer device described herein is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0129] Computer devices can include desktop computers, laptops, handheld computers, and cloud servers. These devices allow for human-computer interaction with users through keyboards, mice, remote controls, touchpads, or voice-activated devices.

[0130] The memory 710 includes at least one type of readable storage medium, including non-volatile memory or volatile memory, such as flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. RAM may include static RAM or dynamic RAM. In some embodiments, the memory 710 may be an internal storage unit of a computer device, such as the hard disk or RAM of the computer device. In other embodiments, the memory 710 may also be an external storage device of the computer device, such as a plug-in hard drive, SmartMediaCard (SMC), SecureDigital (SD) card, or FlashCard. Of course, the memory 710 may include both internal and external storage units of the computer device. In this embodiment, the memory 710 is typically used to store the operating system and various application software installed on the computer device, such as the program code of the methods described above. Furthermore, the memory 710 may also be used to temporarily store various types of data that have been output or will be output.

[0131] The processor 720 is typically used to perform the overall operation of a computer device. In this embodiment, the memory 710 is used to store program code or instructions, including computer operation instructions. The processor 720 is used to execute the program code or instructions stored in the memory 710 or to process data, such as program code that runs the methods described above.

[0132] In this article, the bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus system can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0133] Another embodiment of this application also provides a computer-readable medium, which may be a computer-readable signal medium or a computer-readable medium. A processor in a computer reads computer-readable program code stored in the computer-readable medium, enabling the processor to execute the functional actions specified in each step or combination of steps in the above method; and to generate means for implementing the functional actions specified in each block or combination of blocks in the block diagram.

[0134] Computer-readable media include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared memory or semiconductor systems, devices or apparatuses, or any suitable combination thereof, wherein the memory is used to store program code or instructions, the program code including computer operation instructions, and the processor is used to execute the program code or instructions of the above-described methods stored in the memory.

[0135] The definitions of memory and processor can be found in the description of the foregoing computer device embodiments, and will not be repeated here.

[0136] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units 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 apparatuses or units may be electrical, mechanical, or other forms.

[0137] In the various embodiments of this application, the functional units or modules can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0138] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0139] Unless otherwise expressly indicated by the context, the singular form of words used herein and in the appended claims includes the plural form, and vice versa. Thus, when referring to the singular, the plural form of the corresponding term is generally included. Similarly, the terms “comprising” and “including” shall be interpreted as including rather than exclusively. Likewise, the terms “including” and “or” shall be interpreted as including unless such interpretation is expressly prohibited herein. Where the term “example” is used herein, particularly when it follows a set of terms, the “example” is merely exemplary and illustrative and should not be considered exclusive or extensive.

[0140] Further aspects and scope of adaptation become apparent from the description provided herein. It should be understood that various aspects of this application may be implemented individually or in combination with one or more other aspects. It should also be understood that the descriptions and specific embodiments herein are for illustrative purposes only and are not intended to limit the scope of this application.

[0141] Several embodiments of this disclosure have been described in detail above. However, it is obvious that those skilled in the art can make various modifications and variations to the embodiments of this disclosure without departing from the spirit and scope of this disclosure. The scope of protection of this disclosure is defined by the appended claims.

[0142] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0143] Obviously, those skilled in the art should understand that the various units or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device, or fabricating them separately as individual integrated circuit modules, or fabricating multiple modules or steps into a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0144] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. 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.

[0145] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0146] Obviously, those skilled in the art should understand that the various units or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device, or fabricating them separately as individual integrated circuit modules, or fabricating multiple modules or steps into a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0147] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. 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. An interface request parameter integration method, characterized in that, The application comprises the following steps: When the business layer initiates an API request, the adaptation layer parses the corresponding protocol type according to the API request, and routes to the corresponding request interceptor according to the protocol type; The request interceptor receives and parses the API request, extracts the HTTP request header, uniform resource locator URL and operation behavior parameter, and transmits the URL and operation behavior parameter to the policy factory; The policy factory obtains the corresponding policy class from the policy registry center by querying the policy mapping table according to the received URL and operation behavior parameter; The policy class is instantiated to generate a policy instance and return it to the request interceptor; The request interceptor calls the parameter generation interface of the policy instance to generate a standardized parameter object; The standardized parameter object is dynamically injected into the HTTP request header to form a new API request and forward it to the backend interface.

2. The method of claim 1, wherein, The policy mapping table contains mapping records of the mapping relationship between the URL, the operation behavior parameter and the policy class.

3. The method of claim 1, wherein, The policy mapping table supports a two-dimensional matching mechanism: The first dimension performs path matching according to the URL; The second dimension performs enumeration value matching according to the operation behavior parameter.

4. The method of claim 1, wherein, The step of obtaining the corresponding policy class from the policy registry center by querying the policy mapping table comprises the following steps: According to the URL, the first dimension is matched, and if the matching result is direct mapping, the policy class in the mapping record is directly read; If the matching result is behavior mapping, the second dimension is matched according to the operation behavior parameter; If the second dimension matching is successful, the policy class in the mapping record is read; If the policy class corresponding to the URL and operation behavior parameter is not found, a degradation scheme is executed to inject predefined default parameters or basic parameters for the API request.

5. The method of claim 1, wherein, Before the step of dynamically injecting the standardized parameter object into the HTTP request header, the following steps are further included: Through the parameter verification engine, the validity of the standardized parameter object is verified; If the verification fails, the API request is intercepted and parameter verification exception is prompted; If the verification is passed, the subsequent parameter injection step is executed.

6. The method of claim 1, wherein, The step of dynamically injecting the standardized parameter object into the HTTP request header comprises the following steps: According to the HTTP method type of the API request, the standardized parameter object is injected differently; For GET request, the standardized parameter object is injected into the query string; For POST, PUT, PATCH request, the standardized parameter object is injected into the request body or request header.

7. The method of claim 1, wherein, Further comprising: The policy registry center provides a dynamic registration interface mechanism for the policy mapping table; The policy registry center provides a dynamic deregistration interface mechanism for the policy mapping table; The policy registry center supports dynamic updating of the policy mapping table during system operation.

8. An interface request parameter integration apparatus, characterized by, The application comprises the following steps: A routing module is configured to parse the corresponding protocol type according to the API request when the business layer initiates an API request, and route to the corresponding request interceptor according to the protocol type; An intercepting parsing module is configured to receive and parse the API request, extract HTTP request headers, a URL, and operation behavior parameters therefrom, and transmit the URL and operation behavior parameters to a policy factory; A policy querying module is configured to acquire a corresponding policy class from a policy registry center by querying a policy mapping table according to the received URL and operation behavior parameters; A policy instantiation module is configured to perform instantiation on the policy class, generate a policy instance, and return the policy instance to the request interceptor; A parameter generation module is configured to generate a standardized parameter object by calling a parameter generation interface of the policy instance; A parameter injection module is configured to dynamically inject the standardized parameter object into the HTTP request headers, form a new API request, and forward the new API request to a backend interface.

9. A computer device, comprising: comprising: one or more processors; a memory device for storing one or more programs, when the one or more programs are executed by the one or more processors, the one or more processors implement the method of any one of claims 1-7.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the method of any one of claims 1-7.

Images