A business execution method, device, equipment and storage medium

Abstract

The present application discloses a service execution method, apparatus, device, and storage medium, which is applied to a request-response service. The method includes: obtaining a request message of an interface call request sent by a target terminal based on a first service instruction; parsing the request path of the request message to determine the interface identifier of the back-end interface to be called; verifying the parameters to be verified in the request message based on a target verification configuration file corresponding to the interface identifier; if the verification passes, randomly generating dynamic message data based on the dynamic parameter generation rules contained in the target response configuration file corresponding to the interface identifier; assembling the fixed message data and dynamic message data contained in the target response configuration file to obtain a first response message; and sending the first response message to the target terminal so that the target terminal executes a second service instruction triggered by the first response message. The solution of the present application can ensure service security while flexibly and efficiently responding to interface requests.

Description

Technical Field

[0001] This application relates to the field of message processing technology, specifically to a business execution method, apparatus, device, and storage medium. Background Technology

[0002] In web development, situations may arise where the backend API that the frontend needs to call is unavailable, preventing the frontend's business logic from executing smoothly. The current common practice is to deploy a mock server and input API data according to the API's requirements. However, this method has limitations. It requires frontend developers to write relevant business logic code for the mock server, which has a high technical barrier. Furthermore, the simulated response messages are relatively fixed, lacking flexibility and failing to provide adequate security for the frontend's business logic. Summary of the Invention

[0003] This application provides a business execution method, apparatus, device, and storage medium, which can improve the ease of interface response simulation, lower the technical threshold, and flexibly and efficiently respond to interface requests while ensuring business security, thereby improving the smoothness of front-end business execution. The technical solution of this application is as follows:

[0004] On one hand, a business execution method is provided, the method being applied to a request-response service, the request-response service running on a target terminal, the method comprising:

[0005] Obtain the request message of the interface call request sent by the target terminal based on the first business instruction, the request message including: request path and request associated parameters;

[0006] The request path is parsed to determine the interface identifier of the backend interface to be called by the target terminal;

[0007] Based on the target verification configuration file, the parameters to be verified in the request associated parameters are verified to obtain the verification result. The target verification configuration file is the request verification configuration file corresponding to the interface identifier among a plurality of preset request verification configuration files.

[0008] If the verification result indicates that the request message has passed verification, dynamic message data is randomly generated based on the dynamic parameter generation rules contained in the target response configuration file. The target response configuration file is the response message configuration file corresponding to the interface identifier among a plurality of preset response message configuration files.

[0009] The fixed message data and the dynamic message data contained in the target response configuration file are assembled to obtain the first response message;

[0010] The first response message is sent to the target terminal so that the target terminal executes the second service instruction triggered based on the first response message.

[0011] On the other hand, a business execution apparatus is provided, the apparatus being applied to a request-response service, the request-response service running on a target terminal, the apparatus comprising:

[0012] The request message acquisition module is used to acquire the request message of the interface call request sent by the target terminal based on the first business instruction. The request message includes: request path and request associated parameters.

[0013] The request path parsing module is used to parse the request path and determine the interface identifier of the backend interface to be called by the target terminal.

[0014] The parameter verification module is used to verify the parameters to be verified in the request-associated parameters based on the target verification configuration file and obtain the verification result. The target verification configuration file is the request verification configuration file corresponding to the interface identifier among a plurality of preset request verification configuration files.

[0015] The dynamic data generation module is used to randomly generate dynamic message data based on the dynamic parameter generation rules contained in the target response configuration file when the verification result indicates that the verification of the request message has passed. The target response configuration file is the response message configuration file corresponding to the interface identifier among a plurality of preset response message configuration files.

[0016] The message assembly module is used to assemble the fixed message data and the dynamic message data contained in the target response configuration file to obtain the first response message;

[0017] The first response message sending module is used to send the first response message to the target terminal so that the target terminal executes the second service instruction triggered based on the first response message.

[0018] On the other hand, a business execution device is provided, the device including a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the business execution method as described above.

[0019] On the other hand, a computer-readable storage medium is provided, wherein at least one instruction or at least one program is stored therein, the at least one instruction or the at least one program being loaded and executed by a processor to implement the business execution method as described above.

[0020] The business execution method, apparatus, equipment, and storage medium provided in this application have the following technical effects:

[0021] Using the technical solution provided in this application, a simple configuration file and request-response service can be deployed on the front end. The request-response service can obtain the interface call request sent by the target terminal, determine the target configuration file corresponding to the interface identifier to be called by parsing the request path of the interface call request, generate the response message corresponding to the interface call request based on the configuration file to verify the correctness of the interface call request, and send the response message to the target terminal so that the target terminal can execute the corresponding business process based on the response message. This can improve the ease of interface response simulation, lower the technical threshold, and flexibly and efficiently respond to interface requests while ensuring the security of the business, thereby improving the smoothness of front-end business execution. Attached Figure Description

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

[0023] Figure 1 This is a flowchart illustrating a business execution method provided in an embodiment of this application;

[0024] Figure 2 This is a flowchart illustrating another business execution method provided in an embodiment of this application;

[0025] Figure 3 This is a flowchart illustrating a file configuration process provided in an embodiment of this application;

[0026] Figure 4 This is a flowchart illustrating an HTTP request-response scheme based on the above-described business execution method, provided in an embodiment of this application.

[0027] Figure 5 This is a schematic diagram of a business execution system provided in an embodiment of this application;

[0028] Figure 6 This is a schematic diagram of a business execution device provided in an embodiment of this application. Detailed Implementation

[0029] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0030] 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 so that the embodiments of this application described herein can be implemented in orders other than those illustrated or 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 server 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 devices.

[0031] To better understand the embodiments of this application, some technical terms involved in the embodiments of this application will be introduced below:

[0032] A mock server is a software tool or technology used to simulate the functionality and behavior of a real server. It creates a virtual server environment on a computer, allowing users to test, debug, and develop various applications and services without requiring an actual physical server.

[0033] A service is a standalone software component that provides a specific function or service. Services can be accessed over a network and interact with other components. Services can implement various functions, such as data storage, computation, communication, and authentication. By encapsulating these functions into services, code reuse and modularization can be achieved, improving development efficiency and system maintainability.

[0034] HTTP (Hypertext Transfer Protocol) is a simple request-response protocol that typically runs on top of TCP. It specifies what messages a client might send to a server and what responses it might receive.

[0035] A URL (Uniform Resource Locator) is a simple representation of the location and access method of a resource available on the Internet. It is the address of a standard resource on the Internet. Every file on the Internet has a unique URL, which contains information indicating the file's location and how the browser should handle it.

[0036] JSON (JavaScript Object Notation): is a lightweight file format or data exchange format.

[0037] The following describes a business execution method provided by an embodiment of this application. The method is applied to a request-response service, which runs on a target terminal. Figure 1 This is a flowchart illustrating a business execution method provided in an embodiment of this application. It should be noted that this specification provides the operational steps of the method described in the embodiments or flowcharts, but based on conventional or non-inventive labor, more or fewer operational steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only execution order. In actual system or product execution, the method can be executed sequentially according to the embodiments or accompanying drawings, or in parallel (e.g., in a parallel processor or multi-threaded processing environment). Specifically, as shown... Figure 1 As shown, the above method may include:

[0038] S101, Obtain the request message of the interface call request sent by the target terminal based on the first service instruction. The request message includes: request path and request associated parameters.

[0039] In one specific embodiment, the target terminal may include, but is not limited to, front-end devices such as smartphones, computers (e.g., desktop computers, tablets, laptops), digital assistants, intelligent voice interaction devices (e.g., smart speakers), smart wearable devices, and in-vehicle terminals. This application does not impose any particular limitation on this.

[0040] In one specific embodiment, the target terminal can execute business code to implement the target business function. The business code includes at least a first business instruction and a second business instruction that have a dependency relationship, and the triggering of the second business instruction depends on the execution result of the first business instruction. Optionally, the dependency relationship here may include, but is not limited to, data dependency and control dependency.

[0041] In one optional embodiment, the second business instruction has a data dependency on the first business instruction. For example, the target business function is an e-commerce business function, the first business instruction is a business instruction from the user management module, and the second business instruction is a business instruction from the order processing module. The order processing module depends on the user data provided by the user management module. If the user data changes (such as a user address update), the order processing module also needs to be updated accordingly.

[0042] In an optional embodiment, the second business instruction has a control dependency on the first business instruction. For example, the target business function is the user login function, the first business instruction is the business instruction of the authentication module, and the second business instruction is the business instruction of the resource access module. Only when the execution result of the first business instruction is successful user authentication will the system allow access to the protected resources, that is, trigger the second business instruction.

[0043] In one specific embodiment, the first business instruction can be used to trigger an interface call request. The target terminal responds to the first business instruction by sending an interface call request to the backend interface to be called.

[0044] In a specific embodiment, Figure 2 As shown, before obtaining the request message of the interface call request sent by the target terminal based on the first service instruction, the above method may further include:

[0045] S107, listen to the target port of the target terminal;

[0046] S108: When a connection request is detected from the target port, a communication connection is established with the target port.

[0047] In one specific embodiment, the target terminal may include multiple ports, one of which is assigned to the request-response service as the communication port of the request-response service, and the other ports other than the communication port are configured as target ports for the request-response service to listen on.

[0048] In one specific embodiment, when the request-response service listens for a connection request from the target port through the communication port, the communication port establishes a communication connection with the target port that initiated the connection request. Specifically, the connection method here may include, but is not limited to, TCP connection, Socket connection, etc.

[0049] In a specific embodiment, the request method for an API call request may include, but is not limited to, HTTP requests, HTTPS requests, etc. The request message for an API call request may include, a request path and request-related parameters. Specifically, the request path may be the target address where the target terminal sends the API call request. In a specific embodiment, the request path may be a URL path, which consists of a protocol, host, port, and path. Specifically, the request-related parameters may be parameters carried in the request message. Illustratively, taking an HTTP request as an example, the HTTP request message may consist of a request line, request headers, and a request body. The request path is included in the request line, and the request-related parameters may include, but are not limited to, parameters in the request line, parameters in the request headers, business parameters, etc.

[0050] As can be seen from the above embodiments, the request-response service can listen to the target port of the target terminal. When a connection request from the target port is heard, a communication connection is established with the target port to obtain the interface call request sent by the target terminal, which can ensure the timeliness of request acquisition.

[0051] S102, parse the request path and determine the interface identifier of the backend interface to be called by the target terminal.

[0052] In a specific embodiment, the above-mentioned parsing of the request path to determine the interface identifier of the backend interface to be called by the target terminal may include:

[0053] S1021, parse the string after the last separator in the request path to obtain the interface identifier.

[0054] Specifically, the request path is the URL path, which contains multiple separators " / ". The ending string after the last separator " / " in the URL path is extracted and used as the interface identifier.

[0055] As can be seen from the above embodiments, parsing the string after the last separator in the request path yields the interface identifier. Subsequently, the target verification configuration file and the target response configuration file can be quickly determined based on the interface identifier, thereby responding to interface requests flexibly and efficiently.

[0056] In one specific embodiment, the request-response service may also be pre-configured with multiple request verification configuration files and multiple response message configuration files, specifically, such as... Figure 3 As shown, the file configuration process may include:

[0057] S301, determine the interface identifier of each of the multiple backend interfaces that the target terminal can call, and the calling requirement information corresponding to each of the multiple backend interfaces.

[0058] Specifically, the multiple backend interfaces that the target terminal can call can be the multiple backend interfaces involved in the aforementioned target business function. Based on the aforementioned target business function, a call requirement analysis is performed on each backend interface to obtain the call requirement information corresponding to each backend interface. For illustrative purposes, the call requirement information corresponding to each backend interface may include, but is not limited to: parameter validation requirement information and parameter return requirement information.

[0059] S302, based on the interface identifier of each backend interface and the call requirement information corresponding to each backend interface, configure the request verification configuration file and the response message configuration file corresponding to each backend interface.

[0060] Specifically, the request validation configuration file corresponding to each backend interface can be used to verify the correctness of parameters in the request message sent to the corresponding backend interface. In a specific embodiment, the request validation configuration file can be a configuration file generated based on a preset file format; illustratively, the preset format can be JSON format.

[0061] Specifically, the response message configuration file corresponding to each backend interface can be used to indicate the fixed message data in the request-response message and the dynamic message data in the randomly generated request-response message. In a specific embodiment, the response message configuration file can be a configuration file generated based on a preset file format; illustratively, the preset format can be JSON format.

[0062] S303: Combine the request validation configuration files corresponding to each of the multiple backend interfaces into a single request validation configuration file; combine the response message configuration files corresponding to each of the multiple backend interfaces into a single response message configuration file.

[0063] In one specific embodiment, a verification database and a response database can be constructed. Multiple request verification configuration files are stored in the verification database, and the interface identifier corresponding to each request verification configuration file is used as the index field of the request verification configuration file. Similarly, multiple response message configuration files are stored in the response database, and the interface identifier corresponding to each response message configuration file is used as the index field of the response message configuration file.

[0064] As can be seen from the above embodiments, by configuring the request verification configuration file and the response message configuration file for each backend interface according to the interface identifier and the corresponding call requirement information of each backend interface, and dynamically generating the response message using the configuration file, the ease of interface response simulation can be improved, and frontend developers do not need to write code, thus lowering the technical threshold.

[0065] S103, based on the target verification configuration file, verify the parameters to be verified in the request associated parameters and obtain the verification result. The target verification configuration file is the request verification configuration file corresponding to the interface identifier among a number of preset request verification configuration files.

[0066] Specifically, the target verification configuration file can be obtained by indexing the verification database based on the interface identifier.

[0067] In one specific embodiment, the target verification configuration file contains: a parameter identifier to be verified and parameter verification rules corresponding to the parameter identifier. Based on the target verification configuration file, the parameters to be verified in the request-associated parameters are verified, and the verification results may include:

[0068] S1031, Based on the identifier of the parameter to be verified, determine the parameter to be verified corresponding to the identifier of the parameter to be verified from the request associated parameters.

[0069] S1032, based on the parameter verification rules, the parameter value of the parameter to be verified is verified to obtain the verification result.

[0070] Specifically, the associated request parameters can include multiple request parameters. The system iterates through the multiple request parameters in turn, determines whether the currently iterated request parameter is a parameter to be verified, and verifies the currently iterated request parameter based on the parameter verification rules corresponding to the currently iterated request parameter.

[0071] In a specific embodiment, the parameter validation rule can represent the limiting conditions that the parameter value of the parameter to be validated needs to meet. Accordingly, the validation result can include: validation success result and validation failure result. If the parameter value of the parameter to be validated meets the limiting conditions, a validation success result is obtained (indicating that the validation of the request message has passed). If the parameter value of the parameter to be validated does not meet the limiting conditions or no parameter to be validated corresponding to the identifier of the parameter to be validated is found in the request associated parameters, a validation failure result is obtained (indicating that the validation of the request message has failed).

[0072] In one specific embodiment, the content of the target verification configuration file can be in key-value pair format, where the key is the identifier of the parameter to be verified, and the value corresponding to each key is the parameter verification rule corresponding to the parameter identifier. For example, if the parameter to be verified, P1, is required to be an int value between 1 and 100, it will be represented in the target verification configuration file as P1:int[1,100]; if the parameter to be verified, P2, is required to be a string starting with "aa", it will be represented in the target verification configuration file as P2:re[^aa].

[0073] As can be seen from the above embodiments, the target verification configuration file contains the parameter identifier to be verified and the parameter verification rules corresponding to the parameter identifier. Based on the parameter identifier to be verified, the parameter to be verified corresponding to the parameter identifier is determined from the request associated parameters, and the parameter value of the parameter to be verified is verified based on the parameter verification rules, which can improve the security of business execution.

[0074] S104. If the verification result indicates that the request message has passed the verification, dynamic message data is randomly generated based on the dynamic parameter generation rules contained in the target response configuration file. The target response configuration file is the response message configuration file corresponding to the interface identifier among a number of preset response message configuration files.

[0075] Specifically, the target response configuration file can be obtained by indexing from the response database based on the interface identifier.

[0076] In a specific embodiment, the above-mentioned random generation of dynamic message data based on the dynamic parameter generation rules contained in the target response configuration file may include:

[0077] S1041, Based on a preset regular expression, extract the dynamic generation rules corresponding to at least one preset dynamic parameter in the target response configuration file.

[0078] S1042, Based on the dynamic generation rules corresponding to each preset dynamic parameter, randomly generate the parameter value corresponding to each preset dynamic parameter;

[0079] S1043, take the parameter value corresponding to at least one preset dynamic parameter as dynamic message data.

[0080] In a specific embodiment, the target response configuration file is used to indicate the message elements required for the response message corresponding to the interface call request. Specifically, the message elements here may include: fixed message data set based on the call requirement information and dynamic message data to be generated. The fixed message data can be static message elements that remain unchanged in the response message (i.e., the target terminal sends multiple interface call requests to a certain interface to be called, and the request response service contains the same fixed message data in each response message based on the interface to be called). The dynamic message data can be message elements that need to change in the response message (i.e., the target terminal sends multiple interface call requests to a certain interface to be called, and the request response service contains different dynamic message data in each response message based on the interface to be called).

[0081] Specifically, at least one preset dynamic parameter category can be predetermined, and a regular expression for the corresponding parameter category can be set. Based on the regular expression for each parameter category, the dynamic generation rules corresponding to the preset dynamic parameters of that category can be extracted. For example, the parameter categories here can include, but are not limited to, time-based, numeric, and email-based parameters. Correspondingly, the regular expression for the time category can be: `date.([az]+.*)`, thus identifying dynamic generation rules for time-based dynamic parameters such as `date.yesterday.time` (generating yesterday's date) and `date.today.time` (generating today's date). The regular expression for the numeric category can be: `number.([az]+.*)`, thus identifying dynamic generation rules for numeric dynamic parameters such as `number.int.1_1000000` (randomly generating a 6-digit int number). The regular expression for the email category can be: `email.([az]+.*)`, thus identifying dynamic generation rules for numeric dynamic parameters such as `email.john.163` (randomly generating a 163 email address starting with "john").

[0082] In one specific embodiment, the preset dynamic parameters and their corresponding dynamic generation rules in the target response configuration file can be represented in key-value pair form, where the key is the preset dynamic parameter and the value corresponding to each key is the dynamic generation rule corresponding to the preset dynamic parameter. For illustration, the preset dynamic parameter "id" is an integer ranging from 1 to 100, represented in the target response configuration file as "id": number.int.1_100.

[0083] As can be seen from the above embodiments, by extracting the dynamic generation rules corresponding to at least one preset dynamic parameter in the target response configuration file based on the preset regular expression, and randomly generating the parameter value corresponding to each preset dynamic parameter based on the dynamic generation rule corresponding to each preset dynamic parameter, dynamic message data can be obtained. This can improve the simplicity and flexibility of dynamic message data generation, thereby improving the flexibility of interface request and response simulation and the executability of response messages.

[0084] S105, assemble the fixed message data and dynamic message data contained in the target response configuration file to obtain the first response message.

[0085] In one specific embodiment, the value corresponding to the key of each preset dynamic parameter in the target response configuration file can be replaced by the parameter value corresponding to each preset dynamic parameter from the dynamic generation rule corresponding to each preset dynamic parameter, thereby obtaining the first response message.

[0086] In a specific embodiment, taking the interface call request as an HTTP request as an example, the corresponding first response message is an HTTP response message, which can consist of a status line, response headers, a blank line, and a response body.

[0087] S106, send a first response message to the target terminal so that the target terminal executes a second service instruction triggered by the first response message.

[0088] Specifically, the request-response service can send the first response message to the target port through the communication connection channel between the communication port and the target port.

[0089] Specifically, since the triggering of the second service instruction depends on the execution result of the first service instruction, the target terminal can obtain the execution result of the first service instruction from the first response message to trigger the second service instruction, so that the service code can be executed smoothly.

[0090] As can be seen from the above embodiments, by deploying a simple configuration file and request-response service on the front end, the request-response service can obtain the interface call request sent by the target terminal, determine the target configuration file corresponding to the interface identifier to be called by parsing the request path of the interface call request, generate the response message corresponding to the interface call request based on the verification of the correctness of the interface call request using the configuration file, and send the response message to the target terminal so that the target terminal can execute the corresponding business process based on the response message. This can improve the ease of interface response simulation, lower the technical threshold, and respond to interface requests flexibly and efficiently while ensuring the security of the business, thereby improving the smoothness of front-end business execution.

[0091] In one specific embodiment, the above method may further include:

[0092] If the verification result indicates that the verification of the request message fails, a second response message is sent to the target terminal so that the target terminal executes a second service instruction triggered by the second response message.

[0093] Specifically, the second response message can be a response message indicating that the interface call failed. In a specific embodiment, the second response message carries the reason for the call error.

[0094] In an optional embodiment, in addition to cases where the request message verification fails, a second response message is also sent to the target terminal if the request verification configuration file corresponding to the interface identifier is not found, or the response message configuration file corresponding to the interface identifier is not found, or the necessary fields are missing during the message assembly process.

[0095] In a specific embodiment, taking the interface call request as an HTTP request as an example, the corresponding second response message is an HTTP response message with a response status code set to 500.

[0096] As can be seen from the above embodiments, by simulating various abnormal situations of interface calls and sending response messages corresponding to the abnormal situations to the target terminal, the corresponding business processes can be executed based on the response messages, which can further improve the flexibility and comprehensiveness of interface request and response, thereby further ensuring the smoothness of front-end business execution.

[0097] Taking an API call request as an example, see [link to relevant documentation]. Figure 4 , Figure 4 This is a flowchart illustrating an HTTP request-response scheme based on the above-described business execution method, provided in an embodiment of this application. Specifically, the scheme may include:

[0098] Step 1: Configure the port that the target terminal needs to listen on in the request and response service according to the requirements;

[0099] Step 2: Configure the response database according to requirements. The response message configuration file in the response database is in JSON format. The file name is the interface identifier of the backend interface, and the file content is the response line, response header and response body of the HTTP response message. The file content includes: dynamic generation rules corresponding to fixed message data and static message data.

[0100] Step 3: Configure the validation database according to requirements. The request validation configuration file in the validation database is in JSON format. The file name is the interface identifier of the backend interface, and the file content contains the parameters that need to be validated in the HTTP request message, as well as the parameter validation rules. Configure the regular expression used to identify the parameter validation rules.

[0101] Step 4: Listen to the target port. If a connection request is detected from the target port, establish a TCP communication connection with the target port. The request and response service obtains the HTTP request message from the target terminal through the target port.

[0102] Step 5: The request and response service parses the HTTP request message, extracts the field string after the last ' / ' of the request path in the request message to obtain the identifier of the interface to be called, and then extracts the request-related parameters in the request message.

[0103] Step 6: The request and response service retrieves the corresponding request verification configuration file with the name of the interface to be called from the verification database based on the interface identifier. If the corresponding request verification configuration file can be found, the parameters are verified. If the corresponding request verification configuration file with the name of the interface to be called is not found, the response status code of the HTTP response message is set to 500. If the parameter verification fails, the response status code of the HTTP response message is set to 500.

[0104] Step 7: Retrieve the corresponding response message configuration file named after the interface to be called from the response database. If the corresponding response message configuration file is found, first identify the dynamic parameter generation rules in the response message configuration file based on the preset regular expression, and then randomly generate dynamic message data based on the dynamic parameter generation rules. Then, assemble the fixed message data and dynamic message data contained in the response message configuration file. If the corresponding response message configuration file named after the interface to be called is not found, the HTTP response status code is set to 500. If necessary fields are missing during the message assembly process, the HTTP response status code is set to 500. For messages with an HTTP response code of 500, the reason for the error must be included in the response body.

[0105] Step 8: Send the assembled HTTP response message to the target terminal through the target port.

[0106] As an illustration, the HTTP request message from the destination terminal to the backend interface "users" can be a POST request message as follows:

[0107] (1) Request line: POST / service / users HTTP / 1.1

[0108] (2) Request headers: (only a part is listed)

[0109] Host: 192.168.3.80:8888

[0110] Accept: application / json

[0111] Connection: keep-alive

[0112] (3) Request body:

[0113] name=John&level=H”.

[0114] Analyzing the call requirements of the backend interface "users", we know that the target terminal expects to receive the following HTTP response message:

[0115] (1) Status line: HTTP / 1.1 200 ok

[0116] (2) Response header: (only a part is listed)

[0117] Connection: keep-alive

[0118] Date: 2024.11.13.11:10:31, / / The time when the response message was generated, accurate to the second.

[0119] Content-Type: application / json

[0120] (3) Response body:

[0121] Status: “sucess”

[0122] date:

[0123] {id: 134534, / / Randomly generate a 6-digit integer}

[0124] name: john

[0125] email: john.23hds@163.com / / Randomly generated 163 email address starting with john

[0126] }

[0127] message: user created successfully".

[0128] Accordingly, the configuration file for the response message of the backend interface "users" is as follows:

[0129] {

[0130] HTTP / 1.1 200 OK

[0131] Content-Type: application / json

[0132] Connection: keep-alive

[0133] Date: date.today.sec-time / / Automatically generated: Current time, accurate to the second

[0134] {

[0135] "status": "success",

[0136] "data": {

[0137] "name": "John ",

[0138] "id": number.int.1_1000000, / / Automatically generated: a random 6-digit integer.

[0139] / / Automatically generated: A 163 email address starting with "john"

[0140] "email": "email.john.163"

[0141] },

[0142] "message": "Request processed successfully."

[0143] }

[0144] }

[0145] Accordingly, the request validation configuration file for the backend interface "users" is as follows:

[0146] {

[0147] level:enum.H,L,M / / Check if it is one of H,L,M

[0148] }

[0149] After receiving the HTTP request message for the backend interface "users", the request-response service parses the string "users" after the last " / " in the request path "POST / service / users" as the interface identifier, and then parses all the request-related parameters in the request message; it retrieves the request verification configuration file users.json with the corresponding name "users" from the verification database, and the response message configuration file users.json with the corresponding name "users" from the response database; based on the request verification configuration file, it identifies the parameter to be verified in the HTTP request message as level, where the value H of level is one of H, L, and M. Therefore, the verification of the parameter level passes; based on the dynamic parameter generation rules contained in the response message configuration file, it randomly generates dynamic message data, that is, according to the dynamic parameter corresponding to the preset dynamic parameter 1 "date". The rule "date.today.sec-time" is used to automatically generate the parameter value for "date" (e.g., 2024.11.13.11:10:31). Based on the preset dynamic parameter 2 "id" and the corresponding dynamic generation rule "number.int.1_1000000", the parameter value for "id" is automatically generated (e.g., 134534). Based on the preset dynamic parameter 3 "email" and the corresponding dynamic generation rule "email.john.163", the parameter value for "email" is automatically generated (e.g., email.john.163). The fixed message data and dynamic message data contained in the response message configuration file are then assembled to obtain the HTTP response message, which is then sent back to the target terminal through the target interface.

[0150] As can be seen from the above embodiments, a simple configuration file and request-response service can be deployed on the front end. The request-response service can obtain the interface call request sent by the target terminal, determine the target configuration file corresponding to the interface identifier to be called by parsing the request path of the interface call request, and generate the response message corresponding to the interface call request based on the configuration file after verifying the correctness of the interface call request. The response message is then sent to the target terminal so that the target terminal can execute the corresponding business process based on the response message. This can improve the ease of interface response simulation, lower the technical threshold, and respond to interface requests flexibly and efficiently while ensuring the security of the business, thereby improving the smoothness of front-end business execution.

[0151] This application provides a business execution system, such as... Figure 5As shown, the above system may include: a database running on the target terminal and a request-response service. The database may include: a verification database and a response database. The request-response service may include: an interface communication simulation service and a message processing service. Specifically, the interface communication simulation service may include: a request listening component and a response message sending component. The message processing service may include: a message parsing component, a parameter verification component, a dynamic data generation component, and a response message generation component, wherein:

[0152] Response Database: The response message configuration file in the response database is in JSON format. The file name is the interface identifier of the backend interface, and the file content is the response line, response header, and response body of the HTTP response message. The file content includes: dynamic generation rules corresponding to fixed message data and static message data.

[0153] Validate the database: The request validation configuration file in the database is in JSON format. The file name is the interface identifier of the backend interface, and the file content contains the parameters that need to be validated in the HTTP request message, as well as the parameter validation rules.

[0154] Request listening component: Listens for HTTP requests on a specified port of the target terminal, and when a request arrives, passes the message to the message parsing component.

[0155] Message parsing component: Parses the content after the last " / " in the HTTP request path to obtain the identifier of the interface to be called, and parses the request-related parameters in the request message, including parameters in the request line, parameters in the request header, and business parameters.

[0156] Parameter validation component: Retrieves the request validation configuration file corresponding to the interface identifier in the parameter validation library; if no request validation configuration file corresponding to the interface identifier to be called is found, the HTTP response status code is set to 500; if a request validation configuration file corresponding to the interface identifier to be called exists, it iterates through all request-related parameters in the request message based on the request validation configuration file, and determines whether the currently iterated request-related parameter is the parameter to be validated in the request validation configuration file; if the currently iterated request-related parameter is the parameter to be validated in the request validation configuration file, it determines the correctness of the parameter value of the currently iterated request-related parameter according to the parameter validation rules corresponding to the currently iterated request-related parameter; if incorrect, the HTTP response status code is set to 500.

[0157] Dynamic data generation component: Retrieves the response message configuration file corresponding to the interface identifier to be called in the response database. If a response message configuration file corresponding to the interface identifier to be called can be found, the dynamic parameter generation rules in the response message configuration file are identified based on a preset regular expression, and dynamic message data is randomly generated based on the dynamic parameter generation rules. The dynamic data generation component is configured with regular expressions for identifying dynamic parameter generation rules of different parameter categories. If no response message configuration file corresponding to the interface identifier to be called is found, the response status code of the HTTP response message is set to 500.

[0158] The response message generation component assembles the fixed and dynamic message data contained in the response message configuration file to generate the final HTTP response message. If any necessary fields are missing during the message assembly process, the HTTP response status code is set to 500; messages with an HTTP response code of 500 must include the reason for the error in the response body.

[0159] Response message sending component: Based on the configured port information, it sends out the generated final HTTP response message.

[0160] The systems and methods described above are based on the same inventive concept.

[0161] This application provides a service execution device, such as... Figure 6 As shown, the device is used in a request-response service that runs on a target terminal. The device includes:

[0162] The request message acquisition module 610 is used to acquire the request message of the interface call request sent by the target terminal based on the first business instruction. The request message includes: request path and request associated parameters.

[0163] The request path parsing module 620 is used to parse the request path and determine the interface identifier of the backend interface to be called by the target terminal.

[0164] The parameter verification module 630 is used to verify the parameters to be verified in the request associated parameters based on the target verification configuration file and obtain the verification result. The target verification configuration file is the request verification configuration file corresponding to the interface identifier among a number of preset request verification configuration files.

[0165] The dynamic data generation module 640 is used to randomly generate dynamic message data based on the dynamic parameter generation rules contained in the target response configuration file when the verification result indicates that the verification of the request message has passed. The target response configuration file is the response message configuration file corresponding to the interface identifier among a number of preset response message configuration files.

[0166] The message assembly module 650 is used to assemble the fixed message data and dynamic message data contained in the target response configuration file to obtain the first response message;

[0167] The first response message sending module 660 is used to send a first response message to the target terminal so that the target terminal executes a second service instruction triggered based on the first response message.

[0168] In one specific embodiment, the above-described apparatus may further include:

[0169] The port listening module is used to listen to the target port of the target terminal;

[0170] The connection establishment module is used to establish a communication connection with the target port when a connection request is detected from the target port.

[0171] In one specific embodiment, the request path resolution module 620 described above may include:

[0172] The string parsing unit is used to parse the string after the last separator in the request path to obtain the interface identifier.

[0173] In one specific embodiment, the above-described apparatus may further include:

[0174] The call requirement determination module is used to determine the interface identifiers of the multiple backend interfaces that the target terminal can call and the call requirement information corresponding to each of the multiple backend interfaces.

[0175] The file configuration module is used to configure the request verification configuration file and the response message configuration file for each backend interface according to the interface identifier and the call requirement information corresponding to each backend interface; and to combine the request verification configuration files of multiple backend interfaces into multiple request verification configuration files; and to combine the response message configuration files of multiple backend interfaces into multiple response message configuration files.

[0176] In one specific embodiment, the target verification configuration file includes: a parameter identifier to be verified and parameter verification rules corresponding to the parameter identifier to be verified. The parameter verification module 630 mentioned above may include:

[0177] The parameter to be verified determination unit is used to determine the parameter to be verified corresponding to the parameter to be verified from the request associated parameters based on the parameter to be verified identifier;

[0178] The parameter value verification unit is used to verify the parameter value of the parameter to be verified based on the parameter verification rules, and obtain the verification result.

[0179] In one specific embodiment, the dynamic data generation module 640 described above may include:

[0180] The dynamic generation rule extraction unit is used to extract dynamic generation rules corresponding to at least one preset dynamic parameter in the target response configuration file based on preset regular expressions.

[0181] The parameter value random generation unit is used to randomly generate the parameter value corresponding to each preset dynamic parameter based on the dynamic generation rule corresponding to each preset dynamic parameter.

[0182] The dynamic message data unit is used to take the parameter values ​​corresponding to at least one preset dynamic parameter as dynamic message data.

[0183] In one specific embodiment, the above-described apparatus may further include:

[0184] The second response message sending module is used to send a second response message to the target terminal when the verification result indicates that the verification of the request message has failed, so that the target terminal can execute a second service instruction triggered based on the second response message.

[0185] The apparatus and method embodiments described above are based on the same inventive concept.

[0186] This application provides a service execution device, which includes a processor and a memory. The memory stores at least one instruction or at least one program segment. The at least one instruction or at least one program segment is loaded and executed by the processor to implement the service execution method provided in the above method embodiments.

[0187] Memory can be used to store software programs and modules. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory. Memory can mainly include a program storage area and a data storage area. The program storage area can store the operating system, application programs required for the functions, etc.; the data storage area can store data created based on the use of the aforementioned devices. Furthermore, memory can include high-speed random access memory, and can also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, memory can also include a memory controller to provide the processor with access to the memory.

[0188] The method embodiments provided in this application can be executed in a mobile terminal, computer terminal, server or similar computing device, that is, the computer device mentioned above may include a mobile terminal, computer terminal, server or similar computing device.

[0189] This application embodiment also provides a storage medium, which can be disposed in a server to store at least one instruction or at least one program related to implementing a business execution method of one of the method embodiments. The at least one instruction or the at least one program is loaded and executed by the processor to implement the business execution method provided by the above method embodiment.

[0190] Optionally, in this embodiment, the storage medium may be located at at least one of the multiple network servers in a computer network. Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0191] As can be seen from the embodiments of the business execution method, apparatus, device, or storage medium provided in this application, a simple configuration file and request-response service can be deployed at the front end. The request-response service can obtain the interface call request sent by the target terminal, determine the target configuration file corresponding to the interface identifier to be called by parsing the request path of the interface call request, generate the response message corresponding to the interface call request based on the configuration file after verifying the correctness of the interface call request, and send the response message to the target terminal so that the target terminal can execute the corresponding business process based on the response message. This can improve the ease of interface response simulation, lower the technical threshold, and respond to interface requests flexibly and efficiently while ensuring the security of the business, thereby improving the smoothness of front-end business execution.

[0192] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, specific embodiments have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0193] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0194] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware, or by a program instructing the relevant hardware to implement them. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0195] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A business execution method, characterized in that, The method is applied to a request-response service, which runs on a target terminal, and the method includes: Obtain the request message of the interface call request sent by the target terminal based on the first business instruction, the request message including: request path and request associated parameters; The request path is parsed to determine the interface identifier of the backend interface to be called by the target terminal; Based on the target verification configuration file, the parameters to be verified in the request associated parameters are verified to obtain the verification result. The target verification configuration file is the request verification configuration file corresponding to the interface identifier among a plurality of preset request verification configuration files. If the verification result indicates that the request message has passed verification, dynamic message data is randomly generated based on the dynamic parameter generation rules contained in the target response configuration file. The target response configuration file is the response message configuration file corresponding to the interface identifier among a plurality of preset response message configuration files. The fixed message data and the dynamic message data contained in the target response configuration file are assembled to obtain the first response message; The first response message is sent to the target terminal so that the target terminal executes the second service instruction triggered based on the first response message.

2. The method according to claim 1, characterized in that, The target verification configuration file contains: a parameter identifier to be verified and parameter verification rules corresponding to the parameter identifier. The verification of the parameter to be verified in the request-associated parameters based on the target verification configuration file yields the following verification results: Based on the identifier of the parameter to be verified, the parameter to be verified corresponding to the identifier of the parameter to be verified is determined from the request associated parameters; Based on the parameter verification rules, the parameter values ​​of the parameters to be verified are verified to obtain the verification results.

3. The method according to claim 1, characterized in that, The random generation of dynamic message data based on the dynamic parameter generation rules contained in the target response configuration file includes: Based on preset regular expressions, extract the dynamic generation rules corresponding to at least one preset dynamic parameter in the target response configuration file. Based on the dynamic generation rule corresponding to each preset dynamic parameter, the parameter value corresponding to each preset dynamic parameter is randomly generated; The parameter values ​​corresponding to each of the at least one preset dynamic parameter are used as the dynamic message data.

4. The method according to claim 1, characterized in that, The step of parsing the request path to determine the interface identifier of the backend interface to be called by the target terminal includes: The interface identifier is obtained by parsing the string following the last separator in the request path.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: Determine the interface identifier of each of the multiple backend interfaces that the target terminal can call, and the calling requirement information corresponding to each of the multiple backend interfaces; Configure the request verification configuration file and the response message configuration file for each backend interface based on the interface identifier of each backend interface and the call requirement information corresponding to each backend interface; The request verification configuration files corresponding to each of the multiple backend interfaces are used as the multiple request verification configuration files; the response message configuration files corresponding to each of the multiple backend interfaces are used as the multiple response message configuration files.

6. The method according to any one of claims 1 to 4, characterized in that, Before obtaining the request message of the interface call request sent by the target terminal based on the first service instruction, the method further includes: Listen to the target port of the target terminal; When a connection request is detected from the target port, a communication connection is established with the target port.

7. The method according to any one of claims 1 to 4, characterized in that, The method further includes: If the verification result indicates that the verification of the request message fails, a second response message is sent to the target terminal so that the target terminal executes a second service instruction triggered based on the second response message.

8. A business execution device, characterized in that, The device is used in a request-response service, the request-response service runs on a target terminal, and the device includes: The request message acquisition module is used to acquire the request message of the interface call request sent by the target terminal based on the first business instruction. The request message includes: request path and request associated parameters. The request path parsing module is used to parse the request path and determine the interface identifier of the backend interface to be called by the target terminal. The parameter verification module is used to verify the parameters to be verified in the request-associated parameters based on the target verification configuration file and obtain the verification result. The target verification configuration file is the request verification configuration file corresponding to the interface identifier among a plurality of preset request verification configuration files. The dynamic data generation module is used to randomly generate dynamic message data based on the dynamic parameter generation rules contained in the target response configuration file when the verification result indicates that the verification of the request message has passed. The target response configuration file is the response message configuration file corresponding to the interface identifier among a plurality of preset response message configuration files. The message assembly module is used to assemble the fixed message data and the dynamic message data contained in the target response configuration file to obtain the first response message; The first response message sending module is used to send the first response message to the target terminal so that the target terminal executes the second service instruction triggered based on the first response message.

9. An electronic device, characterized in that, The device includes a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the business execution method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The storage medium stores at least one instruction or at least one program segment, which is loaded and executed by a processor to implement the business execution method as described in any one of claims 1 to 7.

Images