API request processing method and device, electronic equipment and storage medium

Abstract

The invention provides an API request processing method and device, electronic equipment and a storage medium, and the method comprises the steps: creating a route, integrating a verifier in the route, and enabling the verifier to predefine a structure and a rule of an API request; generating a configuration file according to the configuration parameters selected by the user and a predefined template; the configuration file defines a routing rule and message processing logic; according to the configuration file, generating a service application and constructing a corresponding API interface to receive an API request; and if the received API request meets the predefined structure and rule, forwarding the API request to the service application by the router according to the configuration file. Therefore, the learning cost of a user for learning a new technology stack and the workload of manual coding can be reduced, the docking process between different systems is simplified, the overall docking efficiency is improved, and the system can quickly adapt to service changes and technology evolution, improve expandability and maintainability and support more service scenes and extended functions.

Description

Technical Field

[0001] One or more embodiments of the present disclosure relate to the technical field of API request processing, and in particular, to a method, device, electronic device, and storage medium for processing an API request. Background Art

[0002] In existing business systems, when it is necessary to connect with other business systems, hard coding is usually used. Specifically, developers need to manually write code to handle the communication protocols, data formats, and interface specifications of different systems. For example, if a business system needs to connect with another business system that uses a different technology stack, the developer must understand the interface documentation of the other system in detail and then write specific API (Application Programming Interface) request response processing logic.

[0003] However, this hard-coded docking method has several significant disadvantages. First, the development cost is high. Since different systems use different technology stacks and interface specifications, developers need to spend a lot of time learning and understanding these differences, which not only prolongs the development cycle but also increases project risks. Second, the maintainability is poor. Once the interface or data structure of the docking system changes, the docking code needs to be modified and tested again, which cannot quickly adapt to business changes and technological evolution, limiting the scalability and maintainability of the system. Therefore, the existing docking method seems to be unable to cope with complex and changing business needs, and a more efficient and flexible solution is urgently needed. Summary of the invention

[0004] In order to solve the technical problems of high development cost, poor system scalability and maintainability caused by the hard-coded docking mode when a business system is docked with another business system using a different technology stack, the present disclosure provides a method for processing an API request, the method comprising:

[0005] Create routes and integrate validators in the created routes. The validators predefine the structure and rules of API requests.

[0006] Generate a configuration file based on the configuration parameters selected by the user and the predefined template; wherein the configuration file defines the routing rules and message processing logic;

[0007] Generate a business application and build a corresponding API interface according to the configuration file to receive API requests;

[0008] If the received API request meets the structure and rules predefined by the validator, the router forwards the API request to the business application according to the configuration file.

[0009] Optionally, the predefined template is written by a Freemarker template engine according to the abstracted message processing logic of the business application; and generating a configuration file according to the configuration parameters selected by the user and the predefined template includes:

[0010] Receive configuration parameters entered by the user in the front-end configuration interface and the selected predefined template;

[0011] The received configuration parameters are passed to the Freemarker template engine, so that the Freemarker template engine injects the configuration parameters into the predefined template to generate the configuration file.

[0012] Optionally, a validator is integrated into the created route, and the validator predefines the structure and rules of the API request, including:

[0013] Load a rule validation file, which defines the structure and rules of the API request;

[0014] Create a validator based on the validation library, wherein the validator is used to verify whether the API request meets the predefined structure and rules;

[0015] The validator is integrated in the created route, and the rule validation file is referenced, so that the validator reads the rule validation file and verifies the API request based on the structure and rules of the defined API request.

[0016] Optionally, before loading the rule verification file, the method further includes:

[0017] Receive the structure and rules of the API request entered by the user on the front-end configuration interface;

[0018] Convert the structure and rules of the received API request into a rule verification file, and store the converted rule verification file in the file system;

[0019] The structure and rules of the API request include the request path, method, parameters and return value of the API request.

[0020] Optionally, there are multiple generated business applications, and the method further includes:

[0021] Divide the generated business applications into different clusters, each of which contains an independent configuration center and service center;

[0022] Uploading the generated business application configuration information to the configuration center for storage and management;

[0023] Registering the generated business functions of the business application to the service center for storage and management;

[0024] If it is detected that the business application has changed, the service center is notified based on a long polling mechanism so that the service center updates the service list.

[0025] Optionally, the method further includes:

[0026] Receive operations on the generated API interface input by the user in the front-end configuration interface to manage the life cycle of the API interface;

[0027] The operation on the API interface includes at least one of the following: starting the API interface, stopping the API interface, and updating the API interface.

[0028] Optionally, the routing orchestrates a plurality of processors through a pipeline so that the plurality of processors perform processing operations in sequence to form a message processing pipeline;

[0029] The plurality of processors include at least one of the following:

[0030] Time component, message queue and HTTP component.

[0031] The present disclosure also provides a device for processing an API request, the device comprising:

[0032] A creation unit, used for creating a route and integrating a validator in the created route, wherein the validator predefines a structure and rules of an API request;

[0033] A first generating unit, configured to generate a configuration file according to configuration parameters selected by a user and a predefined template; wherein the configuration file defines routing rules and message processing logic;

[0034] A second generating unit is used to generate a business application and construct a corresponding API interface according to the configuration file to receive an API request;

[0035] A forwarding unit is used to enable the router to forward the API request to the business application according to the configuration file if the received API request meets the structure and rules predefined by the validator.

[0036] The present disclosure also provides an electronic device, comprising a communication interface, a processor, a memory and a bus, wherein the communication interface, the processor and the memory are interconnected via the bus;

[0037] The memory stores machine-readable instructions, and the processor executes the above method by calling the machine-readable instructions.

[0038] The present disclosure also provides a machine-readable storage medium, wherein the machine-readable storage medium stores machine-readable instructions, and when the machine-readable instructions are called and executed by a processor, the above method is implemented.

[0039] Through the embodiments of the present disclosure, first, a route is created, and a validator is integrated in the created route, wherein the validator predefines the structure and rules of the API request; then, a configuration file is generated according to the configuration parameters selected by the user and the predefined template; wherein the configuration file defines the routing rules and message processing logic; further, according to the configuration file, a business application is generated and a corresponding API interface is constructed to receive the API request; finally, if the received API request meets the structure and rules predefined by the validator, the route forwards the API request to the business application according to the configuration file.

[0040] Through the above methods, the technical solution of the present invention, on the one hand, allows users to select predefined templates, so that users can easily select templates of the technology types they are familiar with, and generate configuration files in domain-specific languages ​​based on the templates to automatically implement business application construction and API interface generation processes, thereby reducing the learning cost of users learning new technology stacks and the workload of manual coding, simplifying the docking process between different systems, and improving the overall docking efficiency; on the other hand, only the configuration parameters and the structure and rules of predefined API requests need to be modified to adapt to business changes, without the need to re-modify and test the complete docking code, so that the system can quickly adapt to business changes and technological evolution, improve scalability and maintainability, and support more business scenarios and extended functions. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0042] Figure 1 It is a schematic diagram of a method for a business application to process an API request, shown in an exemplary embodiment;

[0043] Figure 2 is a flowchart of a method for processing an API request shown in an exemplary embodiment;

[0044] Figure 3 is a schematic diagram of an Apache Camel architecture shown in an exemplary embodiment;

[0045] Figure 4 It is a technical architecture diagram of a SMP (Service Management Platform) integration platform shown in an exemplary embodiment;

[0046] Figure 5 It is a schematic diagram of a dynamic refresh mechanism of a microservice architecture shown in an exemplary embodiment;

[0047] Figure 6 is a hardware structure diagram of an electronic device shown in an exemplary embodiment;

[0048] Figure 7 It is a block diagram of a device for processing an API request, shown in an exemplary embodiment. DETAILED DESCRIPTION

[0049] In order to enable those skilled in the art to better understand the technical solutions in the present disclosure, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present disclosure.

[0050] It should be noted that: in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this disclosure. In some other embodiments, the steps included in the method may be more or less than those described in this disclosure. In addition, a single step described in this disclosure may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this disclosure may also be combined into a single step for description in other embodiments.

[0051] In existing business systems, when it is necessary to connect with other business systems, hard coding is usually used. Specifically, developers need to manually write code to handle the communication protocols, data formats, and interface specifications of different systems. For example, if a business system needs to connect with another business system that uses a different technology stack, the developer must understand the interface documentation of the other system in detail and then write specific API (Application Programming Interface) request response processing logic.

[0052] However, this hard-coded docking method has several significant disadvantages. First, the development cost is high. Since different systems use different technology stacks and interface specifications, developers need to spend a lot of time learning and understanding these differences, which not only prolongs the development cycle but also increases project risks. Second, the maintainability is poor. Once the interface or data structure of the other system changes, the docking code needs to be modified and tested again, which cannot quickly adapt to business changes and technological evolution, limiting the scalability and maintainability of the system. Therefore, the existing docking method seems to be unable to cope with complex and changing business needs, and a more efficient and flexible solution is urgently needed.

[0053] In view of this, the present disclosure aims to propose a technical solution to simplify the application system docking process and improve the scalability of the application system.

[0054] The technical solution first creates a route through the Apache Camel framework and integrates a validator in the created route, wherein the validator predefines the structure and rules of the API request; then, a configuration file is generated according to the configuration parameters selected by the user and the predefined template; wherein the configuration file defines the routing rules and message processing logic; further, according to the configuration file, a business application is generated and a corresponding API interface is constructed to receive the API request; finally, if the received API request meets the structure and rules predefined by the validator, the route forwards the API request to the business application according to the configuration file.

[0055] For example, see Figure 1 , Figure 1 FIG. 1 is a schematic diagram of a method for a business application to process an API request according to an exemplary embodiment. Figure 1As shown in the figure, the platform allows business personnel to create new business applications by selecting different templates and cluster deployments. At the same time, platform personnel are responsible for writing and managing these templates, such as authentication templates (auth 2.0) and signature templates. Once the business application is created, it will be published to the gateway for access in a standard way on Android, Mac, PC, and Server. The process generally includes the following four steps: Step 1: Create routes and integrate validators. Platform personnel will first create routes (such as those based on the Apache Camel open source integration framework) and integrate a JSON Schema validator in the routes. This validator predefines the structure and rules of API requests, such as HTTP (Hypertext Transfer Protocol) methods, URL (Uniform Resource Locator) paths, request header information, request body format, etc. Step 2: Generate a configuration file based on configuration parameters and templates. When the business personnel select a specific template (such as the auth 2.0 template) and enter the necessary configuration parameters (such as API key, validity period, etc.) through the interface provided by the platform, the system will automatically generate a configuration file (such as Camel DSL). This configuration file contains routing rules and message processing logic, which guides subsequent business applications on how to handle received API requests. Step 3: Generate business applications and build API interfaces. According to the configuration files generated in the above steps, the system will automatically build a new business application and create a corresponding API interface for the application. The application and the corresponding interface will be published to the specified cluster environment (such as cluster A, cluster B, etc.), waiting for API requests from clients. Step 4: Process API requests. Clients (such as Android, Mac, PC, and Server) send API requests to the gateway in a standard way. After receiving the request, the gateway will first pass it to the previously created route. The route checks whether the request conforms to the preset structure and rules based on the built-in validator. If the request is qualified, the request will be forwarded to the business application for processing according to the instructions in the configuration file.

[0056] For example, a business person wants to create a new application that connects to WeChat for Business. He selects the auth 2.0 template and sets the relevant configuration parameters. Subsequently, the system automatically generates a configuration file containing routing rules and message processing logic. Then, the system creates a new application and its API interface based on this configuration file, and deploys the new application and its API interface to cluster C. Finally, when the WeChat for Business client sends an API request, the API request will be captured by the gateway and verified for legitimacy through routing. After the verification is passed, the API request will be forwarded to the new application in cluster C for processing.

[0057] Through the above methods, the technical solution of the present invention, on the one hand, allows users to select predefined templates, so that users can easily select templates of the technology types they are familiar with, and generate configuration files in domain-specific languages ​​based on the templates to automatically implement business application construction and API interface generation processes, thereby reducing the learning cost of users learning new technology stacks and the workload of manual coding, simplifying the docking process between different systems, and improving the overall docking efficiency; on the other hand, only the configuration parameters and the structure and rules of predefined API requests need to be modified to adapt to business changes, without the need to re-modify and test the complete docking code, so that the system can quickly adapt to business changes and technological evolution, improve scalability and maintainability, and support more business scenarios and extended functions.

[0058] It should be noted that the integration framework and configuration files mentioned in the present disclosure are not limited to the Apache Camel framework and the JSON Schema validator. Other integration frameworks and configuration files, such as the Spring Integration framework and the XML Schema validator, are also applicable to the technical solution of the present disclosure.

[0059] The following describes the present disclosure by taking the Apache Camel framework and the JSON Schema validator as examples through specific embodiments and in combination with specific application scenarios.

[0060] See also Figure 2 , Figure 2 This is a flowchart of a method for processing an API request according to an exemplary embodiment. The method may perform the following steps:

[0061] Step 202: Create a route, and integrate a validator into the created route, wherein the validator predefines the structure and rules of the API request.

[0062] See also Figure 3 , Figure 3 FIG. 1 is a schematic diagram of an Apache Camel architecture shown in an exemplary embodiment. Figure 3As shown, Camel Context is a core component of the Apache Camel framework, which contains all defined routes and processor instances. Here, we can see that multiple routes have been created (Route 1, Route 2...), each of which has its specific functions, such as reading data from the file system, filtering data, processing data using XPath expressions, etc. The routing engine is the core of the entire architecture, responsible for managing and executing routing rules, connecting endpoints and processors through routing. Endpoints are the entry and exit of data, such as the file system (FILE), JMS (Java Message Service, Java Message Service) and HTTP, etc. These endpoints will be used to receive API requests. Processors are components that perform specific tasks, such as message filtering, content routing, conversion, mediation, compression, verification and integration. In this embodiment, the validator is a processor. In the created route, a validator needs to be integrated, which predefines the structure and rules of the API request. This can be done by using the built-in components of the Apache Camel framework.

[0063] For example, create a route through the Apache Camel framework that listens to requests from an HTTP endpoint. This route integrates a JSON Schema validator that uses the OAuth 2.0 protocol to verify the legitimacy of API requests. The validator predefines the structure and rules of the API request and checks whether the Authorization field in the request header of the API request contains the correct Bearer token.

[0064] Among them, in the Apache Camel open source integration framework, routing is the core concept of message processing, which defines the flow path of messages from the input endpoint to the output endpoint. Routing can contain multiple processors, which process messages in sequence. In this embodiment, integrating the validator in the created route can be completed by using the built-in components of the Apache Camel framework. The JSON Schema validator is a tool for verifying whether JSON data conforms to predefined structures and rules. In Apache Camel, it can be integrated into the route as a processor to verify the JSON data of the incoming message. OAuth 2.0 is an industry-standard protocol for authorization, which allows third-party applications to access protected resources with user authorization. OAuth 2.0 is used to verify the legitimacy of API requests. In the HTTP request header, the Authorization field is used to carry authentication information, such as a Bearer token. A Bearer token is a token type used for the OAuth 2.0 authorization process, which is usually a long string used to prove the identity and access rights of the holder, allowing the holder to access specific resources.

[0065] Step 204: Generate a configuration file based on the configuration parameters selected by the user and the predefined template; wherein the configuration file defines routing rules and message processing logic.

[0066] For example, in the Apache Camel framework, a Camel DSL configuration file is generated based on the configuration parameters selected by the user (e.g., API key, client ID, redirect URI, etc.) and the predefined OAuth 2.0 template. This configuration file defines the routing rules and message processing logic, including how to parse HTTP requests, perform OAuth 2.0 authentication processes, and how to handle successfully authenticated requests.

[0067] Among them, the template is a set of preset configuration rules or code structures used to generate customized configuration files. In this embodiment, the template may include preset rules for the OAuth 2.0 authentication process. The Camel DSL configuration file is a DSL (Domain-Specific Language) file of the ApacheCamel integration framework, which is used to define routing rules and message processing logic. In Apache Camel, routing rules define how messages flow in the system, including the source, destination, and conversion and processing of messages in the system. Message processing logic refers to a series of steps for how messages are processed in the system, including parsing, verification, conversion, etc. The OAuth 2.0 template is a predefined template for implementing the OAuth 2.0 authentication process. OAuth 2.0 is an open standard for authorization that allows users to delegate access rights to third-party applications.

[0068] Step 206: Generate a business application based on the configuration file and build a corresponding API interface to receive an API request.

[0069] For example, in the Apache Camel framework, using the above Camel DSL configuration file, a business application is built that has the ability to handle authenticated requests. At the same time, a matching API interface is also built, which exposes a series of protected resources that can only be accessed by API requests authenticated by OAuth 2.0.

[0070] Among them, the Camel DSL configuration file refers to a file used to store various parameters and settings required for the system to run. It can be in XML, JSON or other formats. The Camel DSL configuration file allows the system to adjust its behavior according to different environments and requirements without modifying the source code. Business applications are the part that actually completes the business logic, such as processing orders, calculating bills, analyzing data, and so on. Business applications are usually the core part of the software and are responsible for performing the main functions. Apache Camel is an open source enterprise-level integration framework that provides a variety of DSLs to define routing rules and message processing logic. CamelDSL is one of them. It uses Java syntax style and is designed for defining enterprise integration patterns.

[0071] Step 208: If the received API request meets the structure and rules predefined by the validator, the router forwards the API request to the business application according to the configuration file.

[0072] For example, when the API interface receives a request, it first calls the validator to check whether the request carries a valid OAuth 2.0 credential. If the request meets the structure and rules predefined by the validator (that is, the request header contains a valid Bearer token), the router forwards the request to the business application for processing according to the instructions in the configuration file. Otherwise, the request will be rejected and an appropriate error message will be returned.

[0073] Among them, the predefined structure and rules refer to the specific requirements that API requests should comply with, such as the request header of the API request must contain a specific key-value pair, and the request body must be organized in a certain format. These rules are usually clearly listed in the API documentation for developers to follow. Business application refers to the part that executes core business logic, such as processing orders, updating inventory status, etc. In the API architecture, business applications are usually located behind the API gateway and only process requests that have been verified and routed. If the request fails to pass the verification, the API should return an appropriate error response to inform the client what went wrong. The error message usually includes an HTTP status code (such as 401Unauthorized, 403Forbidden, etc.) and a brief description.

[0074] In this embodiment, by introducing a strict verification mechanism, it is ensured that only requests carrying valid authentication information can access sensitive business resources, thereby strengthening resource authority management and improving the overall security of the system.

[0075] In one embodiment shown, the predefined template is written by a Freemarker template engine based on the abstracted message processing logic of the business application; generating a configuration file based on the configuration parameters selected by the user and the predefined template includes: receiving the configuration parameters input by the user in the front-end configuration interface, and the selected predefined template; passing the received configuration parameters to the Freemarker template engine, so that the Freemarker template engine injects the configuration parameters into the predefined template to generate the configuration file.

[0076] For example, an e-commerce platform needs to process user order creation requests. To ensure that only authenticated users can create orders, we use OAuth 2.0 for user authentication. The platform staff used the Freemarker template engine to write a predefined template, which is used to generate the Camel DSL configuration file of the Apache Camel framework. The template contains the logic for processing order creation requests, such as parsing the request body, performing OAuth 2.0 authentication checks, calling order services, etc. Then, the business staff enters the necessary configuration parameters in the front-end configuration interface, such as API key, client ID, redirect URI, etc., and selects the predefined OAuth 2.0 template. The Apache Camel framework passes the configuration parameters entered by the business staff to the Freemarker template engine, which injects these parameters into the predefined template and generates the Camel DSL configuration file. This configuration file defines the routing rules and message processing logic, including how to parse HTTP requests, perform OAuth2.0 authentication processes, and how to handle requests that are successfully authenticated.

[0077] Among them, abstract business logic refers to the logic extracted from the actual business process, which is used to guide how the software responds to specific business scenarios, such as order creation, user authentication, etc. Message processing logic refers to how the software system handles received messages, including parsing, verification, routing, etc. The front-end configuration interface is a user interface that allows users to enter or select configuration parameters, which are then used to generate configuration files. After the Freemarker template engine receives these parameters, it will start to fill in the predefined template. It will traverse each parameter, find the corresponding position in the template, and replace the placeholder. Finally, the filled template becomes a complete configuration file. This configuration file contains all the necessary information to guide the back-end system to correctly execute the OAuth 2.0 authentication process.

[0078] In this embodiment, the Freemarker template engine is used to write predefined templates according to the abstracted message processing logic of the business application, so that the configuration file can be quickly generated. This reduces the time and complexity of manually writing and adjusting the configuration file, improves development efficiency, and ensures the consistency of the structure and format of all generated configuration files, which helps to reduce the configuration inconsistency caused by human errors and facilitates subsequent maintenance and upgrades.

[0079] In one embodiment shown, a validator is integrated in the created route, and the validator predefines the structure and rules of the API request, including: loading a rule verification file, and the rule verification file defines the structure and rules of the API request; creating a validator according to a verification library, and the validator is used to verify whether the API request satisfies the predefined structure and rules; integrating the validator in the created route, and referencing the rule verification file, so that the validator reads the rule verification file and verifies the API request based on the defined structure and rules of the API request.

[0080] For example, we are developing an e-commerce platform that needs to process user order creation requests. In order to ensure the accuracy and security of the data, we decided to validate the structure and rules of the API request. At the same time, we use OAuth 2.0 to ensure that only authenticated users can create orders. First, load the rule validation file JSONSchema file, which will accurately specify the structure and content of the order creation request. For example, for an order creation request, the JSON Schema file may specify that the request body must be an object, including fields such as "product ID", "quantity", and "delivery address", and these fields cannot be empty. Then, you need to use the JSON Schema validation library to create a validator. The role of the validator is to check each order creation request according to the JSON Schema file just loaded to see if they comply with the specified structure and rules. Finally, integrate the validator in the API route that handles the order creation request and reference the JSON Schema file in the validator's properties. Whenever a new order creation request arrives, the validator will read the JSON Schema file and validate the request according to the regulations in it. If the request is not compliant, the validator will prevent the request from being processed further and return an error message to the client. On the contrary, if the request passes the verification, it will enter the next processing step, such as creating an order, notifying the warehouse to prepare goods, etc.

[0081] Among them, JSON Schema validation library is a kind of software library specially used for parsing and validating JSON Schema. Common libraries include Ajv, Zod, Joi, etc. These libraries can read JSON Schema files and create validators based on them. The main task of the validator is to check whether the incoming JSON data conforms to the predefined schema at runtime. Integrating validators in routes is to add validation logic to the path of processing order creation requests. This usually involves defining a middleware or decorator in the backend framework so that all requests arriving at the path must first be checked by the validator to determine the validity of the request. This usually involves inserting a piece of code before the route processing function to instantiate the validator and pass the request data to it. If the validation fails, an error response can be returned directly without continuing the subsequent processing flow. In the route configuration, the JSON Schema file is referenced by setting the properties of the validator, so that the route implements the JSON Schema validation function by calling a specific file (i.e., the JSON Schema file) on the class path.

[0082] In this embodiment, in this way, Apache Camel can dynamically verify API requests according to the JSON Schema file without modifying the code, ensuring that the API requests processed by subsequent business applications are legal and valid. This integration method improves the flexibility and maintainability of the system, allowing the system to quickly adapt to changes in business needs.

[0083] In one embodiment shown, before the loading of the rule verification file, the method also includes: receiving the structure and rules of the API request input by the user on the front-end configuration interface; converting the received structure and rules of the API request into a rule verification file, and storing the converted rule verification file in the file system; wherein the structure and rules of the API request include the request path, method, parameters and return value of the API request.

[0084] For example, in an e-commerce platform, an administrator wants to adjust the rules for order creation API requests. He can set the following in the front-end management interface: the order creation request must contain the product ID (range between 1 and 999), the purchase quantity (minimum 1, maximum 100), the customer's name (string, maximum 50 characters), and the delivery address (string, maximum 100 characters). After the administrator submits these rules, the backend automatically converts this information into the corresponding rule verification JSON Schema file and saves it in the server's file system.

[0085] When a user tries to create a new order, their API request is first routed to an API endpoint with a validator. The validator loads the previously saved JSON Schema file and checks the data in the request according to the rules it defines. For example, if the product ID is not provided in the API request, or the quantity exceeds the maximum allowed value, the validator will intercept the API request and provide an error message to the user, prompting them to correct the request and try again. An API is a set of rules that define how different software components communicate with each other. In web development, APIs are often presented as a set of HTTP requests and responses, and users' API requests are usually HTTP requests from clients.

[0086] In this embodiment, the administrator can intuitively set and adjust the structure and rules of API requests through the front-end configuration interface without directly editing the code or complex configuration files. This approach lowers the technical threshold and allows non-technical personnel to participate in the management and adjustment of API rules.

[0087] In one embodiment shown, there are multiple business applications generated, and the method also includes: dividing the generated business applications into different clusters, each cluster including an independent configuration center and a service center; uploading the configuration information of the generated business applications to the configuration center for storage and management; registering the business functions of the generated business applications to the service center for storage and management; if a change is detected in the business application, notifying the service center based on a long polling mechanism so that the service center updates the service list.

[0088] See also Figure 4 , Figure 4 FIG. 1 is a schematic diagram of a technical architecture of a SMP (Service Management Platform) shown in an exemplary embodiment. Figure 4As shown, the service subscriber accesses the system through a Web (World Wide Web, Internet) page, a mobile terminal or a PC (Personal Computer) terminal, all of which serve as traffic entrances. The configuration center of business application A and business application B is responsible for storing and managing the structure and rules of API requests, including request paths, methods, parameters and return values. The gateway component is responsible for routing maintenance to ensure that API requests can be correctly forwarded to the corresponding services. The SMP service governance component is responsible for service publishing, routing maintenance and API lifecycle management. The SMP service governance component interacts with the configuration center to obtain configuration information, and receives access requests from the SMP front-end component from service subscribers and service providers, and routes them to the appropriate service governance component. The SMP front-end page has two functions: one is to define the structure and rules of API requests for subsequent API request verification; the other is to provide the SMP service governance management platform with control over the API interface lifecycle.

[0089] For example, an online education platform consists of multiple microservices, including student management, teacher management, etc. These microservices constitute business applications A and B. According to different business fields, business applications A and B are divided into two different clusters, each with its own configuration center and service center, so as to isolate the configuration and business logic between different clusters and improve the maintainability and scalability of the system. For business applications in each cluster, their configuration information will be uploaded to their respective configuration centers for storage and management. When the configuration of a business application needs to be modified, it only needs to be operated in the corresponding configuration center without changing the actual application code. At the same time, the functions of these business applications will be registered in their respective service centers. Doing so can help us centrally manage the information of all services and facilitate query and call. Finally, if a business application is found to have changed, such as adding a new function or fixing a defect, the long polling mechanism will be used to notify the service center so that the service center can be informed of the latest situation in a timely manner and update its service list to ensure that users can use the latest version of the service. The service list usually contains the service name (i.e., the unique identifier of each service, used to distinguish different services), service description (i.e., a brief description of the service function and purpose), service network address (usually including IP address and port number, used to locate the service), service status (indicating whether the service is currently available, which may include running, stopped, maintenance, etc.), service version (i.e., service version information, used to distinguish different iterations of the service), etc. Among them, in the microservice architecture, a cluster is a group of related services, which are usually deployed together, sharing configuration and service center to achieve business logic isolation and system scalability. The configuration center is a system that centrally stores and manages service configuration information, such as the structure and rules of API requests, including request paths, methods, parameters, and return values. The service center is responsible for storing and managing the business logic and functions of the service system, and can handle the registration, discovery, and call of the service. Long polling is a service discovery mechanism, in which the client periodically sends requests to the service endpoint to obtain the latest service information or configuration updates. SMP is a service used to manage and monitor the microservice architecture. Long polling is a technology used to achieve real-time communication. In this embodiment, each business application will initiate an HTTP request to the service center to ask if there is any information that needs to be updated. Unlike traditional short polling, the service center will not reply to the request immediately. Instead, it will keep the connection open for a period of time (until new information is available to return or the preset timeout period is reached). If the state of the business application changes during this period (such as adding new features or fixing problems), the service center will immediately return the updated information to the business application as a response. Once the business application receives the response and processes the new information, it will immediately issue a new request and start the above process again.This mechanism enables the service center to learn the latest status of business applications in near real time without frequent polling, and update its service list accordingly. This helps ensure that users can always access the latest service version, while also reducing unnecessary network traffic and server load.

[0090] In this embodiment, the SMP service governance component provides a unified platform to manage and monitor the status and behavior of all services. The business applications of different services are divided into different clusters, and an independent configuration center and service center are configured for each cluster to achieve isolation of business logic. This design improves the maintainability and scalability of the system, so that services in different business areas can be deployed and managed independently. Through clustered deployment and redundant configuration, the stability and reliability of the system are improved. Even if a service fails, other services can still operate normally. In addition, this structure also makes the system easier to expand. For example, when new functions need to be added, new services can be added more conveniently without interfering with existing services.

[0091] In one embodiment shown, the method also includes: receiving operations on the generated API interface input by the user in the front-end configuration interface to manage the life cycle of the API interface; wherein the operations on the API interface include at least one of the following: starting the API interface, stopping the API interface, and updating the API interface.

[0092] For example, on an e-commerce platform based on OAuth 2.0 authentication, users can directly operate the life cycle of the API interface in the front-end configuration interface, including start, stop and update operations. Taking the order creation API interface as an example, users can clearly specify the functional parameters they need in the front-end configuration interface, such as payment method, delivery address and other details. After confirmation, the API interface can be quickly put into the actual operation environment to respond to customers' order creation requests immediately. At the same time, the system also gives users the right to flexibly adjust the status of the API interface. Whether it is temporary deactivation or subsequent upgrade, changes can be made in a timely manner according to business development needs.

[0093] The front end usually refers to the part that users can interact with directly, i.e., forms, buttons, and other elements on a web page. Users can configure and manage the API interface through a browser or other front-end tools in the front-end configuration interface. The life cycle of an API interface refers to the process from the creation to the destruction of an API interface. During this process, the API interface may go through different states, such as inactive, activated, paused, resumed, abandoned, etc.

[0094] In this embodiment, the front-end configuration interface provides an intuitive operation interface, and the life cycle management of all API interfaces is concentrated in the front-end configuration interface, which is convenient for centralized management and monitoring. Administrators can view and control the status of all APIs at a glance in the front-end configuration interface, and complete complex API interface management tasks by simply clicking a button or filling out a form. This process can simplify the management process of API status, lower the operating threshold, and is friendly to administrators. In one embodiment shown, the routing orchestrates several processors through a pipeline so that the several processors perform processing operations in sequence to form a message processing pipeline; wherein the several processors include at least one of the following: a time component, a message queue, and an HTTP component.

[0095] For example, on an e-commerce platform based on OAuth 2.0 authentication, when a user submits an order creation request, the routing mechanism within the system will come into play. Routing orchestrates several processors through pipelines so that the processors perform processing operations in sequence to form a message processing pipeline. On this pipeline, the time component is first verified to confirm whether the timestamp of the request is valid; next, the message will be passed to the message queue to wait for processing to prevent a large number of requests from causing system burden; finally, the HTTP component will send the request to the backend service for processing, thereby ensuring that each step can be executed in an orderly and efficient manner to complete the order creation process.

[0096] Among them, the pipeline is a special form of I / O redirection that allows half-duplex communication between two processes. Pipeline orchestration refers to connecting multiple processors in series to form a processing link so that data can flow from one processor to the next. In this embodiment, the processor is not a CPU in the hardware sense, but refers to a processing unit at the software level, which can be understood as a function or method that performs a specific task. The time component, message queue, and HTTP component are all different types of processors. The time component refers to the logic used to process time-related, such as checking whether the timestamp of the request is valid. The message queue is a middleware used to process messages asynchronously, allowing multiple producers to publish messages to the queue, and consumers can get messages from the queue for processing. The HTTP component refers to a module that processes HTTP requests and responses and is responsible for communicating with external services.

[0097] In this embodiment, a message processing pipeline is formed by arranging several processors through pipelines to ensure that each step can be executed in a predetermined order. This sequential execution ensures the correctness and consistency of the processing logic. Each processor (such as time component, message queue and HTTP component) is an independent module responsible for a specific task. This modular design makes the system more flexible, easy to maintain and expand. If a processor needs to be modified or replaced, only the part needs to be changed without affecting other components. The introduction of message queues can realize asynchronous processing, buffer requests, avoid the impact of a large number of requests on the system at once, and ensure that the system can run stably under high load conditions. In the technical solution disclosed in the present invention, in order to ensure that the API request processing logic and configuration information in the system are up to date, this embodiment designs a dynamic refresh mechanism.

[0098] See also Figure 5 , Figure 5 FIG. 1 is a schematic diagram of a dynamic refresh mechanism of a microservice architecture shown in an exemplary embodiment. Figure 5 As shown in the figure, the middleware domain contains the configuration center, which is responsible for storing and managing the API request processing logic and other configuration information of all services. It is the core of the synchronization process and ensures that all services and components can obtain the latest configuration data. The configuration center can be implemented by Nacos (Dynamic Naming and Configuration Service). The core of the microservice architecture is the service governance platform (i.e. SMP-service governance in the figure) and the integration platform (i.e. SMP-integration platform in the figure). The service governance platform is responsible for the entire life cycle of services and API interfaces, including regular services and connector services. The integration platform includes environmental dependencies, logical systems, connector capability construction, and API metadata; among them, the connector capability construction connects applications and databases, because there are two types of connectors: one is an application-level connector and the other is a database-level connector. Database-level connectors can dynamically build APIs based on database tables, such as adding new leads. Application-level connectors can dynamically build APIs based on applications, such as integrating enterprise WeChat login. The configuration information of the service governance platform (such as the creation, modification, and deletion of a service API interface) is maintained in the configuration center. The integration platform monitors changes in the configuration center. If there are any changes, it will synchronously obtain the updated service configuration from the service governance platform to ensure timely understanding of service status changes and take corresponding measures, such as updating the service catalog and adjusting service configuration.

[0099] In this embodiment, through this dynamic refresh mechanism, the system can update the configuration information in real time, ensuring that all components and services use the latest configuration information. This automatic synchronization mechanism reduces manual operation errors, improves the automation level of the system, enables the system to flexibly respond to business changes and needs, and reduces maintenance costs.

[0100] Corresponding to the embodiment of the method for processing an API request described above, the present disclosure also provides an embodiment of an apparatus for processing an API request.

[0101] See also Figure 6 , Figure 6 It is a hardware structure diagram of an electronic device shown in an exemplary embodiment. At the hardware level, the device includes a processor 602, an internal bus 604, a network interface 606, a memory 608, and a non-volatile memory 610, and of course may also include other required hardware. One or more embodiments of the present disclosure can be implemented based on software, such as the processor 602 reading the corresponding computer program from the non-volatile memory 610 into the memory 608 and then running it. Of course, in addition to the software implementation, one or more embodiments of the present disclosure do not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0102] See also Figure 7 , Figure 7 FIG. 7 is a block diagram of an API request processing device according to an exemplary embodiment. The API request processing device 700 can be applied to Figure 6 In the electronic device shown, the technical solution of the present disclosure is implemented; the device includes:

[0103] A creation unit 702, used to create a route and integrate a validator in the created route, wherein the validator predefines the structure and rules of the API request;

[0104] The first generating unit 704 is used to generate a configuration file according to the configuration parameters selected by the user and the predefined template; wherein the configuration file defines the routing rules and the message processing logic;

[0105] The second generating unit 706 is used to generate a business application and construct a corresponding API interface according to the configuration file to receive an API request;

[0106] The forwarding unit 708 is configured to enable the router to forward the API request to the business application according to the configuration file if the received API request meets the structure and rules predefined by the validator.

[0107] In some embodiments, the predefined template is written by a Freemarker template engine according to the abstracted message processing logic of the business application; the first generating unit includes:

[0108] A receiving subunit, used to receive configuration parameters input by a user in a front-end configuration interface, and a selected predefined template;

[0109] The transfer subunit is used to transfer the received configuration parameters to the Freemarker template engine, so that the Freemarker template engine injects the configuration parameters into the predefined template to generate the configuration file.

[0110] In some embodiments, the creating unit includes:

[0111] A loading subunit, used to load a rule verification file, wherein the rule verification file defines the structure and rules of an API request;

[0112] A subunit is created, which is used to create a validator according to a validation library, wherein the validator is used to verify whether an API request satisfies a predefined structure and rules;

[0113] The integration subunit is used to integrate the validator in the created route and reference the rule verification file so that the validator reads the rule verification file and verifies the API request based on the structure and rules of the defined API request.

[0114] In some embodiments, before loading the rule verification file, the apparatus further includes:

[0115] A first receiving unit, used to receive the structure and rules of the API request input by the user on the front-end configuration interface;

[0116] A conversion unit, used for converting the structure and rules of the received API request into a rule verification file, and storing the converted rule verification file in a file system;

[0117] The structure and rules of the API request include the request path, method, parameters and return value of the API request.

[0118] In some embodiments, the generated business application is multiple, and the device further includes:

[0119] The partitioning unit is used to divide the generated business applications into different clusters, each of which contains an independent configuration center and service center;

[0120] An uploading unit, used to upload the generated configuration information of the business application to the configuration center for storage and management;

[0121] A registration unit, used to register the generated business functions of the business application to the service center for storage and management;

[0122] A notification unit is used to notify the service center based on a long polling mechanism if a change is detected in the business application, so that the service center updates the service list.

[0123] In some embodiments, the apparatus further comprises:

[0124] A second receiving unit is used to receive the operation of the generated API interface input by the user in the front-end configuration interface to manage the life cycle of the API interface;

[0125] The operation on the API interface includes at least one of the following: starting the API interface, stopping the API interface, and updating the API interface.

[0126] In some embodiments, the routing orchestrates a plurality of processors through a pipeline so that the plurality of processors perform processing operations in sequence to form a message processing pipeline;

[0127] The plurality of processors include at least one of the following:

[0128] Time component, message queue and HTTP component.

[0129] The implementation process of the functions and effects of each unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0130] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can refer to the partial description of the method embodiments. The device embodiments described above are only schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the disclosed solution. A person of ordinary skill in the art can understand and implement it without paying any creative work.

[0131] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, a game console, a tablet computer, a wearable device or a combination of any of these devices.

[0132] In a typical configuration, a computer includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0133] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0134] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be used to store information by any method or technology. Information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include temporary computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0135] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0136] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0137] The above describes specific embodiments of the present disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0138] The terms used in one or more embodiments of the present disclosure are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of the present disclosure. The singular forms of "a", "said" and "the" used in one or more embodiments of the present disclosure and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0139] It should be understood that although the terms first, second, third, etc. may be used to describe various information in one or more embodiments of the present disclosure, these information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of the present disclosure, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determination".

[0140] The above description is only a preferred embodiment of one or more embodiments of the present disclosure and is not intended to limit one or more embodiments of the present disclosure. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of one or more embodiments of the present disclosure shall be included in the scope of protection of one or more embodiments of the present disclosure.

Claims

1. A method for processing an API request, characterized in that: The method comprises: Create routes and integrate validators in the created routes. The validators predefine the structure and rules of API requests. Generate a configuration file based on the configuration parameters selected by the user and the predefined template; wherein the configuration file defines the routing rules and message processing logic; Generate a business application and build a corresponding API interface according to the configuration file to receive API requests; If the received API request meets the structure and rules predefined by the validator, the router forwards the API request to the business application according to the configuration file.

2. The method according to claim 1, characterized in that The predefined template is written by the Freemarker template engine according to the abstracted message processing logic of the business application; The generating of the configuration file according to the configuration parameters selected by the user and the predefined template includes: Receive configuration parameters entered by the user in the front-end configuration interface and the selected predefined template; The received configuration parameters are passed to the Freemarker template engine, so that the Freemarker template engine injects the configuration parameters into the predefined template to generate the configuration file.

3. The method according to claim 1, characterized in that The validator is integrated into the created route, and the validator predefines the structure and rules of the API request, including: Load a rule validation file, which defines the structure and rules of the API request; Create a validator based on the validation library, wherein the validator is used to verify whether the API request meets the predefined structure and rules; The validator is integrated in the created route, and the rule validation file is referenced, so that the validator reads the rule validation file and verifies the API request based on the structure and rules of the defined API request.

4. The method according to claim 3, characterized in that Before loading the rule verification file, the method further includes: Receive the structure and rules of the API request entered by the user on the front-end configuration interface; Convert the structure and rules of the received API request into a rule verification file, and store the converted rule verification file in the file system; The structure and rules of the API request include the request path, method, parameters and return value of the API request.

5. The method according to claim 1, characterized in that There are multiple business applications generated, and the method further includes: Divide the generated business applications into different clusters, each of which contains an independent configuration center and service center; Uploading the generated business application configuration information to the configuration center for storage and management; Registering the generated business functions of the business application to the service center for storage and management; If it is detected that the business application has changed, the service center is notified based on a long polling mechanism so that the service center updates the service list.

6. The method according to claim 1, characterized in that The method further comprises: Receive operations on the generated API interface input by the user in the front-end configuration interface to manage the life cycle of the API interface; The operation on the API interface includes at least one of the following: starting the API interface, stopping the API interface, and updating the API interface.

7. The method according to claim 1, characterized in that The routing arranges a plurality of processors through pipelines so that the plurality of processors perform processing operations in sequence to form a message processing pipeline; The plurality of processors include at least one of the following: Time component, message queue and HTTP component.

8. A device for processing an API request, characterized in that: The device comprises: A creation unit, used for creating a route and integrating a validator in the created route, wherein the validator predefines a structure and rules of an API request; A first generating unit, configured to generate a configuration file according to configuration parameters selected by a user and a predefined template; wherein the configuration file defines routing rules and message processing logic; A second generating unit is used to generate a business application and construct a corresponding API interface according to the configuration file to receive an API request; A forwarding unit is used to enable the router to forward the API request to the business application according to the configuration file if the received API request meets the structure and rules predefined by the validator.

9. An electronic device, characterized in that: It includes a communication interface, a processor, a memory and a bus, wherein the communication interface, the processor and the memory are interconnected via the bus; The memory stores machine-readable instructions, and the processor executes the method according to any one of claims 1 to 7 by calling the machine-readable instructions.

10. A machine-readable storage medium, characterized in that: The machine-readable storage medium stores machine-readable instructions, and when the machine-readable instructions are called and executed by the processor, the method according to any one of claims 1 to 7 is implemented.

Images