A request response method and device, a computer device and a storage medium
By simulating the interface at the data access layer and generating and calling back simulated response results, the problem of cumbersome external packet capture tools and high development costs and errors caused by code modifications in existing technologies is solved, achieving efficient and zero-intrusion interface simulation.
Patent Information
- Application Number
- CN202310431150.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-04-20
- Publication Date
- 2026-02-24
- Estimated Expiration
- 2043-04-20
AI Technical Summary
In the development and maintenance of mobile applications, existing technologies that rely on external packet capture tools to simulate network interfaces are cumbersome and prone to errors, while directly modifying code logic and intruding into business code result in high development costs and are prone to introducing program errors.
By simulating the interface at the data access layer, generating and calling back simulated response results, certificate verification and code modifications are avoided, and the server-side response to network service requests is directly simulated at the data access layer.
It reduced development costs, avoided code errors, achieved zero-intrusion interface simulation, and improved development efficiency.
Smart Images

Figure CN116455950B_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of computer technology, and more specifically, to a request-response method, apparatus, computer device, and storage medium. Background Technology
[0002] Currently, in the development and maintenance of mobile applications involving network interfaces, the common approach is to use external packet capture tools or directly modify the code logic to simulate the network interface, generate response results, and then develop and maintain the mobile application based on these response results.
[0003] Both of the above methods have certain problems. Using external packet capture tools to simulate network interfaces requires a proxy between the client and the server to intercept network service requests sent by the client, and then the packet capture tool decides whether to forward them to the server. This method requires certificate verification of the security of the packet capture tool and the maintenance of corresponding simulated data according to specific request and response body data formats. The process is relatively cumbersome, prone to errors, and consumes a lot of development costs. On the other hand, simulating network interfaces by directly modifying the code logic requires intrusion into the business code, which can easily lead to the accidental deployment of the simulated interface code, causing program errors (bugs). Furthermore, developers need to understand the relevant Business Logic Layer (BLL) code logic for calling network service requests, which also consumes a lot of development costs. Summary of the Invention
[0004] This disclosure provides at least one request-response method, apparatus, computer device, and storage medium.
[0005] In a first aspect, embodiments of this disclosure provide a request-response method applied to a terminal device. The method includes:
[0006] In response to receiving a network service request initiated by a target application at the business logic layer of the terminal device, based on the request model object indicated by the network service request, it is determined whether there exists a target interface simulation entity corresponding to the network service request; the target interface simulation entity is used to simulate the response result returned by the data access layer of the terminal device through the interface corresponding to the network service request;
[0007] In the presence of the target interface simulation entity, based on the request model object, the simulation response result corresponding to the request model object is determined using the target interface simulation entity;
[0008] Based on the simulated response result, a simulated response model object corresponding to the request model object is generated, and the simulated response model object is called back to the business logic layer so that the target application can perform the operation corresponding to the network service request according to the received simulated response model object.
[0009] In this way, since the target interface simulation entity simulates the response to network service requests at the data access layer, network service requests initiated by the target application at the business logic layer of the terminal device can be directly sent to the target interface simulation entity. Upon receiving the network service request, the target interface simulation entity generates a response model object corresponding to the request model object indicated by the network service request and sends the response model object back to the business logic layer. This eliminates the need for external packet capture tools to act as proxies between the client and server, thus eliminating the need for certificate verification for security. Furthermore, by directly using the request model object carried in the network service request and the response model object returned by the target interface simulation entity to simulate data transmission between the business logic layer and the data access layer, there is no need to maintain corresponding simulated data according to specific request and response body data formats. This avoids editing errors that are prone to occur when modifying code in plain text code files, significantly reducing development costs.
[0010] In addition, by simulating the response results of network service requests through the interface in the data access layer, there is no need to modify the business logic layer code, which can achieve zero intrusion into the business code, avoid the possibility of accidentally bringing the simulated interface code online, and also eliminate the need for developers to understand the relevant business logic layer code logic for calling network service requests.
[0011] The above request-response method can easily and efficiently simulate the server's response to the network service request initiated by the client in the data access layer without intruding on the business logic layer code, and generate a simulated response model object to be called back to the business logic layer.
[0012] In an optional implementation, the method further includes: sending the network service request to the corresponding service interface when the target interface simulation entity does not exist;
[0013] In response to receiving the actual response result generated by the service interface in response to the network service request, a real response model object corresponding to the request model object is generated based on the actual response result; the real response model object is then called back to the business logic layer so that the target application performs the operation corresponding to the network service request according to the received real response model object.
[0014] In this way, even if the target interface simulation entity does not exist, network service requests can be sent to the server through the service interface to generate a real response. Without manual intervention, the system automatically switches between different request-response methods based on whether the target interface simulation entity exists.
[0015] In one possible implementation, determining whether a target interface simulation entity corresponding to the network service request exists based on the request model object indicated by the network service request includes:
[0016] Obtain the identification information corresponding to the request model object from the request model object;
[0017] Based on the identification information, determine whether there is an interface simulation entity associated with the identification information from at least one pre-defined interface simulation entity;
[0018] In response to the existence of an interface simulation entity associated with the identification information, the interface simulation entity associated with the identification information is determined as the target interface simulation entity corresponding to the network service request.
[0019] In one possible implementation, determining the simulated response result corresponding to the request model object based on the request model object and using the target interface to simulate an entity includes:
[0020] Obtain the request parameters corresponding to the request model object from the request model object;
[0021] Based on the request parameters, the executable method defined in the target interface simulation entity is called to obtain the simulation response result corresponding to the request model object.
[0022] In one possible implementation, the step of determining the simulated response result corresponding to the request model object based on the request model object and utilizing the target interface simulation entity, when the target interface simulation entity exists, includes:
[0023] If the target interface simulation entity exists, its availability is determined based on its availability identifier; the availability identifier indicates whether the interface simulation entity is available or unavailable.
[0024] If the target interface simulation entity is available, the simulation response result corresponding to the request model object is determined using the target interface simulation entity.
[0025] In one possible implementation, it also includes:
[0026] On the development and debugging page corresponding to the target application, at least one switch control button corresponding to an interface simulation entity is displayed;
[0027] In response to the triggering operation of the switch control button, the availability flag corresponding to the interface simulation entity is changed.
[0028] In this way, by triggering the switch control button corresponding to the interface simulation entity, developers can manually change the availability flag of the interface simulation entity, thereby realizing control over the interface simulation entity. In different application scenarios, there is a greater degree of freedom to switch between different request and response methods.
[0029] In one possible implementation, the method further includes: generating an interface simulation entity;
[0030] The interface simulation entity is embedded into the application package corresponding to the target application, so that the terminal device that installs the target application package can execute request responses based on the interface simulation entity.
[0031] Secondly, embodiments of this disclosure also provide a request response device, comprising:
[0032] The first determining module is configured to, in response to receiving a network service request initiated by a target application at the business logic layer of the terminal device, determine, based on the request model object indicated by the network service request, whether there exists a target interface simulation entity corresponding to the network service request; the target interface simulation entity is used to simulate the response result returned by the data access layer of the terminal device through the interface corresponding to the network service request;
[0033] The second determining module is used to determine the simulated response result corresponding to the request model object based on the request model object and using the target interface simulation entity when the target interface simulation entity exists.
[0034] The first generation module is used to generate a simulated response model object corresponding to the request model object based on the simulated response result, and to call back the simulated response model object to the business logic layer so that the target application can perform the operation corresponding to the network service request according to the received simulated response model object.
[0035] In one possible implementation, the second determining module sends the network service request to the corresponding service interface if the target interface simulation entity does not exist.
[0036] In response to receiving the actual response result generated by the service interface in response to the network service request, a real response model object corresponding to the request model object is generated based on the actual response result; the real response model object is then called back to the business logic layer so that the target application performs the operation corresponding to the network service request according to the received real response model object.
[0037] In one possible implementation, when the first determining module determines whether a target interface simulation entity corresponding to the network service request exists based on the request model object indicated by the network service request, it is configured to:
[0038] Obtain the identification information corresponding to the request model object from the request model object;
[0039] Based on the identification information, determine whether there is an interface simulation entity associated with the identification information from at least one pre-defined interface simulation entity;
[0040] In response to the existence of an interface simulation entity associated with the identification information, the interface simulation entity associated with the identification information is determined as the target interface simulation entity corresponding to the network service request.
[0041] In one possible implementation, when the first generation module determines the simulated response result corresponding to the request model object based on the request model object and using the target interface to simulate an entity, it is configured to:
[0042] Obtain the request parameters corresponding to the request model object from the request model object;
[0043] Based on the request parameters, the executable method defined in the target interface simulation entity is called to obtain the simulation response result corresponding to the request model object.
[0044] In one possible implementation, when the second determining module determines the simulated response result corresponding to the request model object based on the request model object and utilizing the target interface simulation entity, in the presence of the target interface simulation entity, it is configured to:
[0045] If the target interface simulation entity exists, its availability is determined based on its availability identifier; the availability identifier indicates whether the interface simulation entity is available or unavailable.
[0046] If the target interface simulation entity is available, the simulation response result corresponding to the request model object is determined using the target interface simulation entity.
[0047] In one possible implementation, the device further includes: a status control module, configured to:
[0048] On the development and debugging page corresponding to the target application, at least one switch control button corresponding to an interface simulation entity is displayed;
[0049] In response to the triggering operation of the switch control button, the availability flag corresponding to the interface simulation entity is changed.
[0050] In one possible implementation, the apparatus further includes: a second generation module, configured to:
[0051] Generate interface to simulate entities;
[0052] The interface simulation entity is embedded into the application package corresponding to the target application, so that the terminal device that installs the target application package can execute request responses based on the interface simulation entity.
[0053] Thirdly, an optional implementation of this disclosure also provides a computer device, a processor, and a memory, wherein the memory stores machine-readable instructions executable by the processor, and the processor is configured to execute the machine-readable instructions stored in the memory. When the machine-readable instructions are executed by the processor, the steps of the first aspect above, or any possible implementation of the first aspect, are performed.
[0054] Fourthly, an optional implementation of this disclosure also provides a computer-readable storage medium storing a computer program that, when run, performs the steps of the first aspect or any possible implementation of the first aspect.
[0055] For a description of the effects of the above-mentioned request-response device, computer equipment, and computer-readable storage medium, please refer to the description of the above-mentioned request-response method, which will not be repeated here.
[0056] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this disclosure.
[0057] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description
[0058] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the embodiments will be briefly described below. These drawings are incorporated in and constitute a part of this specification. They illustrate embodiments conforming to this disclosure and, together with the specification, serve to explain the technical solutions of this disclosure. It should be understood that the following drawings only show some embodiments of this disclosure and should not be considered as limiting the scope. Those skilled in the art can obtain other related drawings based on these drawings without creative effort.
[0059] Figure 1 A flowchart of a request-response method provided by some embodiments of this disclosure is shown;
[0060] Figure 2 A flowchart illustrating the generation interface for simulating entities provided in some embodiments of this disclosure is shown;
[0061] Figure 3 The diagram shows an example of a development and debugging page for an interface simulation entity provided in some embodiments of this disclosure;
[0062] Figure 4 A flowchart illustrating a request-response method provided in some embodiments of this disclosure is shown.
[0063] Figure 5 A schematic diagram of a request response apparatus provided in some embodiments of this disclosure is shown;
[0064] Figure 6 A schematic diagram of a computer device provided in some embodiments of the present disclosure is shown. Detailed Implementation
[0065] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. The components of the embodiments of this disclosure described and shown herein can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this disclosure is not intended to limit the scope of the claimed disclosure, but merely represents selected embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without inventive effort are within the scope of protection of this disclosure.
[0066] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.
[0067] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application, server, or storage medium performing the operations of this disclosed technical solution, based on the prompt message.
[0068] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.
[0069] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.
[0070] Research has revealed several issues in mobile application development and maintenance involving network interfaces, including incomplete implementation of business logic, reliance on server-side interface returns of specific data, high troubleshooting costs, and high modification costs. These issues are typically addressed using two interface simulation methods: One method involves using external network packet capture tools to proxy all network service requests from the device, intercepting network service requests for specific interfaces, and generating corresponding simulated data according to specific request and response body data formats. The other method involves directly modifying the business logic layer, changing the request logic for pulling or uploading data from the server to return specific data for interface simulation. However, using external network packet capture tools for interface simulation is cumbersome, prone to errors when modifying plain text code files, and requires significant development costs. Directly modifying the code logic requires intruding into the business code, which can easily lead to accidentally deploying the simulated interface code, causing bugs. Furthermore, developers need to understand the relevant business logic layer's code logic for calling network service requests, which also incurs significant development costs.
[0071] Based on the above research, this disclosure provides a simple and efficient interface simulation method that requires zero intrusion into the business logic layer code. This method simulates the server's response to a network service request initiated by the business logic layer and sends the corresponding real response model object back to the client. The relevant inventive concept includes: by simulating the response to a network service request at the data access layer, the network service request initiated by the target application at the business logic layer of the terminal device can be sent to the target interface simulation entity. This method does not require modifying code files according to a specific data format to generate simulated data, and it does not require modification of the business logic layer code. It achieves a simple and efficient simulation of the server's response to a client's network service request at the data access layer without intruding on the business logic layer code, generating a simulated response model object, and sending it back to the business logic layer.
[0072] The shortcomings of the above solutions are the result of the inventor's practical experience and careful research. Therefore, the discovery process of the above problems and the solutions proposed in this disclosure below should be considered as the inventor's contribution to this disclosure.
[0073] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.
[0074] To facilitate understanding of the technical solutions disclosed herein, the technical terms used in the embodiments of this disclosure will first be explained:
[0075] In a three-tier architecture, the Business Logic Layer (BLL) sits between the Data Access Layer (DAL) and the User Interface (UI). After receiving user commands from the UI layer, it connects to the DAL layer to enable data connection and command transmission between the three layers.
[0076] The Data Access Layer (DAL) is used to communicate with the server and respond to network communication-related operations.
[0077] To facilitate understanding of this embodiment, a request-response method disclosed in this disclosure will first be described in detail. The execution subject of the request-response method provided in this disclosure is generally a computer device with certain computing capabilities. This computer device may include, for example, a terminal device, a server, or other processing devices. The terminal device may be a user equipment (UE), mobile device, user terminal, terminal, cellular phone, cordless phone, personal digital assistant (PDA), handheld device, computing device, in-vehicle device, wearable device, etc. In some possible implementations, the request-response method can be implemented by a processor calling computer-readable instructions stored in memory.
[0078] The following describes a request-response method provided by an embodiment of this disclosure.
[0079] See Figure 1 The diagram shows a flowchart of a request-response method provided in an embodiment of this disclosure. The method includes steps S101 to S103, wherein:
[0080] S101: In response to receiving a network service request initiated by the target application at the business logic layer of the terminal device, based on the request model object indicated by the network service request, determine whether there exists a target interface simulation entity corresponding to the network service request; the target interface simulation entity is used to simulate the response result returned by the data access layer of the terminal device through the interface corresponding to the network service request.
[0081] Here, the interface simulation entity is a class defined in the code. It can be pre-generated based on potential network service requests from the target application and stored in a local dictionary of interface simulation entities. These potential network service requests from the target application could be, for example, during the development phase of a new feature, where the new feature might initiate all or part of the network service requests to the server; or during the troubleshooting phase of the target application, involving network service requests corresponding to faults.
[0082] The target interface simulation entity is determined in at least one interface simulation entity based on the request model object indicated by the network service request.
[0083] For example, in response to receiving a network service request initiated by the Business Logic Layer (BLL layer), the system queries a dictionary storing at least one interface simulation entity to determine whether a target interface simulation entity corresponding to the network service request exists, based on the request model object indicated by the network service request.
[0084] Here, a dictionary is a structure for storing key-value pairs. Each key is unique within a dictionary, and one key can correspond to multiple values. This allows you to retrieve the corresponding value from the dictionary using the key. For example, the key can be feature data of the response returned by the API's simulated entity, consisting of numbers, strings, or tuples. For instance, key1 might return a product page, and key2 might return a payment page. The value can be the corresponding response result; for example, key1's value might be a product image or description, while key2's value might be the payment page.
[0085] The process of querying a dictionary containing at least one simulated interface entity to determine whether a simulated target interface entity exists corresponding to the network service request can be achieved by matching the key value of the simulated interface entity.
[0086] In addition, there are other ways to store interface-simulated entities, such as lists that can be retrieved through retrieval, which will not be elaborated on in this application.
[0087] In addition, network service requests initiated by the BLL layer can be generated based on user instructions triggered by developers in the UI layer, or they can be generated directly in the BLL layer by modifying the code logic.
[0088] Next, the target interface simulation entity provides a simulation interface to receive network service requests initiated by the BLL layer and return a simulation response corresponding to the network service request. When the BLL layer initiates a network service request, it calls the modeled request method, passing in a request model object through the simulation interface. This modeled request method is an abstract method; the request method, Uniform Resource Locator (URL), protocol version, request headers, and request parameters can be pre-agreed with the server. Then, structured request data is defined using template code generation, and this structured request data is represented as a request model object. Since the target interface simulation entity simulates the server's DAL layer, it can also recognize the structured request data of this request model object.
[0089] S102: If the target interface simulation entity exists, based on the request model object, use the target interface simulation entity to determine the simulation response result corresponding to the request model object.
[0090] Here, when a target interface simulation entity exists, the structured request data of the request object model is passed to the target interface simulation entity through the simulation interface connected to it. The target interface simulation entity analyzes the structured request data of the request model object to determine the actual request content of this network service request, and then determines the simulated response result corresponding to the request model object based on the actual request content. The actual request content is determined based on the request parameters in the structured request data.
[0091] For example, the target interface simulation entity analyzes the structured request data of the request model object to determine the actual request content of this network service request: display 5 hot news items on the homepage. At this time, the target interface simulation entity determines the simulation data corresponding to the 5 hot news items from the pre-prepared simulation data corresponding to multiple hot news items, and constitutes the simulation response result.
[0092] Here, by preparing simulated data corresponding to multiple trending news items in advance, a target interface can simulate different request parameters for network service requests with the same URL. For example, network service request A and network service request B have the same URL, but the actual request content of network service request A is to display 5 trending news items on the homepage, while network service request B displays 8 trending news items on the homepage. Based on the request parameters corresponding to different network service requests, the corresponding simulated response result can be determined in a target interface simulated entity, reducing the number of target interface simulated entities and saving the cost of generating interface simulated entities.
[0093] In addition, the request parameters for network service requests can also be to obtain image information, text information, information for a certain period of time, or the size and resolution of an image, etc. The specific settings are determined according to the actual application, and this application does not impose any restrictions.
[0094] S103: Based on the simulated response result, generate a simulated response model object corresponding to the request model object, and call back the simulated response model object to the business logic layer so that the target application performs the operation corresponding to the network service request according to the received simulated response model object.
[0095] Here, after determining the simulated response result, a simulated response model object corresponding to the request model object is generated. Both the simulated response model object and the request model object can be represented as a set of structured request data, such as structured data in JSON format. The simulated response model object is then called back to the BLL layer.
[0096] In this way, by using an interface mock entity defined by code, the DAL layer can simulate the server's response to a network service request initiated by the client and call back the real response model object corresponding to the real response result to the client. Since this process is implemented in the DAL layer, there is no need to intrude on the BLL layer code. Furthermore, the mock response model object uses the same modeling method as the request model object, eliminating the need to edit code files in plain text format. Instead, it simulates structured data in JSON format based on the mock response model object using the modeling method. Moreover, since the interface mock entity does not need to proxy the network service request initiated by the BLL layer, certificate verification is not required. Thus, this method can simply and efficiently simulate the server's response to a network service request initiated by the client in the DAL layer without intruding on the BLL layer code, generate a mock response model object, and call back to the business logic layer.
[0097] In some possible implementations provided in this disclosure, in the absence of the target interface simulation entity, the network service request is sent to the corresponding service interface; in response to receiving the real response result generated by the service interface in response to the network service request, a real response model object corresponding to the request model object is generated based on the real response result; the real response model object is called back to the business logic layer so that the target application performs the operation corresponding to the network service request according to the received real response model object.
[0098] Here, in the case where no target interface simulates an entity, the network service request initiated by the BLL layer is sent to the service interface connected to the server. At this point, the modeled request method is called, passing in the request model object indicated by the network service request. Then, the structured request data of the request model object is sent to the application network framework. The application network framework serializes the structured request data, generating a request byte stream, which is then sent to the server via the operating system network service. The server generates the actual response result and sends the response byte stream back to the application network framework via the operating system network service. The application network framework converts the response byte stream into structured response data and sends it back to the modeled request method. The modeled request method then converts the structured response data into the corresponding actual response model object and sends it back to the BLL layer. This ensures that the target application receives the actual response model object.
[0099] The difference between the real response model object here and the simulated response model object mentioned above is that the real response model object is generated by the server, while the simulated response model object is generated by the simulated interface entity. The difference between the service interface and the simulated interface is whether it is the server or the simulated interface entity that connects to the BLL layer.
[0100] In some possible implementations provided in this disclosure, the method further includes: generating an interface simulation entity; and embedding the interface simulation entity into an application package corresponding to the target application, so that a terminal device that has the target application package installed executes a request response based on the interface simulation entity.
[0101] Among them, see Figure 2 The flowchart shown illustrates a process for generating an interface simulation entity. Generating the interface simulation entity includes the following steps S201 to S203, wherein:
[0102] S201: Determine the key corresponding to the interface simulation entity.
[0103] For example, the key corresponding to the interface simulation entity can be determined based on the network service requests that the target application may initiate. For instance, if the network service request includes a URL, the key corresponding to the interface simulation entity can be determined based on the URL. The same URL shares the same interface simulation entity, thus determining a single key. Alternatively, the key can be determined based on the class name of the request model object indicated by the network service request. The class name of the request model object can be pre-set based on the actual request content of the request model object. For example, if the actual request content is a request for a news page, then the class name of the request model object could be some data information that represents the requested news page, such as NP1. After pre-setting the class name of the request model object, this class name can be used as the key corresponding to the interface simulation entity. When a network service request initiated by the BLL layer is received, the key with the same class name is matched in the locally stored dictionary based on the class name of the request model object indicated by the network service request. If a match is found, the interface simulation entity corresponding to this key is determined to be the target interface simulation entity.
[0104] S202: Function to set the control interface to simulate the on / off state of an entity.
[0105] For example, the on / off state of the interface simulation entity can be controlled to determine whether the interface simulation entity intervenes in the process of the client requesting data from the server when the interface simulation entity is included in the application package corresponding to the target application.
[0106] In this way, by controlling the on / off state of the interface simulation entity, the interface simulation entity can be flexibly turned on or off during the testing or development phase.
[0107] S203: Determine the executable methods of the interface simulation entity.
[0108] For example, the executable method here could be a handle method, which initializes a simulated response model object based on the request model object indicated by the received network service request and then calls back to the BLL layer.
[0109] Here, the `handle` method initializes the mock response model object. It can return mock data that matches the request model object, or it can return erroneous mock data. The specific settings can be configured according to the actual application. Here, "matching" means returning a correct, reasonable response model object that corresponds to the request model object. For example, a network service request for a certain interface needs to return mock data A on the first request, mock data B on the second request, and erroneous mock data on the third request. The `handle` method is used to simulate these three response results.
[0110] The steps of generating interface simulation entities in S201 to S203 above can be done by developing the interface simulation code in a programming manner during the generation phase using a code editor.
[0111] Next, after determining the interface simulation entity, the execution code of the interface simulation entity can be injected into the application package of the target application, so that the target application can use the interface simulation entity to simulate the process of the server responding to the network service request initiated by the client and calling back the real response model object corresponding to the real response result to the client.
[0112] Furthermore, the sharing of interface simulation entities can be achieved by distributing artifacts. No external tools are needed; multiple users can share the interface simulation entity simply by installing the application that executes the code of the interface simulation entity on the terminal device.
[0113] Furthermore, in some possible implementations provided in this disclosure, at least one switch control button corresponding to an interface simulation entity is displayed on the development and debugging page corresponding to the target application; in response to the triggering operation of the switch control button, the availability identifier corresponding to the interface simulation entity is changed.
[0114] Here, on the UI layer development and debugging page of the target application, the switch control button corresponding to the interface simulation entity is displayed; the development and debugging page here can be set to enable permissions, and can only be enabled by the relevant developers.
[0115] For example, see Figure 3 The image shown is an example of a development and debugging page for an interface simulating an entity. Figure 3In the development and debugging page, the keys for interface simulation entities A31, A32, A33, and A34 are displayed, along with switch control buttons B31, B32, B33, and B34 to control the on / off state of interface simulation entities A31, A32, A33, and A34. Developers can change the on / off state and availability indicator of the interface simulation entity controlled by the corresponding switch control button by triggering it.
[0116] In this way, by setting a switch control button on the UI layer development and debugging page, the control interface can more intuitively and conveniently simulate the on / off state of the entity.
[0117] In some possible implementations provided in this disclosure, determining whether there exists a target interface simulation entity corresponding to the network service request based on the request model object indicated by the network service request includes: obtaining identification information corresponding to the request model object from the request model object; determining whether there exists an interface simulation entity associated with the identification information from at least one pre-set interface simulation entity based on the identification information; and, in response to the existence of an interface simulation entity associated with the identification information, determining the interface simulation entity associated with the identification information as the target interface simulation entity corresponding to the network service request.
[0118] Here, the identification information corresponding to the request model object can be any one or more of the following: the class name, ID, identifier code, URL, etc. of the request model object.
[0119] For example, after obtaining the identification information, the key of at least one interface simulation entity is matched in a locally stored dictionary to determine whether there is an interface simulation entity associated with the identification information. This association can be that the identification information of the request model object is exactly the same as the key of the interface simulation entity, or it can be some kind of preset correspondence. In response to the existence of an interface simulation entity associated with the identification information in the dictionary, that interface simulation entity is determined as the target interface simulation entity.
[0120] In some possible implementations provided in this disclosure, determining the simulated response result corresponding to the request model object based on the request model object and using the target interface simulation entity includes: obtaining the request parameters corresponding to the request model object from the request model object; and calling the executable method defined in the target interface simulation entity based on the request parameters to obtain the simulated response result corresponding to the request model object.
[0121] Here, the request parameters can be parsed from the structured request data of the request model object. Based on the request parameters, the executable methods defined in the target interface mock entity are called, such as the `handle` method.
[0122] For example, the request parameters corresponding to the request model object are represented as follows: obtain a set of product images, based on the request parameters and the key of the target interface simulated entity, call the handle method, look up the value corresponding to the key of the target interface simulated entity in the dictionary, and piece together the structured response data representing a set of product images that meet the request parameters to form the simulated response result.
[0123] In some possible implementations provided in this disclosure, the step of determining the simulated response result corresponding to the request model object based on the target interface simulation entity when the target interface simulation entity exists includes: determining whether the target interface simulation entity is available based on its availability identifier when the target interface simulation entity exists; the availability identifier is used to indicate whether the interface simulation entity is available or unavailable; and determining the simulated response result corresponding to the request model object using the target interface simulation entity when the target interface simulation entity is available.
[0124] For example, after determining the target interface simulation entity, the availability identifier of the target interface simulation entity can also be judged. For instance, after determining the target interface simulation entity, the value of the representation status information of the target interface simulation entity in the dictionary can be accessed. When the access result is 1, it means that the target interface simulation entity is in an available state. When the access result is 0, it means that the target interface simulation entity is in an unavailable state.
[0125] In addition, the values representing state information in the dictionary can be updated based on the user's triggering operation of the switch control button on the UI layer development and debugging page. The value representing state information is set to a value that is either 0 or 1. When the user triggers the switch control button, if the value is 1, it is changed to 0, and if the value is 0, it is changed to 1.
[0126] Next, if the target interface simulation entity is available, that is, if the value of the representation status information of the target interface simulation entity is 1, the request model object is sent to the target interface simulation entity. Conversely, if the target interface simulation entity is unavailable, that is, if the value of the representation status information of the target interface simulation entity is 0, the request model object is sent to the server.
[0127] Additionally, see Figure 4As shown, this application also provides a flowchart example of a request-response method. Figure 4 In the process, the request-response method includes the following steps S401 to S409, wherein:
[0128] S401: The BLL layer initiates a network service request.
[0129] S402: Invoke the modeled request method.
[0130] S403: Determine whether a corresponding target interface simulation entity exists based on the request model object; if it exists, execute S404; otherwise, jump to S408.
[0131] S404: Determine whether the target interface simulation entity is available. If it is available, execute S405; otherwise, execute S408.
[0132] S405: Send the request model object to the target interface simulation entity.
[0133] S406: The target interface simulated entity generates a simulated response model object based on the request model object and sends it back to the BLL layer.
[0134] S407: The BLL layer receives the response model object and completes the network service request.
[0135] The response model objects here include either simulated response model objects or real response model objects.
[0136] S408: Send the request model object to the server.
[0137] S409: The server receives the request model object, generates the actual response model object, and sends a callback to the BLL layer. Then it redirects to S407.
[0138] Furthermore, this disclosure also provides an application scenario for the request-response method. During the development of new requirements, since the new requirements have not yet been deployed after the interface definition is completed, it is impossible to request a server response to a network service request initiated by the BLL layer. This method can be applied by embedding the executable code of at least one interface simulation entity into the target application's package. Upon receiving a network service request initiated by the BLL layer, the target interface simulation entity is searched in a locally stored dictionary, and the request model object indicated by the network service request is sent to the target interface simulation entity. The target interface simulation entity generates a simulated response model object based on the request model object and sends the response model object back to the BLL layer. Based on the simulated response model object returned by the target interface simulation entity, the overall implementation code logic of the new requirement is determined to be correct, thereby eliminating possible bugs before the new requirement goes live.
[0139] During the problem investigation phase, in order to reproduce online issues, this method can also be applied to investigate bugs offline, and the specific process is similar to that described above.
[0140] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.
[0141] Based on the same inventive concept, this disclosure also provides a request response device corresponding to a request response method. Since the principle of the device in this disclosure for solving the problem is similar to the above-mentioned request response method in this disclosure, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.
[0142] See Figure 5 The diagram shown is a schematic representation of a request-response device provided in an embodiment of this disclosure. The device includes: a first determining module 51, a second determining module 52, and a first generating module 53; wherein,
[0143] The first determining module 51 is configured to, in response to receiving a network service request initiated by a target application at the business logic layer of the terminal device, determine whether there exists a target interface simulation entity corresponding to the network service request based on the request model object indicated by the network service request; the target interface simulation entity is used to simulate the response result returned by the data access layer of the terminal device through the interface corresponding to the network service request;
[0144] The second determining module 52 is used to determine the simulated response result corresponding to the request model object based on the request model object and using the target interface simulation entity when the target interface simulation entity exists.
[0145] The first generation module 53 is used to generate a simulated response model object corresponding to the request model object based on the simulated response result, and to call back the simulated response model object to the business logic layer so that the target application can perform the operation corresponding to the network service request according to the received simulated response model object.
[0146] In one possible implementation, the second determining module 52 sends the network service request to the corresponding service interface if the target interface simulation entity does not exist.
[0147] In response to receiving the actual response result generated by the service interface in response to the network service request, a real response model object corresponding to the request model object is generated based on the actual response result; the real response model object is then called back to the business logic layer so that the target application performs the operation corresponding to the network service request according to the received real response model object.
[0148] In one possible implementation, when the first determining module 51 determines whether there exists a target interface simulation entity corresponding to the network service request based on the request model object indicated by the network service request, it is configured to:
[0149] Obtain the identification information corresponding to the request model object from the request model object;
[0150] Based on the identification information, determine whether there is an interface simulation entity associated with the identification information from at least one pre-defined interface simulation entity;
[0151] In response to the existence of an interface simulation entity associated with the identification information, the interface simulation entity associated with the identification information is determined as the target interface simulation entity corresponding to the network service request.
[0152] In one possible implementation, when the first generation module 53 determines the simulated response result corresponding to the request model object based on the request model object and using the target interface to simulate an entity, it is configured to:
[0153] Obtain the request parameters corresponding to the request model object from the request model object;
[0154] Based on the request parameters, the executable method defined in the target interface simulation entity is called to obtain the simulation response result corresponding to the request model object.
[0155] In one possible implementation, when the second determining module 52 determines the simulated response result corresponding to the request model object based on the request model object and using the target interface simulation entity, in the presence of the target interface simulation entity, it is configured to:
[0156] If the target interface simulation entity exists, its availability is determined based on its availability identifier; the availability identifier indicates whether the interface simulation entity is available or unavailable.
[0157] If the target interface simulation entity is available, the simulation response result corresponding to the request model object is determined using the target interface simulation entity.
[0158] In one possible implementation, the device further includes: a status control module 55, configured to:
[0159] On the development and debugging page corresponding to the target application, at least one switch control button corresponding to an interface simulation entity is displayed;
[0160] In response to the triggering operation of the switch control button, the availability flag corresponding to the interface simulation entity is changed.
[0161] In one possible implementation, the apparatus further includes: a second generation module 54, configured to:
[0162] Generate interface to simulate entities;
[0163] The interface simulation entity is embedded into the application package corresponding to the target application, so that the terminal device that installs the target application package can execute request responses based on the interface simulation entity.
[0164] The processing flow of each module in the device and the interaction flow between each module can be referred to the relevant descriptions in the above method embodiments, and will not be detailed here.
[0165] This disclosure also provides a computer device, such as... Figure 6 The diagram shown is a schematic representation of a computer device structure provided in an embodiment of this disclosure, including:
[0166] A processor 61 and a memory 62; the memory 62 stores machine-readable instructions executable by the processor 61, and the processor 61 executes the machine-readable instructions stored in the memory 62. When the machine-readable instructions are executed by the processor 61, the processor 61 performs the following steps:
[0167] In response to receiving a network service request initiated by a target application at the business logic layer of the terminal device, based on the request model object indicated by the network service request, it is determined whether there exists a target interface simulation entity corresponding to the network service request; the target interface simulation entity is used to simulate the response result returned by the data access layer of the terminal device through the interface corresponding to the network service request;
[0168] In the presence of the target interface simulation entity, based on the request model object, the simulation response result corresponding to the request model object is determined using the target interface simulation entity;
[0169] Based on the simulated response result, a simulated response model object corresponding to the request model object is generated, and the simulated response model object is called back to the business logic layer so that the target application can perform the operation corresponding to the network service request according to the received simulated response model object.
[0170] The aforementioned memory 62 includes a main memory 621 and an external memory 622. The main memory 621, also known as internal memory, is used to temporarily store the computational data in the processor 61, as well as the data exchanged with external memory such as a hard disk. The processor 61 exchanges data with the external memory 622 through the main memory 621.
[0171] The specific execution process of the above instructions can be referred to the steps of a request-response method described in the embodiments of this disclosure, and will not be repeated here.
[0172] This disclosure also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of a request-response method described in the above-described method embodiments. The storage medium may be a volatile or non-volatile computer-readable storage medium.
[0173] This disclosure also provides a computer program product carrying program code. The program code includes instructions that can be used to execute the steps of a request-response method described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.
[0174] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium; in another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.
[0175] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection may be through some communication interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.
[0176] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0177] In addition, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0178] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0179] Finally, it should be noted that the above-described embodiments are merely specific implementations of this disclosure, used to illustrate the technical solutions of this disclosure, and not to limit it. The protection scope of this disclosure is not limited thereto. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this disclosure. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be covered within the protection scope of this disclosure. Therefore, the protection scope of this disclosure should be determined by the protection scope of the claims.
Claims
1. A request-response method, characterized in that, Applied to terminal devices, including: In response to receiving a network service request initiated by a target application at the business logic layer of the terminal device, based on the request model object indicated by the network service request, it is determined whether there exists a target interface simulation entity corresponding to the network service request; the target interface simulation entity is used to simulate the response result returned by the data access layer of the terminal device through the interface corresponding to the network service request; wherein, the request model object is represented as a first set of structured request data; In the presence of the target interface simulation entity, based on the request model object, the simulation response result corresponding to the request model object is determined using the target interface simulation entity; Based on the simulated response result, a simulated response model object corresponding to the request model object is generated, and the simulated response model object is called back to the business logic layer so that the target application performs the operation corresponding to the network service request according to the received simulated response model object; wherein, the simulated response model object represents a second set of structured request data, and the simulated response model object adopts the same modeling method as the request model object.
2. The method according to claim 1, characterized in that, The method further includes: sending the network service request to the corresponding service interface when there is no target interface simulation entity; In response to receiving the actual response result generated by the service interface in response to the network service request, a real response model object corresponding to the request model object is generated based on the actual response result; the real response model object is then called back to the business logic layer so that the target application performs the operation corresponding to the network service request according to the received real response model object.
3. The method according to claim 1, characterized in that, The step of determining whether a target interface simulation entity corresponding to the network service request exists based on the request model object indicated by the network service request includes: Obtain the identification information corresponding to the request model object from the request model object; Based on the identification information, determine whether there is an interface simulation entity associated with the identification information from at least one pre-defined interface simulation entity; In response to the existence of an interface simulation entity associated with the identification information, the interface simulation entity associated with the identification information is determined as the target interface simulation entity corresponding to the network service request.
4. The method according to any one of claims 1-3, characterized in that, The step of determining the simulated response result corresponding to the request model object by simulating an entity using the target interface based on the request model object includes: Obtain the request parameters corresponding to the request model object from the request model object; Based on the request parameters, the executable method defined in the target interface simulation entity is called to obtain the simulation response result corresponding to the request model object.
5. The method according to any one of claims 1-3, characterized in that, In the case where the target interface simulation entity exists, determining the simulated response result corresponding to the request model object based on the request model object and utilizing the target interface simulation entity includes: If the target interface simulation entity exists, its availability is determined based on its availability identifier; the availability identifier indicates whether the interface simulation entity is available or unavailable. If the target interface simulation entity is available, the simulation response result corresponding to the request model object is determined using the target interface simulation entity.
6. The method according to claim 5, characterized in that, Also includes: On the development and debugging page corresponding to the target application, at least one switch control button corresponding to an interface simulation entity is displayed; In response to the triggering operation of the switch control button, the availability flag corresponding to the interface simulation entity is changed.
7. The method according to any one of claims 1-3, characterized in that, The method further includes: generating an interface simulation entity; The interface simulation entity is embedded into the application package corresponding to the target application, so that the terminal device that installs the target application package can execute request responses based on the interface simulation entity.
8. A request-response device, characterized in that, include: The first determining module is configured to, in response to receiving a network service request initiated by a target application at the business logic layer of a terminal device, determine whether there exists a target interface simulation entity corresponding to the network service request based on the request model object indicated by the network service request; the target interface simulation entity is used to simulate the response result returned by the data access layer of the terminal device through the interface corresponding to the network service request; wherein, the request model object is represented as a first set of structured request data; The second determining module is used to determine the simulated response result corresponding to the request model object based on the request model object and using the target interface simulation entity when the target interface simulation entity exists. The first generation module is used to generate a simulated response model object corresponding to the request model object based on the simulated response result, and to call back the simulated response model object to the business logic layer so that the target application can perform the operation corresponding to the network service request according to the received simulated response model object; wherein, the simulated response model object represents a second set of structured request data, and the simulated response model object adopts the same modeling method as the request model object.
9. A computer device, characterized in that, include: A processor and a memory, the memory storing machine-readable instructions executable by the processor, the processor executing the machine-readable instructions stored in the memory, wherein when the machine-readable instructions are executed by the processor, the processor performs the steps of a request-response method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a computer device, performs the steps of a request-response method as described in any one of claims 1 to 7.
Citation Information
Patent Citations
Interface calling method and device, and computer readable storage medium
CN113722020A