CN119946033A

CN119946033A - Communication method, device, electronic device and computer readable storage medium

Info

Publication number: CN119946033A
Application number: CN202510004318.5A
Authority: CN
Inventors: 吴利青
Original assignee: Zhejiang Geely Holding Group Co Ltd; Zhejiang Zeekr Intelligent Technology Co Ltd
Current assignee: Zhejiang Geely Holding Group Co Ltd; Zhejiang Zeekr Intelligent Technology Co Ltd
Priority date: 2025-01-02
Filing date: 2025-01-02
Publication date: 2025-05-06

Abstract

The present application provides a communication method, device, electronic device and computer-readable storage medium. The communication method includes: receiving a first HTTP request based on a web interface, the first HTTP request is used to request to view the information of the target object in the service; in response to the first HTTP request, obtaining the information of the target object from the service; serializing the information of the target object according to the target data format supported by the web interface; sending a first HTTP response based on the web interface, the first HTTP response contains the serialized information of the target object. Viewing the target object information in the service through the web interface can make it easy for testers to obtain the target object information in the service, thereby improving the convenience of testing.

Description

Communication method, communication device, electronic equipment and computer readable storage medium

Technical Field

The present application relates to the field of communications, and in particular, to a communication method, apparatus, electronic device, and computer readable storage medium.

Background

In a system built based on a service-oriented architecture (service oriented architecture, SOA) and a micro-service software architecture approach, a large application is broken down into a set of small, function-independent services that coordinate and interwork with each other to provide complete functionality for users. In the test scene, whether the state information in the service process is correct or not is not easy to acquire in the service running process, so that the difficulty is increased for the problem investigation of the test. Therefore, how to improve the convenience of the test is a problem to be solved.

Disclosure of Invention

The embodiment of the application provides a communication method, a communication device, electronic equipment and a computer readable storage medium, so as to improve the convenience of testing.

In a first aspect, a communication method is provided, the method comprising receiving a first hypertext transfer protocol (hypertext transfer protocol, HTTP) request based on a web interface, the first HTTP request being used for requesting to view information of a target object in a service, obtaining the information of the target object from the service in response to the first HTTP request, serializing the information of the target object according to a target data format supported by the web interface, and sending a first HTTP response based on the web interface, the first HTTP response containing the serialized information of the target object.

In one possible implementation, the first HTTP request includes a uniform resource locator (uniform resource locator, URL) registered for the target object, and the first HTTP request is requested in a GET manner.

In one possible implementation manner, the target object is a container object in the service, the information of the target object is information of a target element in the container object, and the response to the first HTTP request, the obtaining of the information of the target object from the service, including the response to the first HTTP request, looking up an element contained in the container object to determine an identification of the target element, and based on the identification of the target element, obtaining the information of the target object from the service.

In one possible implementation, the method further includes receiving a second HTTP request based on the web interface, the second HTTP request being for requesting a remote procedure call (remote procedure call, RPC) interface that invokes the service, sending an RPC request to the service via the RPC interface based on the second HTTP request to obtain RPC response information, serializing the RPC response information into the target data format, and sending a second HTTP response based on the web interface, the second HTTP response including the serialized RPC response information.

In one possible implementation, the second HTTP request includes a URL registered for the RPC interface, and the second HTTP request is requested in a POST.

In one possible implementation manner, the sending the RPC request to the service through the RPC interface based on the second HTTP request includes obtaining a header and a body of the RPC request from the second HTTP request, generating the RPC request according to the header and the body of the RPC request, and sending the RPC request to the service through the RPC interface.

In one possible implementation, the method further includes receiving a third HTTP request based on the web interface, the third HTTP request for invoking an event trigger, and invoking the event trigger in response to the third HTTP request to trigger a target event during the service run.

In one possible implementation, the third HTTP request includes a URL registered for the target event, and the request manner of the third HTTP request is POST.

In a second aspect, a test method is provided, the test method comprising sending an HTTP request, determining whether the function of the service matches an expected result based on a received HTTP response and/or a triggered target event, the HTTP response or the target event being obtained according to the method of the first aspect or any one of the possible implementations of the first aspect.

In a third aspect, a communication device is provided, the device comprising a receiving module for receiving a first HTTP request based on a web interface, wherein the first HTTP request is used for requesting to view information of a target object in a service, an obtaining module for responding to the first HTTP request and obtaining the information of the target object from the service, a processing module for serializing the information of the target object according to a target data format supported by the web interface, and a sending module for sending a first HTTP response based on the web interface, wherein the first HTTP response contains the serialized information of the target object.

In one possible implementation, the first HTTP request includes a URL registered for the target object, and the request manner of the first HTTP request is GET.

In one possible implementation manner, the device further comprises a second receiving module, a second sending module and a second processing module, wherein the second receiving module is used for receiving a second HTTP request based on the web interface, the second HTTP request is used for requesting to call an RPC interface of the service, the second sending module is used for sending the RPC request to the service through the RPC interface based on the second HTTP request so as to acquire RPC response information, the second processing module is used for serializing the RPC response information into the target data format, and the third sending module is used for sending a second HTTP response based on the web interface, and the second HTTP response contains the serialized RPC response information.

In one possible implementation manner, the device further comprises a third receiving module, a calling module and a triggering module, wherein the third receiving module is used for receiving a third HTTP request based on the web interface, the third HTTP request is used for calling an event trigger, and the calling module responds to the third HTTP request and calls the event trigger to trigger a target event in the service running process.

In a fourth aspect, a testing apparatus is provided, which includes a second sending module configured to send an HTTP request, and a determining module configured to determine, based on a received HTTP response and/or a triggered target event, whether a function of a service matches an expected result, where the HTTP response or the target event is obtained according to the method in the first aspect or any one of the possible implementation manners of the first aspect.

In a fifth aspect, an electronic device is provided, comprising a memory, and a processor configured to execute a program stored in the memory, to perform a method as described in any one of the first aspect or any one of the second aspect or any one of the possible implementation manners of the second aspect.

In a sixth aspect, a computer readable storage medium is provided, on which a code is stored, the code being for performing a method as described in the first aspect or any one of the possible implementations of the second aspect or the second aspect.

In a test scene, the embodiment of the application receives the HTTP request based on the web interface to acquire the target object information in the service, sequences the target object information and then sends the HTTP response through the web interface, so that the acquisition of the target object information in the service by a tester is easy, and the convenience of the test is improved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the related art, the drawings that are required to be used in the embodiments will be briefly described. It is to be understood that the drawings in the following description are only some embodiments of the present application and that other drawings may be derived from these drawings by one of ordinary skill in the art.

Fig. 1 is a flowchart of a method for acquiring target object information based on a web interface according to an embodiment of the present application.

Fig. 2 is a flowchart illustrating a process of acquiring target object information based on a web interface according to an embodiment of the present application.

Fig. 3 is an exemplary diagram of a service module for invoking an RPC interface based on a web interface according to an embodiment of the present application.

Fig. 4 is a flowchart of a method for invoking an RPC interface based on a web interface according to an embodiment of the present application.

Fig. 5 is a flowchart illustrating a procedure for retrieving an RPC interface based on a web interface according to an embodiment of the present application.

FIG. 6 is a flow chart of a method for retrieving event triggers based on a web interface provided by an embodiment of the present application.

FIG. 7 is a flowchart illustrating a process for retrieving event triggers based on a web interface according to an embodiment of the present application.

FIG. 8 is an exemplary diagram of testing based on a web interface provided by an embodiment of the present application.

Fig. 9 is a schematic structural diagram of a communication device according to an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present application, but not all embodiments. All other embodiments, which are derived by a person skilled in the art based on the embodiments of the application, fall within the scope of protection of the application.

In a system constructed based on an SOA and micro-service software architecture method, a large application is disassembled into a group of small, function independent services, and the services are mutually coordinated and matched to provide complete functions for users. In the test scene, whether the state information in the service process is correct or not is not easy to acquire in the service running process, so that the difficulty is increased for the problem investigation of the test. Therefore, how to improve the convenience of the test is a problem to be solved.

In view of the above problems, the related art proposes to view service internal information through a debugging tool. For example, the service internal information may be viewed through the debug tool gdb. However, the gdb needs to intercept and analyze the execution flow of the service, so that more service resources, such as CPU or memory, are consumed when viewing the internal information of the service by using the gdb. In addition, the debug tool requires the tester to know the service internal operating logic, which has a high usage threshold for the tester.

The related art also proposes to acquire service internal information by viewing log records. But too little logging may result in incomplete information. Detailed logging may result in an excessive amount of logging, requiring excessive service resources. Meanwhile, access to the service is often needed to acquire the log record, and the access process is complex.

Aiming at the problem of how to improve the convenience of the test, the embodiment of the application provides a method for acquiring the target object information in the service based on the HTTP request received by the web interface, and then transmitting the HTTP response through the web interface after serializing the target object information. Because the web interface can acquire the internal information of the service as required and acquire the current internal information of the service, historical data does not need to be saved, and therefore excessive service resources do not need to be occupied. Meanwhile, information in the service is acquired through the web interface, and various modes such as a command line, a browser and Postman can be acquired, so that the acquisition is simple, the internal operation logic of the service is not required to be known, and the mode is easy to use. In addition, serializing the target information in the service makes the information easier to view and understand by the tester. Therefore, the convenience of the test can be improved.

The communication method according to the embodiment of the present application will be described in more detail with reference to fig. 1.

In step S110, a first HTTP request is received based on the web interface.

The Web interface refers to a communication mode externally provided by a system or an application program. It allows the caller to exchange data and call functions via the internet.

The HTTP request may be used in various ways, for example, it may be information for requesting to view a target object in a service, it may be used for requesting to call a service interface, it may be used for requesting to call an event trigger, etc. For convenience of description, a request for requesting information of a target object in the view service is hereinafter referred to as a first HTTP request. The information of the target object may be any information that may be obtained from a service in a test scenario. For example, it may be service internal state information, configuration parameters, performance data, debug information, system logs, request counts or response times, etc. The information type of the target object is not limited herein.

The first HTTP request includes a uniform resource locator registered for the target object. URLs are network addresses used to identify and locate resources and may refer to various types of resources such as web pages, pictures, videos, files, and so on. The first HTTP request may be in the form of a GET. The GET is used to request that a particular resource be retrieved from a service. The target object information, taking service internal state information as an example, the first HTTP request may use/info/+ object name as URL.

In step S110, information of a target object is acquired from a service in response to a first HTTP request.

The target object may be organized in various ways, for example, a single object or a container object. The information of the single instance object is only one piece, such as configuration parameters or service internal state information. This related information is organized together to form a management object. A singleton object may include a global variable. For the acquisition of the single-instance object information, the URL and the single-instance object data collection processor can be bound, and the single-instance object information is acquired by using an interface. Container objects refer to a plurality of element objects of the same class contained within each container. When the target object is a container object within the service, the information of the target object is information of a target element within the container object. That is, when the target object is a container object within the service, information of the target object, that is, information of a target element within the container object is acquired from the service in response to the first HTTP request. An element refers to a single member object within a container object. For example, if the container object is a "user list," then each user is an element. An element typically contains a set of information that describes the characteristics or state of the element. A web interface is added to the container object that enumerates all of the service object information, through which all exposed element information can be referenced.

How the target element information within the container object is obtained from the service is described in detail below. There are various ways to obtain the target element information in the container object from the service, for example, when the number of the object elements in the container is not large, the information of all the target elements can be obtained at one time through one web interface. This way all information in the container can be obtained quickly and completely. When the number of elements in the container object is large, the data overload may be caused by acquiring the information of the target elements in all the container objects at one time, so that the convenience of testing can be improved by gradually acquiring the information of the target elements in a hierarchical manner. By hierarchically capturing information of target elements within container objects, a web interface can be defined for different levels and a data collection processor can be implemented. The hierarchical manner may be, for example, that the web interface of the first level may look at the element contained in the container object to determine the Identifier (ID) of the target element according to the first HTTP request. The identification of the target element is a value that is used to uniquely identify the target element in the container. The identification of the target elements allows the system to quickly retrieve, reference, and manipulate the elements of the target. The second level web interface may obtain information of the target object based on the identification of the target element determined by the first level web interface. For example, to obtain information of a target object in a container may be achieved by adding a container element ID in a URL or query parameter, e.g.,/info/users/123 or/info/usersid =123. The hierarchical acquisition of the container object information can effectively manage and access the information in the service, and avoid data overload caused by the one-time acquisition of the container object information, so that the convenience of testing can be improved.

The hierarchical method for acquiring the service internal object information is also suitable for the scene of multi-layer container nesting. Multi-level container nesting refers to the fact that container objects internally contain other container objects, and the internal container objects may contain more container objects, forming a multi-level nesting structure. This structure is similar to nesting of folders, where each folder may contain other folders, and possibly more folders. In the scene of hierarchical management of information, for example, under the condition of complex structure or unknown depth of containers, the nested containers are accessed step by step through a web interface, so that the information of a target object in service can be effectively searched and acquired, and the convenience of testing is improved.

In step S130, the information of the target object is serialized according to the target data format supported by the web interface.

The communication protocol used by the web interface is typically the HTTP protocol. The HTTP protocol requires that the data format be suitable for network transport. Serialization refers to converting information of a target object into a data format that is easy to view. There are a variety of data formats supported by the Web interface, such as JSON, XML, YAML, etc. Taking the JSON format as an example, the information of the target object may be serialized into the JSON format. The JSON is a lightweight data exchange format, supports different programming languages, is easy to view and understand, is beneficial to test staff to quickly position and solve the problem, and can improve the convenience of testing. There are various methods for serializing information of a target object. The following illustrates a serialization method by taking the serialization of information of a target object in service as JSON as an example. For example, the method can be used for supporting a structure body and JSON conversion of languages such as Java, golang and the like, can be used for defining a data structure by using a third-party tool such as protobuf and the like, can be used for generating the capability of the data structure code to be included in the JSON structure mutual conversion, and can also be used for completing format conversion by manually writing codes by means of a plurality of JSON libraries.

In step S140, a first HTTP response is sent based on the web interface.

The first HTTP response contains the serialized object information. The first HTTP response is sent to the caller over the web interface. The caller may determine a problem based on the received first HTTP response and process the service accordingly.

The method of obtaining information of a target object in a service through a web interface is described in detail above. The flow of obtaining information of a target object in a service through a web interface is illustrated in more detail below in conjunction with fig. 2.

The caller sends an HTTP request to the service, and the web port of the service starts processing after receiving the HTTP request. The service parses the HTTP request, including the request line (method, URL, HTTP version), etc. The service invokes different service information collectors according to the URL. The service information collector collects service information. Once the required service information is collected, the service generates an HTTP response. And the calling party receives the HTTP response, so that the information of the target object in the service is obtained.

The foregoing describes in detail that obtaining information of a target object in a service through a web interface may improve the convenience of testing. In some embodiments, the web interface may not only obtain target object information in the service, but may also invoke the RPC interface to facilitate testing. Since in a system of micro-service software architecture method components, multiple micro-services in a large application may involve and provide a set of application programming interfaces (application programming interface, APIs) for other services to use. The RPC interface allows remote communication between these services, which makes it as convenient to invoke other services as local functions. To ensure the performance of the interface, the communication between services is usually in a binary format, which is more efficient to transmit, but less readable. To ensure security of the interface, RPC communication typically adds identity and access management (IDENTITY AND ACCESS MANAGEMENT, IAM) controls so that only authorized services can access a particular interface, but this also creates a barrier to interface access under test. In addition, to call the RPC interface, an API software development kit (software development kit, SDK) based on a certain programming language corresponding to the RPC interface needs to be provided, but the test generally uses a relatively flexible programming language to trigger the interface call to complete the interface function test, and the mismatch between the API SDK programming language and the test programming language may cause the test personnel to become difficult to develop the test work.

In view of the above problem of testing with RPC interfaces, some solutions are proposed in the related art. For example, for the problem that the mismatch between the API SDK programming language and the test programming language may cause high test cost, the related art proposes to integrate the SDK code of the test service in the test code, and complete the interface function test by triggering the interface call in the test code. However, the SDK code of the integrated test service generally provides only a limited variety of programming languages, and the problem of high test cost caused by mismatching of the API SDK programming language and the test programming language still cannot be avoided. In addition, this approach does not bypass the IAM limitation, requires some additional processing to be performed, and presents a certain impediment to testing. Other related art proposes to erect an independent gateway service, and to convert the RPC interface into the HTTP interface through the gateway service. Since the HTTP interface can support almost all programming languages, the call to the interface can be completed through the HTTP interface regardless of the programming language used by the caller. However, this method has drawbacks such as the need to maintain an additional gateway service, the need to update the gateway service after the service interface is changed, and the inability to use in gateway-free scenarios such as local development. These above solutions, while improving the convenience of the test to some extent, increase the cost of the test. In order to improve the test convenience and reduce the test cost, the application provides a solution by calling the RPC interface through the web interface. Since the web interface calls the RPC interface without additional gateway services, the test cost can be saved. In addition, the test language can be freely selected by a web interface tester, so that the test difficulty caused by mismatching of the API SDK programming language and the test programming language can be avoided, and the test convenience is improved. Meanwhile, the web interface can be used for not performing IAM verification or easily constructing verification information by transmitting a verification token, so that the convenience of testing is improved.

Implementation of the web interface to invoke the RPC interface relies on some common components on the service. To facilitate understanding the process of the web interface calling the RPC interface, a brief description of the service modules in the service is provided below in conjunction with fig. 3. The service modules generally include an RPC service network module, an RPC request distributor, and an RPC request processor. The RPC service network module is configured to process the RPC request, including receipt, resolution, and response of the RPC request. The RPC request distributor is configured to route the RPC request to the PRC request processor. The RPC request processor is used for processing the RPC request and executing the responding business logic to generate RPC response information. Invoking the RPC interface through the web interface is equivalent to providing a set of web interfaces outside of the RPC interface. This requires the integration of a further set of service modules for the web interface into the service. The service modules of the Web interface comprise a Web service network module, a Web request distributor and a Web request processor. The web services network module is used to process HTTP requests, which includes the receipt, resolution, and response of HTTP requests. The web request dispatcher is for routing HTTP requests to the PRC request processor. The web request processor is configured to process the HTTP request and execute the responsive business logic and generate an HTTP response.

The method for calling the RPC interface through the web interface according to the embodiment of the present application is described in more detail below with reference to fig. 4.

In step S410, a second HTTP request is received based on the web interface.

The HTTP request may be used to request an RPC interface that invokes a service based on the web interface receiving the HTTP request. For convenience of description, an HTTP request for requesting an RPC interface for calling a service will be hereinafter referred to as a second HTTP request.

The second HTTP request may include a URL registered for the RPC interface. The RPC interface call may use/RPC/+ interface name as URL. The second HTTP request may be in the form of a POST. POST is suitable for sending data to a service.

In step S420, an RPC request is sent to the service through the RPC interface based on the second HTTP request to acquire RPC response information.

Based on the second HTTP request, sending the RPC request to the service through the RPC interface comprises obtaining a header and a body of the RPC request from the second HTTP request, generating the RPC request according to the header and the body of the RPC request, and sending the RPC request to the service through the RPC interface. When the service receives the second HTTP request, the header and body of the RPC request are passed through the header and body of the second HTTP request. The service generates the RPC request after receiving the header and body of the RPC request.

The RPC interface may be implemented in a variety of ways, for example, by defining a service interface via an interface definition language (INTERFACE DESCRIPTION LANGUAGE, IDL). IDLs are data structures that describe the method, request, and response of a service, and may provide specifications for the implementation and invocation of the service. The IDL is used to define a service interface, and then a service framework can be generated by a framework tool with IDL files as input. The service framework binds the mapping between the requests and the processors. The binding of the URL of the RPC interface to the corresponding URL handler may be automatically generated by the extension framework tool. The binding of the URL of the RPC interface to the corresponding URL handler can be achieved by manual encoding, which cannot be extended by the framework.

In step S430, the RPC response information is serialized into a target data format. The target data format is an easy to view data format. The data format may be JSON, XML, YAML, for example. Taking JSON as an example, the response of RPC is generally in binary format, and JSON format is based on text format, which is easy to view and understand. Therefore, the RPC response information is serialized into the JSON format, which is helpful for testers to quickly locate and solve the problem, and the convenience of the test can be improved.

In step S440, a second HTTP response is sent based on the web interface. The serialized RPC response information may be sent back to the caller through the body of the HTTP response. The second HTTP response may also contain some common parameters that track the identity of the network request path, such as trace_id, etc. The public parameters may be sent back to the caller through the header of the HTTP response.

The method of invoking the RPC interface via the web interface is described in detail above. The flow of invoking the RPC interface via the web interface is illustrated in more detail below in conjunction with fig. 5.

The service receives a second HTTP request from the caller. After receiving the second HTTP request, the URL of the request, the request parameters, the header and the body of the HTTP request begin to be parsed. The service obtains the RPC interface to be invoked according to the URL and the request parameters or header of the second HTTP request. The service parses the body of the HTTP request to obtain the body of the RPC request. The service uses the RPC message distributor to route the RPC request to the processor of the RPC interface. The RPC interface processor processes after receiving the RPC request. After the process is completed, the service sequences the RPC response information into an HTTP response. The service sends an HTTP response back to the caller.

In a test scenario, in addition to the RPC interface that needs to obtain service internal information or invoke a service, in some embodiments, it is also necessary to monitor or trigger events to ensure that the service can respond correctly. The related art proposes to simulate triggering by a tool or triggering by real environment operation, but such triggering operation is complicated and has high operation cost. Because the web interface can call the event trigger through the command line, the browser, postman and the like, the event trigger can be simulated without complex operation, and therefore, the convenience of testing can be improved.

The method for simulating event triggering by calling an event trigger through a web interface according to the embodiment of the present application is described in more detail below with reference to fig. 6.

In step S610, a third HTTP request is received based on the web interface. The third HTTP request may be used to invoke an event trigger. The types of events are various, and may be, for example, user behavior, system state change, external signals, and the like. The event URL may be defined by defining the required events according to the test requirements, listing the event list to be simulated. The defined event URL binds with the event trigger to simulate event generation and trigger the corresponding processing logic of the event. For convenience of description, the HTTP request for calling the event trigger will be hereinafter referred to as a third HTTP request. The third HTTP request includes a URL registered for the target event. The URL may include/event/+ event name. The request manner of the third HTTP request may be POST. POST is used to submit data to a service.

In step S620, in response to the third HTTP request, an event trigger is invoked to trigger a target event during service execution.

In service, defined event URLs are mapped to corresponding event triggers. Thus, when the service receives an HTTP request for a particular URL, it knows which event trigger to invoke.

Optionally, in some embodiments, the web interface may invoke an event trigger custom event. Custom events may enable event triggering for certain specific scenarios, such as may simulate periodic triggering events. Therefore, the operation cost of the tester can be reduced, and the convenience of the test is improved.

Optionally, in some embodiments, the web interface of the custom event may combine the web interface for obtaining the target information in the service to obtain some new capabilities, such as simulating the periodic trigger event and monitoring the service state, which may further reduce the operation cost of the tester and improve the convenience of the test.

The method of simulating event triggers through a web interface is described in detail above. The process of simulating event triggers through a web interface is illustrated in more detail below in conjunction with fig. 7.

The web interface receives the HTTP request. The service, upon receiving the HTTP request, parses the URL and other information of the HTTP request. Each URL corresponds to a responsive event or processing logic. The service will invoke the corresponding event trigger based on the URL of the request. The event trigger simulates an actual event and performs a predetermined operation. After the event processing is completed, the system generates an HTTP response and sends the HTTP response back to the caller.

An embodiment of the present application is described in more detail below in conjunction with fig. 8. It should be noted that this example is merely to aid one skilled in the art in understanding the embodiments of the present application and is not intended to limit the embodiments of the present application to the specific types or scenarios illustrated. Various equivalent modifications or variations will be apparent to those skilled in the art from the examples given below, and such modifications or variations are intended to be within the scope of embodiments of the present application.

The Web interface receives the HTTP request. The service, upon receiving the HTTP request, parses the URL and other information of the HTTP request. The service determines the HTTP request type based on the URL of the HTTP request and other information. If the web interface receives the first HTTP request, the service collects service related information and sequences the information and returns the information to the client calling party as response information. If the web interface receives not only the first HTTP request but also the second HTTP request, the service not only collects service related information and sequences the information and returns a response, but also calls the RPC interface to complete the second HTTP request to the RPC request, the RPC request distribution and the RPC request processing and returning response. If the web interface receives not only the first HTTP request but also the third HTTP request, the service not only collects service related information and sequences the information and returns a response, but also calls an event trigger to simulate event triggering and returns a response according to the third HTTP request.

The scheme of viewing the target object information in the service based on the web interface, the scheme of calling the RPC interface of the service based on the web interface, and the scheme of calling the event trigger based on the web interface are respectively described in detail above. The technical scheme can be used independently to improve the convenience of the test, and can also be combined arbitrarily to improve the convenience of the test. It should be understood that the above-mentioned individual technical solutions or any combination technical solutions belong to the protection solutions of the embodiments of the present application.

Optionally, the embodiment of the application also provides a testing method. The test method comprises the steps of sending an HTTP request, and determining whether the function of the service is matched with an expected result or not based on the received HTTP response and/or a triggered target event, wherein the HTTP response or the target event can be obtained according to the communication method in any one of the previous embodiments. The function of a service may refer to a specific operation or task that the service should perform or a precondition for the service configuration, etc. The expected result may refer to an output result or state that the tester expects to be after the service performs its function. The test method is used for determining whether the function of the service is matched with the expected result, so that a tester can conveniently verify whether the service works normally according to the design or the requirement.

Method embodiments of the present application are described in detail above in connection with fig. 1-8, and apparatus embodiments of the present application are described in detail below. It is to be understood that the description of the device embodiments corresponds to the description of the method embodiments, and that parts not described in detail can therefore be seen in the preceding method embodiments.

The embodiment of the application also provides a communication device, as shown in fig. 9, which comprises a receiving module 910, an obtaining module 920, a processing module 930 and a sending module 940. The receiving module 910 is configured to receive a first HTTP request based on a web interface, where the first HTTP request is used to request to view information of a target object in a service, the obtaining module 920 is configured to obtain information of the target object from the service in response to the first HTTP request, the processing module 930 is configured to serialize the information of the target object according to a target data format supported by the web interface, and the sending module 940 is configured to send a first HTTP response based on the web interface, where the first HTTP response includes the serialized information of the target object.

Optionally, in some embodiments, the first HTTP request includes a URL registered for the target object, and the first HTTP request is requested in a GET.

Optionally, in some embodiments, the target object is a container object in the service, the information of the target object is information of a target element in the container object, and the responding to the first HTTP request obtains the information of the target object from the service, including responding to the first HTTP request, looking up an element contained in the container object to determine an identification of the target element, and obtaining the information of the target object from the service based on the identification of the target element.

Optionally, in some embodiments, the device further comprises a second receiving module, a second sending module and a second processing module, wherein the second receiving module is used for receiving a second HTTP request based on the web interface, the second HTTP request is used for requesting to call an RPC interface of the service, the second sending module is used for sending the RPC request to the service through the RPC interface based on the second HTTP request so as to acquire RPC response information, the second processing module is used for serializing the RPC response information into the target data format, and the third sending module is used for sending a second HTTP response based on the web interface, and the second HTTP response contains the serialized RPC response information.

Optionally, in some embodiments, the second HTTP request includes a URL registered for the RPC interface, and a request manner of the second HTTP request is POST.

Optionally, in some embodiments, the sending an RPC request to the service through the RPC interface based on the second HTTP request includes obtaining a header and a body of the RPC request from the second HTTP request, generating the RPC request according to the header and the body of the RPC request, and sending the RPC request to the service through the RPC interface.

Optionally, in some embodiments, the device further comprises a third receiving module, configured to receive a third HTTP request based on the web interface, wherein the third HTTP request is used for calling an event trigger, and a calling module, responsive to the third HTTP request, is configured to call the event trigger to trigger a target event in the service running process.

Optionally, in some embodiments, the third HTTP request includes a URL registered for the target event, and a request manner of the third HTTP request is POST.

The embodiment of the application also provides a testing device, which comprises a second sending module and a determining module, wherein the second sending module is used for sending an HTTP request, and the determining module is used for determining whether the function of the service is matched with an expected result or not based on the received HTTP response and/or the triggered target event, and the HTTP response or the target event is obtained according to the communication method in any embodiment.

The embodiment of the application also provides electronic equipment which comprises a memory and a processor. The processor is configured to execute the program stored in the memory to perform the method described in any of the previous embodiments.

Embodiments of the present application also provide a computer-readable storage medium having stored thereon code for performing the method described in any of the previous embodiments.

It should be understood that in embodiments of the present application, "B corresponding to a" means that B is associated with a, from which B may be determined. It should also be understood that determining B from a does not mean determining B from a alone, but may also determine B from a and/or other information.

It should be understood that the term "and/or" is merely an association relationship describing the associated object, and means that three relationships may exist, for example, a and/or B, and that three cases, a alone, a and B together, and B alone, may exist. In addition, the character "/" herein generally indicates that the front and rear associated objects are an "or" relationship.

It should be understood that, in various embodiments of the present application, the sequence numbers of the foregoing processes do not mean the order of execution, and the order of execution of the processes should be determined by the functions and internal logic thereof, and should not constitute any limitation on the implementation process of the embodiments of the present application.

In the several embodiments provided by the present application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, produces a flow or function in accordance with embodiments of the present application, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computer, service, or data center to another website, computer, service, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line (digital subscriber Line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be read by a computer or a data storage device such as a service, data center, or the like that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital versatile disk (digital video disc, DVD)), or a semiconductor medium (e.g., solid State Disk (SSD)), etc.

The foregoing is merely illustrative of the present application, and the present application is not limited thereto, and any person skilled in the art will readily recognize that variations or substitutions are within the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A communication method, characterized in that the method comprises:

Receiving a first HTTP request based on a web interface, where the first HTTP request is used to request to view information of a target object in a service;

In response to the first HTTP request, obtaining information of the target object from the service;

Serializing the information of the target object according to the target data format supported by the web interface;

A first HTTP response is sent based on the web interface, where the first HTTP response includes serialized information of the target object.

2. The method according to claim 1 is characterized in that the first HTTP request includes a URL registered for the target object, and the request mode of the first HTTP request is GET.

3. The method according to claim 1, wherein the target object is a container object in the service, and the information of the target object is information of a target element in the container object.

The step of obtaining the target object information from the service in response to the first HTTP request includes:

In response to the first HTTP request, checking the elements contained in the container object to determine the identifier of the target element;

Based on the identifier of the target element, information of the target object is obtained from the service.

4. The method according to any one of claims 1 to 3, characterized in that the method further comprises:

Receiving a second HTTP request based on the web interface, where the second HTTP request is used to request to call the RPC interface of the service;

Based on the second HTTP request, sending an RPC request to the service through the RPC interface to obtain RPC response information;

Serializing the RPC response information into the target data format;

A second HTTP response is sent based on the web interface, wherein the second HTTP response includes the serialized RPC response information.

5. The method according to claim 4 is characterized in that the second HTTP request includes a URL registered for the RPC interface, and the request mode of the second HTTP request is POST.

6. The method according to claim 4, wherein the sending of the RPC request to the service through the RPC interface based on the second HTTP request comprises:

Obtaining a header and a body of the RPC request from the second HTTP request;

Generate the RPC request according to the header and body of the RPC request;

An RPC request is sent to the service through the RPC interface.

7. The method according to any one of claims 1 to 3, characterized in that the method further comprises:

receiving a third HTTP request based on the web interface, wherein the third HTTP request is used to invoke an event trigger;

In response to the third HTTP request, the event trigger is called to trigger a target event during the operation of the service.

8. The method according to claim 7, characterized in that the third HTTP request includes a URL registered for the target event, and the request mode of the third HTTP request is POST.

9. A testing method, characterized in that the testing method comprises:

Send HTTP request;

Determine whether the function of the service matches the expected result based on the received HTTP response and/or the triggered target event, wherein the HTTP response or the target event is obtained according to the communication method according to any one of claims 1-8.

10. A communication device, characterized in that the device comprises:

A receiving module, configured to receive a first HTTP request based on a web interface, wherein the first HTTP request is used to request to view information of a target object in a service;

an acquisition module, configured to acquire information of the target object from the service in response to the first HTTP request;

A processing module, configured to serialize the information of the target object according to a target data format supported by the web interface;

A sending module is used to send a first HTTP response based on the web interface, wherein the first HTTP response includes serialized information of the target object.

11. A testing device, characterized in that the testing device comprises:

The second sending module is used to send HTTP requests;

A determination module is used to determine whether the function of the service matches the expected result based on the received HTTP response and/or the triggered target event, wherein the HTTP response or the target event is obtained according to the communication method according to any one of claims 1-8.

12. An electronic device, comprising:

Memory;

A processor, configured to execute the program stored in the memory to perform the method according to any one of claims 1 to 9.

13. A computer-readable storage medium, characterized in that a code is stored on the computer-readable storage medium, and the code is used to execute the method according to any one of claims 1 to 9.