Service execution method and device, equipment and storage medium

Abstract

The invention discloses a service execution method, device and equipment and a storage medium, the method is applied to request response service, and the method comprises the following steps: obtaining a request message of an interface calling request sent by a target terminal based on a first service instruction; analyzing a request path of the request message, and determining an interface identifier of a back-end interface to be called; based on a target verification configuration file corresponding to the interface identifier, verifying a to-be-verified parameter in the request message; under the condition that the verification is passed, generating a rule based on a dynamic parameter contained in a target response configuration file corresponding to the interface identifier, and randomly generating dynamic message data; assembling the fixed message data and the 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 based on the target response message. By utilizing the scheme of the invention, the service security can be ensured, and the interface request is flexibly and efficiently responded.

Description

Technical Field

[0001] The present application relates to the technical field of message processing, and in particular to a service execution method, device, equipment and storage medium. Background Art

[0002] In Web development, you may encounter a situation where the backend interface that the frontend needs to call is unavailable, causing the frontend business code to fail to execute smoothly. The current common practice is to deploy a Mock server and enter interface data according to the interface requirements. This method has certain limitations and requires frontend developers to write business code related to the Mock server. The technical threshold is high. At the same time, the content of the simulated response message is relatively fixed, with poor flexibility and lack of security for the frontend business. Summary of the invention

[0003] The present application provides a service execution method, apparatus, device and storage medium, which can improve the simplicity of interface response simulation, lower the technical threshold, and flexibly and efficiently respond to interface requests on the basis of ensuring the security of the service, thereby improving the fluency of front-end service execution. The technical solution of the present application is as follows:

[0004] On the one hand, a service execution method is provided, the method is applied to a request response service, the request response service is run on a target terminal, the method comprises:

[0005] Acquire a request message of an interface call request sent by the target terminal based on the first service instruction, wherein the request message includes: a request path and request associated parameters;

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

[0007] Based on a target verification configuration file, verifying the parameters to be verified in the request-associated parameters to obtain a verification result, wherein the target verification configuration file is a request verification configuration file corresponding to the interface identifier in a plurality of preset request verification configuration files;

[0008] In a case where the verification result indicates that the request message has passed the verification, dynamically generating dynamic message data based on a dynamic parameter generation rule included in a target response configuration file, wherein the target response configuration file is a response message configuration file corresponding to the interface identifier among a plurality of preset response message configuration files;

[0009] Assembling the fixed message data and the dynamic message data contained in the target response configuration file to obtain a first response message;

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

[0011] On the other hand, a service execution device is provided, the device is applied to a request response service, the request response service is run on a target terminal, and the device includes:

[0012] A request message acquisition module, used to acquire a request message of an interface call request sent by the target terminal based on the first service instruction, wherein the request message includes: a request path and request associated parameters;

[0013] A request path parsing module, used to parse the request path and determine the interface identifier of the backend interface to be called by the target terminal;

[0014] A parameter verification module, configured to verify the parameters to be verified in the request-associated parameters based on a target verification configuration file to obtain a verification result, wherein the target verification configuration file is a request verification configuration file corresponding to the interface identifier in a plurality of preset request verification configuration files;

[0015] a dynamic data generation module, configured to randomly generate dynamic message data based on a dynamic parameter generation rule included in a target response configuration file when the verification result indicates that the request message has passed verification, wherein the target response configuration file is a response message configuration file corresponding to the interface identifier among a plurality of preset response message configuration files;

[0016] A message assembling module, used for assembling the fixed message data and the dynamic message data contained in the target response configuration file to obtain a 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 by the target response message.

[0018] On the other hand, a business execution device is provided, which includes a processor and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or the at least one program is 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, in which at least one instruction or at least one program is stored, and the at least one instruction or the at least one program is loaded and executed by a processor to implement the business execution method as described above.

[0020] The service execution method, device, equipment and storage medium provided by this application have the following technical effects:

[0021] By using the technical solution provided by the present application, a simple configuration file and a 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, and determine the target configuration file corresponding to the interface identifier to be called by parsing the request path of the interface call request. The configuration file is used to generate a response message corresponding to the interface call request on the basis of verifying the correctness of the interface call request, and the response message is sent to the target terminal, so that the target terminal executes the corresponding business process based on the response message. The simplicity of interface response simulation can be improved, the technical threshold can be lowered, and the interface request can be responded to flexibly and efficiently on the basis of ensuring the security of the business, thereby improving the fluency of the front-end business execution. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the technical solutions and advantages in the embodiments of the present application or the prior art, the drawings required for use in the embodiments or the prior art descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0023] Figure 1 It is a flowchart of a service execution method provided in an embodiment of the present application;

[0024] Figure 2 It is a flowchart of another service execution method provided in an embodiment of the present application;

[0025] Figure 3 It is a flowchart of a file configuration process provided by an embodiment of the present application;

[0026] Figure 4 It is a flowchart of an HTTP request response solution implemented based on the above-mentioned business execution method provided in an embodiment of the present application;

[0027] Figure 5 It is a schematic diagram of a business execution system provided in an embodiment of the present application;

[0028] Figure 6 It is a schematic diagram of a service execution device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0029] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0030] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or server that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0031] In order to better understand the embodiments of the present application, some professional terms involved in the embodiments of the present application are introduced below:

[0032] Mock Server: A software tool or technology that simulates the functions and behaviors of a real server. It can create a virtual server environment on a computer, enabling users to test, debug, and develop various applications and services without the need for an actual physical server.

[0033] Service: refers to a software component that runs independently to provide specific functions or services. Services can be accessed through the network and interact with other components. Services can implement a variety of different functions, such as data storage, computing, communication, authentication, etc. 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 usually runs on top of TCP. It specifies what messages a client may send to a server and what responses it may get.

[0035] URL (Uniform Resource Location): A simple representation of the location and access method of resources available on the Internet. It is the address of standard resources on the Internet. Every file on the Internet has a unique URL, which contains information indicating the location of the file 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 service execution method provided by an embodiment of the present application, the method is applied to a request response service, the request response service is run on a target terminal, Figure 1 A flowchart of a business execution method provided for an embodiment of the present application. It should be noted that this specification provides method operation steps as described in the embodiment or flowchart, but may include more or fewer operation steps based on conventional or non-creative work. The order of steps listed in the embodiment is only one way of executing the steps among many orders, and does not represent the only order of execution. When the system or product is executed in practice, it can be executed in sequence or in parallel (for example, in a parallel processor or multi-threaded processing environment) according to the method shown in the embodiment or the accompanying drawings. Specifically, Figure 1 As shown, the above method may include:

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

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

[0040] In a specific embodiment, the target terminal can execute a service code for implementing a target service function, the service code at least includes a first service instruction and a second service instruction having a dependency relationship, and the triggering of the second service instruction depends on the execution result of the first service instruction. Optionally, the dependency relationship here may include but is not limited to: data dependency and control dependency.

[0041] In an optional embodiment, the second business instruction has 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 of the user management module, and the second business instruction is a business instruction of 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 the user address is updated), 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 a user login function, the first business instruction is a business instruction of an identity authentication module, and the second business instruction is a business instruction of a resource access module. Only when the execution result of the first business instruction is a successful user identity authentication, the system allows access to protected resources, i.e., triggers the second business instruction.

[0043] In a specific embodiment, the first service instruction may be used to trigger an interface calling request, and the target terminal sends an interface calling request to the backend interface to be called in response to the first service instruction.

[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 method may further include:

[0045] S107, monitoring the target port of the target terminal;

[0046] S108, when a connection request from a target port is monitored, a communication connection is established with the target port.

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

[0048] In a specific embodiment, when the request response service monitors a connection request from a target port through a communication port, the communication port establishes a communication connection with the target port that initiates the connection request. Specifically, the connection mode here may include but is not limited to: TCP connection, Socket connection, etc.

[0049] In a specific embodiment, the request method of the interface call request may include, but is not limited to, HTTP request, HTTPS request, etc. The request message of the interface call request may include, a request path and request associated parameters. Specifically, the request path may be the target address to which the target terminal sends the interface call request. In a specific embodiment, the request path may be a URL path, which is composed of a protocol, a host, a port, and a path. Specifically, the request associated parameters may be parameters carried in the request message. Schematically, taking the interface call request as an HTTP request as an example, the request message of the HTTP request may be composed of a request line, a request header, and a request body. The request path is included in the request line, and the request associated parameters may include, but are not limited to, parameters in the request line, parameters in the request header, business parameters, etc.

[0050] As can be seen from the above embodiments, the request response service can monitor the target port of the target terminal. When a connection request from the target port is monitored, a communication connection is established with the target port to obtain the interface call request sent by the target terminal, thereby ensuring the timeliness of request acquisition.

[0051] S102, parsing the request path to 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 an interface identifier.

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

[0055] It can be seen from the above embodiments that the string after the last separator in the request path is parsed to obtain the interface identifier, and the target verification configuration file and the target response configuration file can be quickly determined based on the interface identifier, thereby responding to the interface request flexibly and efficiently.

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

[0057] S301, determining the interface identifiers of the respective backend interfaces that can be called by the target terminal and the calling requirement information corresponding to the respective backend interfaces.

[0058] Specifically, the multiple backend interfaces that can be called by the target terminal can be multiple backend interfaces involved in the above target business functions. Based on the above target business functions, a call requirement analysis is performed on each backend interface to obtain the call requirement information corresponding to each backend interface. In an illustrative manner, the call requirement information corresponding to each backend interface can include, but is not limited to: parameter verification requirement information and parameter return requirement information.

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

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

[0061] Specifically, the response message configuration file corresponding to each backend interface can be used to indicate fixed message data in the request response message and 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, and schematically, the preset format can be a JSON format.

[0062] S303, using the request verification configuration files corresponding to the multiple backend interfaces as multiple request verification configuration files; using the response message configuration files corresponding to the multiple backend interfaces as multiple response message configuration files.

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

[0064] It can be seen from the above embodiments that, according to the interface identifier of each backend interface and the calling requirement information corresponding to each backend interface, a request verification configuration file corresponding to each backend interface and a response message configuration file corresponding to each backend interface are configured, and the response message is dynamically generated using the configuration file. This can improve the simplicity of interface response simulation, eliminate the need for front-end developers to write code, and lower the technical threshold.

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

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

[0067] In a specific embodiment, the target verification configuration file includes: a parameter identifier to be verified and a parameter verification rule corresponding to the parameter identifier to be verified. Based on the target verification configuration file, the parameter to be verified in the request associated parameter is verified, and the verification result obtained may include:

[0068] S1031, based on the parameter identifier to be verified, determining the parameter to be verified corresponding to the parameter identifier to be verified from the request associated parameters.

[0069] S1032, based on the parameter verification rule, verify the parameter value of the parameter to be verified to obtain a verification result.

[0070] Specifically, the request-associated parameters may include multiple request parameters. The multiple request parameters are traversed in turn to determine whether the currently traversed request parameter is a parameter to be verified. If the currently traversed request parameter is a parameter to be verified, the currently traversed request parameter is verified based on the parameter verification rule corresponding to the currently traversed request parameter.

[0071] In a specific embodiment, the parameter verification rule may indicate the restriction conditions that the parameter value of the parameter to be verified must meet. Accordingly, the verification result may include: a verification success result and a verification failure result. When the parameter value of the parameter to be verified meets the restriction conditions, a verification success result is obtained (indicating that the request message has been verified). When the parameter value of the parameter to be verified does not meet the restriction conditions or the parameter to be verified corresponding to the parameter to be verified identifier is not found in the request-associated parameters, a verification failure result is obtained (indicating that the request message has not been verified).

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

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

[0074] S104, when the verification result indicates that the request message verification has passed, randomly generate dynamic message data based on the dynamic parameter generation rule included in the target response configuration file, and the target response configuration file is a response message configuration file corresponding to the interface identifier among the preset multiple response message configuration files.

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

[0076] In a specific embodiment, the above-mentioned dynamic parameter generation rule based on the target response configuration file included in the randomly generated dynamic message data may include:

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

[0078] S1042, randomly generating a parameter value corresponding to each preset dynamic parameter based on a dynamic generation rule corresponding to each preset dynamic parameter;

[0079] S1043: Use 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, wherein 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 the response message based on each feedback from the interface to be called), and 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 the response message based on each feedback from the interface to be called).

[0081] Specifically, at least one parameter category of a preset dynamic parameter can be predetermined, and a regular expression of the corresponding parameter category can be set, so that based on the regular expression of each parameter category, the dynamic generation rule corresponding to the preset dynamic parameter of the corresponding parameter category can be extracted. Schematically, the parameter category here can include but is not limited to: time category, value category, mailbox category, etc. Correspondingly, the regular expression of the time category can be: date.([az]+.*), so as to identify the dynamic generation rules corresponding to time-type dynamic parameters such as "date.yesterday.time" (generate yesterday's date) and "date.today.time" (generate today's date); the regular expression of the value category can be: number.([az]+.*), so as to identify the dynamic generation rules corresponding to the value-type dynamic parameters such as "number.int.1_1000000" (randomly generate a 6-digit int number), and the regular expression of the mailbox category can be: email.([az]+.*), so as to identify the dynamic generation rules corresponding to the value-type dynamic parameters such as "email.john.163" (randomly generate a 163 mailbox starting with john).

[0082] In a specific embodiment, the preset dynamic parameters and their corresponding dynamic generation rules in the target response configuration file can be expressed in the form of key-value pairs, 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. Schematically, the preset dynamic parameter "id" is an integer ranging from 1 to 100, which is expressed as "id": number.int.1_100 in the target response configuration file.

[0083] It can be seen from the above embodiments that based on the preset regular expression, the dynamic generation rules corresponding to at least one preset dynamic parameter in the target response configuration file are extracted, and based on the dynamic generation rules corresponding to each preset dynamic parameter, the parameter value corresponding to each preset dynamic parameter is randomly generated to obtain dynamic message data, which can improve the simplicity and flexibility of dynamic message data generation, and thereby improve the flexibility of interface request response simulation and the executableness of response messages.

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

[0085] In a specific embodiment, the value corresponding to the key of each preset dynamic parameter in the target response configuration file can be replaced with 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, and the HTTP response message may be composed of a status line, a response header, 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 target response message.

[0088] Specifically, the request response service may send a 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] It can be seen from the above embodiments that a simple configuration file and request response service are deployed at the front end. The request response service can obtain the interface call request sent by the target terminal, and determine the target configuration file corresponding to the interface identifier to be called by parsing the request path of the interface call request. The configuration file is used to verify the correctness of the interface call request, and a response message corresponding to the interface call request is generated, and a response message is sent to the target terminal, so that the target terminal executes the corresponding business process based on the response message. The simplicity of interface response simulation can be improved, the technical threshold can be lowered, and the interface request can be responded to flexibly and efficiently on the basis of ensuring the security of the business, thereby improving the fluency of the front-end business execution.

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

[0092] When the verification result indicates that the request message verification 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 may be a response message indicating that the interface call has failed. In a specific embodiment, the second response message carries the reason for the call error.

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

[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] It can be seen from the above embodiments that by simulating various abnormal situations of interface calls and sending response messages corresponding to the abnormal situations to the target terminal so that the corresponding business processes are executed based on the response messages, the flexibility and comprehensiveness of the interface request response can be further improved, thereby further ensuring the smoothness of the front-end business execution.

[0097] Take the interface call request as an HTTP request as an example, see Figure 4 , Figure 4 This is a flowchart of an HTTP request response solution implemented based on the above-mentioned service execution method provided in an embodiment of the present application. Specifically, the solution may include:

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

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

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

[0101] Step 4: Monitor the target port. If a connection request from the target port is monitored, a TCP communication connection is established with the target port. The request response service obtains the HTTP request message of the destination terminal through the target port.

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

[0103] Step 6: The request response service retrieves the request verification configuration file corresponding to the interface identifier to be called from the verification database according to the interface identifier. If the corresponding request verification configuration file can be retrieved, the parameter verification is performed; if the request verification configuration file corresponding to the interface identifier to be called is not retrieved, 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 response message configuration file whose corresponding name is the interface identifier to be called in the response database. If the corresponding response message configuration file can be retrieved, first identify the dynamic parameter generation rule in the response message configuration file based on the preset regular expression, and randomly generate dynamic message data based on the dynamic parameter generation rule, and then assemble the fixed message data and dynamic message data contained in the response message configuration file; if the response message configuration file whose corresponding name is the interface identifier to be called is not retrieved, the response status code of the HTTP response message is set to 500; if the necessary fields are missing in the process of assembling the message, the HTTP response status code is set to 500; the message with the HTTP response code of 500 needs to carry the reason for the error in the response body;

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

[0106] Indicatively, the HTTP request message of the destination terminal for the backend interface "users" can be the following POST request message:

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

[0108] (2) Request header: (only part of it 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] By analyzing the call requirements of the backend interface "users", it can be seen that the HTTP response message that the destination terminal expects to receive is:

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

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

[0117] Connection:keep-alive

[0118] Date:2024.11.13.11:10:31, / / Time when the response message is generated, accurate to seconds

[0119] Content-Type:application / json

[0120] (3) Response body:

[0121] Status: "sucess"

[0122] date:

[0123] {id:134534, / / Randomly generate a 6-digit int random number

[0124] name:john,

[0125] email:john.23hds@163.com / / Randomly generate a 163 mailbox starting with john

[0126] }

[0127] message: user created successfully".

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

[0129] {

[0130] HTTP / 1.1 200OK

[0131] Content-Type:application / json

[0132] Connection:keep-alive

[0133] Date:date.today.sec-time / / Automatically generated: current time, accurate to seconds

[0134] {

[0135] "status":"success",

[0136] "data":{

[0137] "name":"John",

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

[0139] / / Automatically generated: a 163 mailbox starting with john

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

[0141] },

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

[0143] }

[0144] }

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

[0146] {

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

[0148] }

[0149] After obtaining 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 request-related parameters in the request message; retrieves the request verification configuration file users.json with the corresponding name "users" from the verification database, and retrieves the response message configuration file users.json with the corresponding name "users" from the response database; according to the request verification configuration file, it is identified that the parameter to be verified in the HTTP request message is level, and the value H of level is one of H, L, and M. Therefore, the level verification of the parameter to be verified passes; based on the dynamic parameter generation rule contained in the response message configuration file, a dynamic message data is randomly generated. That is, according to the dynamic generation rule "date.today.sec-time" corresponding to the preset dynamic parameter 1 "date", the parameter value of "date" is automatically generated (for example, 2024.11.13.11:10:31); according to the dynamic generation rule "number.int.1_1000000" corresponding to the preset dynamic parameter 2 "id", the parameter value of "id" is automatically generated (for example, 134534); according to the dynamic generation rule "email.john.163" corresponding to the preset dynamic parameter 3 "email", the parameter value of "email" is automatically generated (for example, email.john.163); then the fixed message data and the dynamic message data contained in the response message configuration file are assembled to obtain an HTTP response message, and the HTTP response message is fed back to the target terminal through the target interface.

[0150] It can be seen from the above embodiments that 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, and determine the target configuration file corresponding to the interface identifier to be called by parsing the request path of the interface call request. The configuration file is used to verify the correctness of the interface call request, and a response message corresponding to the interface call request is generated, and a response message is sent to the target terminal, so that the target terminal executes the corresponding business process based on the response message. The simplicity of interface response simulation can be improved, the technical threshold can be lowered, and the interface request can be responded to flexibly and efficiently on the basis of ensuring the security of the business, thereby improving the fluency of the front-end business execution.

[0151] The present application embodiment provides a service execution system, such as Figure 5As shown, the above system may include: a database and a request response service running on the target terminal, 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 monitoring 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 name of the file is the interface identifier of the backend interface. The content of the file is the response line, response header and response body in the HTTP response message. The content of the file includes: dynamic generation rules corresponding to fixed message data and static message data;

[0153] Verification database: The request verification configuration file in the verification database is in json format. The name of the file is the interface identifier of the backend interface. The content of the file is the parameters that need to be verified in the HTTP request message, as well as the parameter verification rules.

[0154] Request monitoring component: monitors the HTTP request of the designated port of the target terminal, and when the 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, obtains the identifier of the interface to be called, and parses the request-related parameters in the request message, including the parameters in the request line, the parameters in the request header, and the business parameters.

[0156] Parameter verification component: retrieve the request verification configuration file corresponding to the interface identifier in the parameter verification library; if the request verification configuration file corresponding to the interface identifier to be called is not retrieved, the response status code of the HTTP response message is set to 500; if there is a request verification configuration file corresponding to the interface identifier to be called, based on the request verification configuration file, traverse all request-related parameters in the request message to determine whether the currently traversed request-related parameters are the parameters to be checked in the request verification configuration file; if the currently traversed request-related parameters are the parameters to be checked in the request verification configuration file, determine the correctness of the parameter values ​​of the currently traversed request-related parameters according to the parameter verification rules corresponding to the currently traversed request-related parameters; if incorrect, set the response status code of the HTTP response message to 500.

[0157] Dynamic data generation component: retrieve the response message configuration file corresponding to the interface identifier to be called in the response database; if the response message configuration file corresponding to the interface identifier to be called can be retrieved, identify the dynamic parameter generation rule in the response message configuration file based on a preset regular expression, and randomly generate dynamic message data based on the dynamic parameter generation rule, wherein the dynamic data generation component is configured with a regular expression for identifying the dynamic parameter generation rules of different parameter categories; if the response message configuration file corresponding to the interface identifier to be called is not retrieved, the response status code of the HTTP response message is set to 500.

[0158] Response message generation component: Assemble the fixed message data and dynamic message data contained in the response message configuration file to generate the final HTTP response message. 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 needs to be carried in the response body.

[0159] Response message sending component: sends the final generated HTTP response message according to the configured port information.

[0160] The system and method embodiments in the above-mentioned system embodiments are based on the same inventive concept.

[0161] The present application embodiment provides a service execution device, such as Figure 6 As shown, the device is applied to a request response service, the request response service runs on a target terminal, and the device includes:

[0162] The request message acquisition module 610 is used to acquire a request message of the interface call request sent by the target terminal based on the first service instruction, wherein the request message includes: a 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-related parameters based on the target verification configuration file to obtain a verification result, and the target verification configuration file is a request verification configuration file corresponding to the interface identifier in the preset multiple 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 rule included in the target response configuration file when the verification result indicates that the request message verification has passed, and the target response configuration file is a response message configuration file corresponding to the interface identifier among the preset multiple response message configuration files;

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

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

[0168] In a specific embodiment, the above device may further include:

[0169] A port monitoring module is used to monitor 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 from the target port is monitored.

[0171] In a specific embodiment, the request path parsing module 620 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 a specific embodiment, the above device may further include:

[0174] A calling requirement determination module, used to determine the interface identifiers of the multiple backend interfaces that can be called by the target terminal and the calling requirement information corresponding to the multiple backend interfaces;

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

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

[0177] A to-be-verified parameter determination unit, configured to determine, based on the to-be-verified parameter identifier, the to-be-verified parameter corresponding to the to-be-verified parameter identifier from the request associated parameters;

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

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

[0180] A dynamic generation rule extraction unit, used to extract the dynamic generation rule corresponding to at least one preset dynamic parameter in the target response configuration file based on a preset regular expression;

[0181] A parameter value random generation unit, used to randomly generate a parameter value corresponding to each preset dynamic parameter based on a dynamic generation rule corresponding to each preset dynamic parameter;

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

[0183] In a specific embodiment, the above device 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 request message verification fails, so that the target terminal executes a second service instruction triggered by the second response message.

[0185] The device and method embodiments in the above-mentioned device embodiments are based on the same inventive concept.

[0186] An embodiment of the present application provides a business execution device, which includes a processor and a memory, in which at least one instruction or at least one program is stored, and 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 in the above method embodiment.

[0187] The 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. The memory can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, application programs required for functions, etc.; the data storage area can store data created according to the use of the above devices, etc. In addition, the memory can include a high-speed random access memory and can also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices. Accordingly, the memory can also include a memory controller to provide the processor with access to the memory.

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

[0189] An embodiment of the present application also provides a storage medium, which can be set in a server to store at least one instruction or at least one program related to a business execution method for implementing a method embodiment. 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 method embodiment.

[0190] Optionally, in this embodiment, the storage medium may be located in at least one of the multiple network servers of the computer network. Optionally, in this embodiment, the storage medium may include, but is not limited to, various media that can store program codes, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0191] It can be seen from the embodiments of the business execution method, device, equipment or storage medium provided by the present application that 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, and determine the target configuration file corresponding to the interface identifier to be called by parsing the request path of the interface call request. The configuration file is used to verify the correctness of the interface call request, and a response message corresponding to the interface call request is generated, and a response message is sent to the target terminal, so that the target terminal executes the corresponding business process based on the response message. The simplicity of interface response simulation can be improved, the technical threshold can be lowered, and the interface request can be responded to flexibly and efficiently on the basis of ensuring the security of the business, thereby improving the fluency of the front-end business execution.

[0192] It should be noted that the above-mentioned sequence of the embodiments of the present application is for description only and does not represent the advantages and disadvantages of the embodiments. The above-mentioned specific embodiments of this specification are described. Other embodiments are within the scope of the attached 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.

[0193] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device, equipment and storage medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0194] A person skilled in the art will appreciate that all or part of the steps to implement the above embodiments may be accomplished by hardware, or may be accomplished by instructing the relevant hardware through a program, and the above program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a disk or an optical disk, etc.

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

Claims

1. A service execution method, characterized in that: The method is applied to a request response service, the request response service is run on a target terminal, and the method includes: Acquire a request message of an interface call request sent by the target terminal based on the first service instruction, wherein the request message includes: a request path and request associated parameters; Parsing the request path to determine the interface identifier of the backend interface to be called by the target terminal; Based on a target verification configuration file, verifying the parameters to be verified in the request-associated parameters to obtain a verification result, wherein the target verification configuration file is a request verification configuration file corresponding to the interface identifier in a plurality of preset request verification configuration files; In a case where the verification result indicates that the request message has passed the verification, dynamically generating dynamic message data based on a dynamic parameter generation rule included in a target response configuration file, wherein the target response configuration file is a response message configuration file corresponding to the interface identifier among a plurality of preset response message configuration files; Assembling the fixed message data and the dynamic message data included in the target response configuration file to obtain a first response message; The first response message is sent to the target terminal, so that the target terminal executes a second service instruction triggered by the target response message.

2. The method according to claim 1, characterized in that The target verification configuration file includes: a parameter identifier to be verified and a parameter verification rule corresponding to the parameter identifier to be verified. The verification result obtained by verifying the parameter to be verified in the request-related parameters based on the target verification configuration file includes: Based on the parameter identifier to be checked, determining the parameter to be checked corresponding to the parameter identifier to be checked from the request associated parameters; Based on the parameter verification rule, the parameter value of the parameter to be verified is verified to obtain the verification result.

3. The method according to claim 1, characterized in that The step of randomly generating dynamic message data based on the dynamic parameter generation rules included in the target response configuration file includes: Extracting dynamic generation rules corresponding to at least one preset dynamic parameter in the target response configuration file based on a preset regular expression; Based on the dynamic generation rule corresponding to each preset dynamic parameter, randomly generate a parameter value corresponding to each preset dynamic parameter; The parameter value corresponding to each of the at least one preset dynamic parameters is used as the dynamic message data.

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

5. The method according to any one of claims 1 to 4, characterized in that: The method further comprises: Determine the interface identifiers of the multiple backend interfaces that can be called by the target terminal and the call requirement information corresponding to the multiple backend interfaces; According to the interface identifier of each backend interface and the call requirement information corresponding to each backend interface, configure the request verification configuration file corresponding to each backend interface and the response message configuration file corresponding to each backend interface; The request verification configuration files corresponding to each of the multiple back-end interfaces are used as the multiple request verification configuration files; the response message configuration files corresponding to each of the multiple back-end 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 acquiring the request message of the interface call request sent by the target terminal based on the first service instruction, the method further includes: Monitoring a target port of the target terminal; When a connection request from the target port is monitored, 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 comprises: When the verification result indicates that the request message has not been verified, 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.

8. A service execution device, characterized in that: The device is applied to a request response service, the request response service is run on a target terminal, and the device includes: A request message acquisition module, used to acquire a request message of an interface call request sent by the target terminal based on the first service instruction, wherein the request message includes: a request path and request associated parameters; A request path parsing module, used to parse the request path and determine the interface identifier of the backend interface to be called by the target terminal; A parameter verification module, configured to verify the parameters to be verified in the request-associated parameters based on a target verification configuration file to obtain a verification result, wherein the target verification configuration file is a request verification configuration file corresponding to the interface identifier in a plurality of preset request verification configuration files; a dynamic data generation module, configured to randomly generate dynamic message data based on a dynamic parameter generation rule included in a target response configuration file when the verification result indicates that the request message has passed verification, wherein the target response configuration file is a response message configuration file corresponding to the interface identifier among a plurality of preset response message configuration files; A message assembling module, used for assembling the fixed message data and the dynamic message data contained in the target response configuration file to obtain a 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 by the target response message.

9. An electronic device, characterized in that: The device includes a processor and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded and executed by the processor to implement the service 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, and the at least one instruction or the at least one program is loaded and executed by the processor to implement the service execution method according to any one of claims 1 to 7.

Images