Method and apparatus for providing information

Abstract

This invention discloses a method for an electronic device to provide information. Specifically, the method for an electronic device to provide information may include: receiving identification information and an inbound API request from a terminal; confirming the analog type corresponding to the terminal based on at least one of the identification information and the inbound API request; confirming an outbound API request based on the inbound API request; transmitting the outbound API request to at least one of an analog data server and a service data server based on the analog type; receiving an inbound API response corresponding to the outbound API request; and transmitting at least a portion of the inbound API response to the terminal.

Description

Technical Field

[0001] The embodiments of this specification relate to a method and apparatus for providing information. More specifically, the embodiments of this specification relate to a method and apparatus for providing information to a user by simulating an API request or API response based on configuration information. Prior Art

[0002] Information exchange between the backend and frontend can be implemented using an API (Application Programming Interface). Specifically, if an API request is made from the frontend to the backend, the backend can transmit the API response corresponding to the API request to the frontend.

[0003] On the other hand, it can be difficult for each user to consistently maintain a consistent understanding of the API requests and corresponding API responses for multiple users. Furthermore, when the backend or frontend services are not yet developed, or when the appropriate data is not available in the actual service database, it can be difficult for users to confirm whether they have received the API response that matches the API request. Therefore, there is a need to develop technology that can test services by modifying API requests or responses.

[0004] For related content, please refer to previous literature such as KR102163818B1 and KR102230272B1. Summary of the Invention

[0005] [Problems to be solved by the invention] The present invention is proposed to solve the above-mentioned problems, and its purpose is to provide a method and device for providing information.

[0006] More specifically, the present invention aims to provide a method and apparatus that can simulate either an API request or an API response to perform API-related testing by confirming the simulation type of the API request based on the API request received from the terminal and the corresponding setting information.

[0007] Furthermore, the present invention aims to provide a method and apparatus for more efficiently performing testing, which is configured to perform testing according to various scenarios, and can easily confirm its API request and API response information, and can share the information.

[0008] The technical issues to be achieved by the present invention are not limited to the above-mentioned issues, and other technical issues can be inferred from the following embodiments. [Technical means to solve the problem]

[0009] As a technical means for achieving the above-mentioned problem, according to the first aspect of the present invention, a method for an electronic device to provide information may include: a step of receiving identification information and an inbound API request for a terminal from a terminal; a step of confirming a mocking type corresponding to the terminal based on at least one of the identification information and the information of the inbound API request; a step of confirming an outbound API request based on the inbound API request; a step of transmitting an outbound API request to at least one of a mock data server and a service data server based on the mocking type; a step of receiving an inbound API response corresponding to the outbound API request; and a step of transmitting at least a portion of the inbound API response to the terminal.

[0010] According to one embodiment, the method for providing information may further include: storing at least one of an inbound API request, an outbound API request, an inbound API response, and at least a portion thereof in a data storage device.

[0011] According to one embodiment, the method for providing information may further include: providing a page including at least one of an inbound API request, an outbound API request, an inbound API response, and at least a portion thereof stored in a data storage device to a terminal.

[0012] According to one embodiment, the step of confirming the simulation type corresponding to the inbound API request may include: a step of confirming the object simulation data corresponding to the inbound API request based on the identification information and the information of the inbound API request; and a step of confirming the simulation type based on the setting information of the object simulation data.

[0013] According to one embodiment, the method for providing information is characterized in that the page includes a modification page of the simulation data included in the simulation data server, and based on the icon on the modification page, it is determined whether to apply the object simulation data corresponding to the inbound API request.

[0014] According to one embodiment, the step of transmitting the outbound API request may include: based on the simulation type, the step of identifying at least one server from among the simulation data server and the service data server to which the outbound API request is transmitted.

[0015] According to one embodiment, when the simulation type is type 1, the step of transmitting the outbound API request may include: the step of requesting the simulation data server to transmit the object simulation data corresponding to the inbound API request; the step of receiving the inbound API response may include: the step of confirming the object simulation data received from the simulation data server as the inbound API response.

[0016] According to one embodiment, when the simulation type is type 2, the step of transmitting the outbound API request may include: the step of transmitting the outbound API request to the service data server; the step of receiving the inbound API response may include: the step of updating the inbound API response based on the object simulation data corresponding to the inbound API request and confirming the updated inbound API response.

[0017] According to one embodiment, the object simulation data is data used to update an inbound API response, and the object simulation data includes at least one of information about a field of the updated object and information about a field value in the inbound API response.

[0018] According to one embodiment, when the simulation type is type 3, the step of transmitting the outbound API request may include: modifying the header of the outbound API request based on the information of the object simulation data corresponding to the inbound API request and confirming the modified outbound API request; and transmitting the modified outbound API to the service data server.

[0019] According to one embodiment, when the simulation type is type 4, the step of transmitting the outbound API request may include: the step of modifying the data of the outbound API request based on the information of the object simulation data corresponding to the inbound API request and confirming the modified outbound API request; and the step of transmitting the modified outbound API request to the service data server.

[0020] The electronic device for providing information in the third aspect of the present invention may include: a transceiver; a storage device storing one or more instructions; and a processor, which receives identification information and an inbound API request of a terminal from a terminal, confirms a simulation type corresponding to the terminal based on at least one of the identification information and the information of the inbound API request, confirms an outbound API request based on the inbound API request, transmits the outbound API request to at least one of a mock data server and a service data server based on the simulation type, receives an inbound API response corresponding to the outbound API request, and transmits at least a portion of the inbound API response to the terminal.

[0021] The recording medium of the third aspect of the present invention is a non-transitory computer-readable recording medium that records a program for execution in a computer. [Effects of the Invention]

[0022] According to the embodiments of this specification, an electronic device can determine the corresponding simulation type for a terminal based on the terminal's identification information and information from an inbound API request. Based on the simulation type, simulated API requests or responses can be used to test undeveloped backend or frontend services using simulated data.

[0023] The effects of the invention are not limited to the effects mentioned above. Ordinary technicians in the technical field can clearly understand other effects not mentioned based on the description of the invention patent application scope. Simple diagram description

[0024] FIG. 1 is a diagram of an information providing system for illustrating a method for providing information by an electronic device according to various embodiments. FIG2 is a flow chart showing a method for providing information according to an embodiment. FIG3 is a diagram for more specifically illustrating an information providing system according to an embodiment. FIG4 is a flow chart of an embodiment of confirming an inbound API response when the simulation type of the inbound API request is type 1. FIG. 5 a is a diagram for explaining the process of purchasing the first item through the detail page of the first item in the terminal. 5b is a diagram of a page including at least one of an inbound API request, an outbound API request, an inbound API response, and at least a portion thereof. FIG. 5 c is a diagram illustrating an embodiment of setting simulation data corresponding to an inbound API request. FIG5 d is a diagram showing a modified page of simulation data. FIG. 5e is a diagram showing a simulation data setting page corresponding to the target simulation data. FIG5f is a diagram showing the process of a terminal user editing object simulation data. FIG5g is a diagram showing a correction page of simulation data. FIG5h is a diagram for explaining the result of purchasing the first item through the detail page of the first item in the terminal when the simulation type is the first type. FIG. 6 a is a diagram showing an embodiment in which a user of a terminal edits object simulation data. FIG6 b is a diagram for explaining the result of purchasing the first item through the detail page of the first item in the terminal when the simulation type is the first type. FIG. 7 is a diagram illustrating an embodiment of confirming an inbound API response when the simulation type of the inbound API request is type 2. FIG8a is a diagram showing the process of a terminal user editing object simulation data. FIG8b is a diagram for explaining an embodiment of updating an inbound API response according to code content of the source code of the object simulation data. 9a and 9b are diagrams for explaining an embodiment of confirming an inbound API response when the simulation type of the inbound API request is type 3 or type 4. FIG. 10 is a diagram for explaining in detail a correction page of simulation data. FIG. 11 is a schematic block diagram of an electronic device for providing information according to an embodiment. Implementation Method

[0025] The terms used in the examples are selected from commonly used terms, as much as possible, taking into account the functions of the present invention. However, they may vary depending on the intentions of those skilled in the art, previous cases, the emergence of new technologies, and so on. Furthermore, in certain cases, the applicant may arbitrarily select terms. In such cases, their meanings will be detailed in the corresponding description. Therefore, the terms used in this invention should be defined based on their meanings and the overall content of the invention, rather than simply based on their names.

[0026] Throughout this specification, when a section is described as "including" a certain component, this means that, unless otherwise stated, other components may be included, and does not exclude other components. Furthermore, terms such as "unit" and "module" used in this specification refer to a unit that performs at least one function or operation and may be implemented by hardware, software, or a combination of hardware and software.

[0027] The expression "at least one of a, b and c" recorded throughout the specification may include "a alone", "b alone", "c alone", "a and b", "a and c", "b and c" or "all of a, b, and c".

[0028] The "terminal" mentioned below can be a computer or portable terminal connected to a server or other terminal via a network. Computers include notebooks, desktops, and laptops equipped with web browsers. Portable terminals, as wireless communication devices that ensure portability and mobility, include communication terminals based on IMT (International Mobile Telecommunication), CDMA (Code Division Multiple Access), W-CDMA (W-Code Division Multiple Access), and LTE (Long Term Evolution), as well as all types of handheld wireless communication devices such as smartphones and tablets.

[0029] The following will describe the embodiments of the present invention in detail with reference to the accompanying drawings so that those skilled in the art can easily implement the invention. However, the present invention can be implemented in various forms and is not limited to the embodiments described herein.

[0030] Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

[0031] In the description of the embodiments, descriptions of technical contents that are well known in the technical field to which the present invention belongs and are not directly related to the present invention will be omitted. By omitting unnecessary descriptions, the main points of the present invention are conveyed more clearly and specifically.

[0032] For similar reasons, some components are exaggerated, omitted, or shown schematically in the accompanying drawings. Furthermore, the sizes of the components do not necessarily reflect their actual sizes. Identical or corresponding components in the various drawings are denoted by the same reference numerals.

[0033] The advantages and features of the present invention, as well as the methods for achieving these advantages and features, will be more readily apparent with reference to the accompanying drawings and the embodiments described below. However, the present invention is not limited to the embodiments disclosed below and can be implemented in a variety of different forms. These embodiments are provided solely to fully disclose the present invention and to fully inform those skilled in the art of the invention of its scope. The present invention is defined solely by the scope of the claims. Throughout this specification, identical reference numerals refer to identical components.

[0034] At this point, it is understood that the combination of each block in the process flow chart and the flowchart can be implemented using computer program instructions. Since these computer program instructions can be installed on a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, the instructions, when executed by the processor of the computer or other programmable data processing device, generate means for performing the functions described in the flow chart blocks. To achieve the functions in a specific manner, these computer program instructions can also be stored in a computer-usable or computer-readable memory of a computer or other programmable data processing device, thereby also producing an article of manufacture containing instructions for performing the functions described in the flow chart blocks. Since the computer program instructions can also be installed on a computer or other programmable data processing device, executing a series of operating steps on the computer or other programmable data processing device generates a process executed by the computer, thereby executing the instructions on the computer or other programmable data processing device provides the steps for performing the functions described in the flow chart blocks.

[0035] Furthermore, each block may represent a module, segment, or portion of code that includes one or more executable instructions for performing a specific logical function. Furthermore, in some alternative implementations, it should be noted that the functions described in the blocks may occur out of order. For example, two blocks shown in succession may actually be executed simultaneously, or the blocks may sometimes be executed in the reverse order depending on the corresponding functions.

[0036] FIG. 1 is a diagram of an information providing system for illustrating a method for providing information by an electronic device according to various embodiments.

[0037] Referring to Figure 1 , various embodiments of the information provision system can be implemented using various devices. For example, the information provision system may include an electronic device 100, a terminal 110, an analog data server 120, and a service data server 130. The information provision system shown in Figure 1 only illustrates the components relevant to this embodiment. Therefore, those skilled in the art of the related art will understand that in addition to the components shown in Figure 1 , other general components may also be included.

[0038] The electronic device 100, terminal 110, analog data server 120, and service data server 130 may each include a transceiver, storage, and a processor. Furthermore, the electronic device 100, terminal 110, analog data server 120, and service data server 130 each refer to a unit that processes at least one function or operation, which may be implemented by hardware, software, or a combination of hardware and software. Furthermore, throughout the embodiments, the electronic device 100, terminal 110, analog data server 120, and service data server 130 are each referred to as a separate device or server, which may be a logically separate structure, at least part of which may be implemented by functions separated from a single device or server.

[0039] According to one embodiment, the electronic device 100, terminal 110, simulated data server 120, and service data server 130 may include multiple computer systems or computer software implemented by a network server. For example, at least a portion of the electronic device 100, terminal 110, simulated data server 120, and service data server 130 may refer to computer systems and computer software connected to lower-level devices capable of communicating with other network servers via a computer network such as an intranet or the Internet, accepting job execution requests, executing the jobs, and providing execution results. Furthermore, at least a portion of the electronic device 100, terminal 110, simulated data server 120, and service data server 130 may be understood in a broad sense to include a series of application programs operable on the network server and various databases constructed within or on other connected nodes. For example, at least a portion of the electronic device 100, the terminal 110, the simulation data server 120, and the service data server 130 may be implemented using various network server programs provided by operating systems such as DOS, Windows, Linux, UNIX, or MacOS.

[0040] The electronic device 100, terminal 110, analog data server 120, and service data server 130 can communicate with each other via a network (not shown). Networks include local area networks (LANs), wide area networks (WANs), value-added networks (VANs), mobile radio communication networks, and combinations thereof. These networks are comprehensive data communication networks that enable smooth communication between the various network components shown in FIG. 1. These networks can include wired internet, wireless internet, and mobile radio communication networks. Examples of wireless communication include, but are not limited to, wireless fidelity (Wi-Fi), Bluetooth, Bluetooth low energy (BLE), ZigBee, WFD (Wi-Fi Direct), UWB (ultra-wideband), infrared communication (IrDA), and NFC (Near Field Communication).

[0041] According to one embodiment, based on the function executed by terminal 110, electronic device 100 can receive an inbound API request corresponding to the function and terminal identification information. Furthermore, electronic device 100 can operate as a proxy server and transmit an outbound API request corresponding to the inbound API request to service data server 130. Therefore, electronic device 100 can receive an inbound API response corresponding to the outbound API request from service data server 130. However, to test against backend or frontend issues, it is necessary to correct erroneous elements in the API request and response. In this case, mock data for correcting erroneous elements in the API request and response can be stored in mock data server 120. Therefore, in this case, electronic device 100 can simulate API requests and responses based on target mock data corresponding to the erroneous elements to be corrected in the mock data stored in mock data server 120.

[0042] In this regard, the electronic device 100 of one embodiment receives identification information and an inbound API request of the terminal from the terminal 110, confirms the simulation type corresponding to the terminal based on at least one of the identification information and the information of the inbound API request, confirms the outbound API request based on the inbound API request, transmits the outbound API request to at least one of the simulation data server 120 and the service data server 130 based on the simulation type, receives an inbound API response corresponding to the outbound API request, and transmits at least a portion of the inbound API response to the terminal 110. Specific embodiments will be described in detail below.

[0043] FIG2 is a flow chart showing a method for providing information according to an embodiment.

[0044] 2 , it can be clearly understood that, regarding each operation of the electronic device 100 for providing information, a portion of the operations can be changed, replaced, or a portion of the order between the operations can be changed within the scope clearly understood by a person having common sense in the technical field to which the present invention belongs.

[0045] In step S210 , the electronic device 100 may receive identification information of the terminal 110 and an inbound API request from the terminal 110 .

[0046] According to one embodiment, terminal 110 may be an electronic device that performs various operations through applications, programs, and the like. Terminal 110 may be a mobile device or a computer, but is not limited to any particular type. Terminal 110 may transmit API request information corresponding to the function being executed by terminal 110 and identification information identifying terminal 110 to electronic device 100. The function may be performed using data obtained using the methods of the embodiments of this disclosure (which may be at least a portion of the incoming API response). For example, in an e-commerce application, as a detailed page for a specific product, terminal 110 may obtain a page containing images, price information, and discount information for the specific product in response to a connection request, thereby displaying a purchase page for the specific product. To display this page, the e-commerce service server may receive data from a database that manages the information displayed on the page and generate the page based on this data. Alternatively, this page may be generated on terminal 110 based on information provided by the e-commerce service server.

[0047] In this case, the identification information of terminal 110 can be a universally unique identifier (UUID) used to distinguish terminal 110 from other terminals. Therefore, the electronic device can confirm the identification information based on the UUID information obtained from terminal 110. The identification information can be a UUID, but is not limited to this. For example, the identification information can be the username of the requester.

[0048] In step S220, the electronic device 100 may confirm the emulation type corresponding to the terminal based on at least one of the identification information and the information of the inbound API request.

[0049] According to one embodiment, the electronic device 100 may identify the object emulation data corresponding to the inbound API request based on at least one of the identification information and the information of the inbound API request. More specifically, the electronic device 100 may identify the object emulation data corresponding to the inbound API request stored in the emulation data server 120 based on at least one of the identification information and the information of the inbound API request. Here, the object emulation data may include the same API URL information as the inbound API request and the identification information of the terminal 110 that transmitted the inbound API request. Specifically, the object emulation data configuration information included in the object emulation data may include the same API URL information as the inbound API request and the identification information of the terminal 110.

[0050] On the other hand, in an embodiment, the electronic device 100 may confirm the configuration information based on at least one of the identification information and the inbound API request to determine the emulation type. In an embodiment, the electronic device 100 may confirm the configuration information based on at least one of the identification information and the inbound API request to determine the emulation type corresponding to the configuration information, thereby determining the operation corresponding to the inbound API.

[0051] However, the operation of confirming the target simulation data is not limited to this. For example, if electronic device 100 receives an inbound API request from terminal 110, it may request simulation data server 120 to transmit simulation data corresponding to the identification information of terminal 110. Therefore, before confirming the simulation type corresponding to the terminal of electronic device 100, the simulation data corresponding to terminal 110 may be pre-stored in the memory of electronic device 100.

[0052] According to one embodiment, the electronic device 100 can determine the emulation type based on the configuration information of the target emulation data. More specifically, the electronic device 100 can determine the emulation type corresponding to the inbound API request based on the configuration information of the target emulation data. Therefore, even for inbound API requests received from the same terminal 110, the emulation type determined based on the corresponding target emulation data may be different. Here, the configuration information of the target emulation data can be information indicating that the emulation type corresponding to the inbound API request is one of Type 1, Type 2, Type 3, and Type 4.

[0053] On the other hand, based on the confirmed simulation type, the subsequent operation of the electronic device 100 can be determined.

[0054] In step S230, the electronic device 100 may confirm the outbound API request based on the inbound API request. For example, to obtain information corresponding to the API request requested by the terminal based on the inbound API request, the outbound API request may be transmitted via a specific service, and a portion of the information included therein may be stored in the electronic device 100. Therefore, the electronic device 100 may confirm the outbound API request corresponding to the inbound API request.

[0055] Here, the information of the inbound API request may include at least one of the URL (Uniform Resource Locator) information of the inbound API request, request header information, request data information, and the HTTP (Hyper Text Transfer Protocol) method information of the inbound API request.

[0056] In step S240 , the electronic device 100 may transmit an outbound API request to at least one of the simulation data server and the service data server based on the simulation type.

[0057] In step S250 , the electronic device 100 may receive an inbound API response corresponding to the outbound API request.

[0058] The specific operations of step S240 and step S250 vary depending on whether the simulation type is type 1, type 2, type 3, or type 4, and therefore will be introduced below according to the simulation type classification.

[0059] 1) The simulation type is Type 1 - full response simulation (full response mock).

[0060] According to one embodiment, if the emulation type is Type 1, the electronic device 100 may request the emulation data server to transmit the object emulation data corresponding to the inbound API request. Therefore, the electronic device 100 may receive the object emulation data from the emulation data server 120. Therefore, if the emulation type is Type 1, the electronic device 100 may omit the operation of transmitting the outbound API request to the service data server 130. Furthermore, if the object emulation data is already stored in the electronic device 100, the electronic device 100 may omit the operation of requesting the emulation data server to transmit the object emulation data corresponding to the inbound API request.

[0061] According to one embodiment, the electronic device 100 can confirm the object analog data through the inbound API response. Therefore, among the analog types, the first type can be a type characterized by completely replacing the inbound API response with the object analog data.

[0062] 2) The simulation type is type 2 - update response mock.

[0063] According to one embodiment, if the simulation type is type 2, the electronic device 100 may transmit an outbound API request to the service data server 130. Furthermore, in response to the outbound API request, the electronic device 100 may receive an inbound API request from the service data server 130. Furthermore, the electronic device 100 may request the simulation data server to transmit the object simulation data corresponding to the inbound API request. Thus, the electronic device 100 may receive the object simulation data from the simulation data server 120. Furthermore, if the object simulation data is already stored in the electronic device 100, the electronic device 100 may confirm it.

[0064] According to one embodiment, the electronic device 100 can update the inbound API response based on the object simulation data corresponding to the inbound API request and confirm the updated inbound API response. When the simulation type is Type 2, the object simulation data may include information used to update the inbound API response. More specifically, the object simulation data may include at least one of information regarding the fields of the updated object and information regarding the field values in the inbound API response. Furthermore, while the embodiments illustrate the example of updating information received from the service data server with information received from the simulation data server, a condition may be set such that only at least a portion of the information received from the simulation data server can be used to update information received from the service data server.

[0065] 3) The simulation type is type 3 – request header mock.

[0066] According to one embodiment, if the emulation type is Type 3, the electronic device 100 may modify the header of the outbound API request based on the information in the object emulation data corresponding to the inbound API request, thereby confirming the modified outbound API request. Consequently, the electronic device 100 may transmit the modified outbound API request to the service data server 130. Alternatively, in one embodiment, the header modification of the API request may be determined based on configuration information obtained from the user. This same configuration information may be configured in the electronic device 100 before the terminal generates the API request.

[0067] 4) The simulation type is type 4 – request data mock.

[0068] According to one embodiment, if the simulation type is Type 4, the electronic device 100 may modify the data of the outbound API request based on the information of the object simulation data corresponding to the inbound API request and confirm the modified outbound API request. Therefore, the electronic device 100 may transmit the modified outbound API request to the service data server 130. Alternatively, in one embodiment, the modification of the API request data may be determined based on configuration information obtained from the user. This configuration information may be configured in the electronic device 100 before the terminal generates the API request.

[0069] In step S260 , the electronic device 100 may transmit at least a portion of the inbound API response to the terminal.

[0070] According to one embodiment, the electronic device 100 may identify at least a portion of the inbound API response as an outbound API response and transmit it to the terminal 110 .

[0071] According to one embodiment, the electronic device 100 may store at least one of an inbound API request, an outbound API request, an inbound API response, and at least a portion (corresponding to an outbound API response) in a data storage device. The data storage device may be a storage device located inside or outside the electronic device 100.

[0072] According to one embodiment, the electronic device 100 may provide a page to the terminal 110 that includes at least one of an inbound API request, an outbound API request, an inbound API response, and at least a portion thereof stored in the data storage. Furthermore, the page may include a modification page for the simulation data stored in the simulation data server 120. Therefore, the user of the terminal 110 can confirm the object simulation data corresponding to the inbound API request on the modification page and edit the modified object simulation data using the modification page. Based on the object simulation data edited by the user of the terminal 110, the electronic device 100 can confirm the modified object simulation data corresponding to the inbound API request using the modification page.

[0073] FIG3 is a diagram for more specifically illustrating an information providing system according to an embodiment.

[0074] Referring to Figure 3 , various embodiments of the information provision system can be implemented using various devices. For example, the information provision system may include an electronic device 100, a terminal 110, an analog data server 120, a service data server 130, and a data storage device 300. The analog data server 120 may be a storage device within the electronic device 100 or a storage device external to the electronic device 100, but is not limited thereto.

[0075] The electronic device 100 can operate using Nginx as the electronic device for connecting API requests and responses in this case. The electronic device 100 can include a Java service and a mock agent. Specifically, the electronic device 100 can transmit an inbound API request including identification information to the mock agent via the Java service. Furthermore, the electronic device 100 can include a mock agent that simulates the inbound API request and the portion of the API response corresponding to the inbound API request that needs to be tested.

[0076] In step S301 , the electronic device 100 may receive identification information and an inbound API request from the terminal 110 .

[0077] In step S302, electronic device 100 may obtain simulation data from simulation data server 120. Furthermore, electronic device 100 may determine the simulation type corresponding to terminal 110 based on at least one of the identification information and the information in the inbound API request. Simulation data server 120 may be an open-source, non-relational database management system based on Redis (Remote Dictionary Server).

[0078] Specifically, the simulation agent included in the electronic device 100 can perform: 1) confirming whether there is object simulation data corresponding to the inbound API request; and 2) confirming the simulation type of the inbound API request when the object simulation data exists.

[0079] For example, the electronic device 100 can obtain simulation data stored in the simulation data server 120. Therefore, the electronic device 100 can confirm the target simulation data stored in the simulation data server 120 based on at least one of the identification information and the information in the inbound API request. Furthermore, the electronic device 100 can confirm the simulation type corresponding to the target simulation data. According to another embodiment, the electronic device 100 transmits the information and identification information of the inbound API request received from the simulation data server 120, and only obtains from the simulation data server 120 information corresponding to the information and identification information corresponding to the inbound API request. Therefore, the electronic device 100 can confirm the simulation type corresponding to the obtained target simulation data. For example, the electronic device 100 can confirm whether the simulation type in the inbound API request is Type 1, Type 2, Type 3, or Type 4.

[0080] In step S303 , the electronic device 100 may confirm the outbound API request corresponding to the inbound API request, and transmit the outbound API request to at least one of the service data server 130 and the simulation data server.

[0081] An API request (an API request may include an inbound API request and an outbound API request) may include URL (Uniform Resource Locator) information of the API request and HTTP protocol method information of the API request.

[0082] In step S304 , the electronic device 100 may receive an inbound API response corresponding to the outbound API request.

[0083] According to one embodiment, 1) when the simulation type of the inbound API request is one of Type 2, Type 3, and Type 4, the simulation agent included in the electronic device 100 may receive an inbound API response from the service data server 130. 2) when the simulation type of the inbound API request is Type 1, the simulation agent included in the electronic device 100 may not transmit an outbound API request to the service data server 130. In this case, the electronic device 100 can confirm the target simulation data through the inbound API response.

[0084] In step S305, the electronic device 100 may provide functionality to the terminal. More specifically, the electronic device 100 may provide functionality corresponding to the inbound API request based on the inbound API response. For example, the electronic device 100 may generate an e-commerce-related page corresponding to the API request based on information obtained from the service data server 130 and provide it to the terminal 110.

[0085] In step S306 , the simulation data server 120 may store the simulation data stored in the simulation data server 120 in the data storage 300 .

[0086] In step S307 , the electronic device 100 may store at least one of the inbound API request, the inbound API response, the outbound API request, and the outbound API response (corresponding to at least a portion of the inbound API response) in the data storage 300 .

[0087] In step S308, the electronic device 100 may provide a page 320 including at least one of the inbound API request, inbound API response, outbound API request, and outbound API response stored in the data storage 300 to the terminal 110. Furthermore, the electronic device 100 may provide a modification page 321 for editing simulation data including object simulation data.

[0088] In step S309, the electronic device 100 may modify the simulation data based on the user input of the terminal 110 on the modification page 321. More specifically, the user input of the terminal 110 on the modification page 321 may be input to edit the object simulation data corresponding to the inbound API request into the modified object simulation data.

[0089] In step S310, based on the information regarding the icon indicating whether to apply the simulated data, the electronic device 100 may determine whether to apply the simulated data. The user of the terminal 110 may determine whether to apply the object simulated data corresponding to the inbound API request by activating or deactivating the icon indicating whether to apply the object simulated data corresponding to the inbound API request on the modification page 321.

[0090] In step S311 , the electronic device 100 may have identification information different from that of the terminal 110 , or may provide the page 320 and the revised page 321 to the first terminal 330 of another user.

[0091] In this case, page 320 and modification page 321 can be provided to multiple developers. If a user uses terminal 110 to identify elements in an API request or response that require testing, an interface is provided that allows modification of these elements only within the user's operating environment. In the operating environments of multiple developers, it is necessary to provide the (original) API request and API response. However, multiple developers can also connect to the user's operating environment by entering the user's identification information into the list page. For example, if a user shares the identification information of terminal 110 with a first user using terminal 330, the first user can enter the identification information into page 320 or modification page 321 to connect to the user's operating environment.

[0092] FIG4 is a flow chart of an embodiment of confirming an inbound API response when the simulation type of the inbound API request is type 1.

[0093] In step S410 , the electronic device 100 may request the simulation data server to transmit the object simulation data corresponding to the inbound API request.

[0094] In this specification, the first type of simulation type for an inbound API request may be a type that completely replaces the inbound API response corresponding to the inbound API request with object simulation data. Typically, if the service data server 130 does not have an inbound API response corresponding to the inbound API request, the electronic device 100 may replace the inbound API response with the object simulation data.

[0095] In step S420 , the electronic device 100 may identify the object simulation data as an inbound API response.

[0096] According to one embodiment, the electronic device 100 may identify the object simulation data as an inbound API response. Specifically, if the simulation type of the inbound API request is Type 1, the electronic device 100 may not transmit the API request to the service data server 130. Furthermore, the electronic device 100 may display a page displaying the inbound API request and the inbound API response.

[0097] 5a, 5b, 5c, 5d, 5e, 5f, 5g, and 5h are diagrams illustrating an embodiment of confirming an inbound API response when the simulation type of the inbound API request is type 1.

[0098] FIG. 5 a is a diagram for explaining the process of purchasing the first item through the detail page of the first item in the terminal.

[0099] The user of terminal 110 can purchase the first item through the first item's detail page displayed on terminal 110. Page 500 is a purchase page for red vinegar made from pomegranates, the first item. In response to input via "Buy" icon 501 on terminal 110, terminal 110 can display a checkout page 502 for the first item. Checkout page 502 can be used to enter a review of the first item, a delivery destination, and a payment method.

[0100] Specifically, terminal 110 can transmit information regarding the execution of a specific function (e.g., linking to the checkout page 502 for the first item) and identification information identifying terminal 110 to electronic device 100. The electronic device 100 can then display the checkout page 502 using data obtained using the methods of the embodiments of the present invention. During the execution of the aforementioned function, electronic device 100 can receive at least one inbound API request corresponding to the function executed by terminal 110 from service data server 130. Furthermore, electronic device 100 can transmit an outbound API response corresponding to the inbound API request to terminal 110.

[0101] 5b is a diagram of a page including at least one of an inbound API request, an outbound API request, an inbound API response, and at least a portion thereof.

[0102] According to one embodiment, the electronic device 100 may provide a page 510 that includes at least one of an inbound API request, an outbound API request, an inbound API response, and at least a portion (outbound API response). Specifically, page 510 in FIG. 5 b may include an API request and an API response, where the API request corresponds to a link to the checkout page 502 for the first item on the fulfillment terminal 110.

[0103] Page 510 may include a plurality of inbound API requests corresponding to a link to the checkout page 502 for the first item in terminal 110. Specifically, page 510 may include inbound API requests indexed 1 to 5. Inbound API request 511 indexed 4 may be an API request with the API URL information "http: / / search-api.coupang.netapi / v2 / plv." Furthermore, page 510 may include an icon 512 as an entry point for linking to the detailed pages of the inbound API request and the corresponding outbound API request. Furthermore, page 510 may be a page including an API request and an API response, with the API request corresponding to "165300727500707623860509" 515, which is identification information used to distinguish terminal 110 from other terminals.

[0104] The user of terminal 110 can simulate an inbound API request 511 among the multiple inbound API requests displayed on page 510 to test the connection to the checkout page 502 for the first item on terminal 110. To do this, the user of terminal 110 can confirm the icon 513 corresponding to inbound API request 511 and then click "Save as Simulation Data" 514 at the top to connect to the configuration page for configuring the simulation data corresponding to inbound API request 511.

[0105] FIG. 5 c is a diagram illustrating an embodiment of setting simulation data corresponding to an inbound API request.

[0106] Settings page 520 includes fields for entering a project name 521, a scenario name 522, and a group name 523 for the simulation data corresponding to the inbound API request. As shown in Figure 5c, the user of terminal 110 can set project name 521 to "Project A," scenario name 522 to "Scene A," and group name 523 to "Coupang," and then click "Save" icon 524 for storing the simulation data. Consequently, the simulation data corresponding to the inbound API request is stored at the address with project name 521 set to "Project A," scenario name 522 set to "Scene A," and group name 523 set to "Coupang Test."

[0107] FIG5 d is a diagram showing a modified page of simulation data.

[0108] Modification page 530 may include fields for entering a project name 531, a scenario name 532, a group name 533, and identification information 534. For example, a user of terminal 110 may enter "Project A," "Scene A," "Coupang Test," and "165300727500707623860509," respectively. In response to the input, electronic device 100 displays object simulation data 535 corresponding to inbound API request 511 on modification page 530.

[0109] Referring to Figure 5d , the modification page 530 may include: 1) an icon 536 for editing object simulation data 535, and 2) an icon 537 indicating whether to apply the object simulation data. Here, the icon 537 indicating whether to apply the object simulation data is a slide button, indicating whether to simulate the object simulation data 535 in the inbound API request 511. Furthermore, if input is received via the icon 536 for editing the object simulation data 535 on the modification page 530, the electronic device 100 may provide a simulation data setting page for the object simulation data 535. In this case, the modification page 530 includes the term "simulation data setting page."

[0110] FIG. 5e is a diagram showing a simulation data setting page corresponding to the target simulation data.

[0111] Simulation data configuration page 540 may be a configuration page for the object simulation data corresponding to inbound API request 511 with index number 4 in FIG 5 b . Simulation data configuration page 540 may include information 541 regarding the API URL, information 542 regarding the method corresponding to the API response, information 543 regarding the simulation type, information 544 regarding the status corresponding to the API response, and information regarding the source code 545 for the simulation data.

[0112] For example, referring to the target simulation data settings page 540, API URL information 541 may correspond to the API URL of the inbound API request 511, whose API URL information is "http: / / search-api.coupang.netapi / v2 / plv." Furthermore, method information 542, simulation type information 543, and status information 544 corresponding to the API response may each be POST, type 1, and 200. Here, status information 544 corresponding to the API response being 200 may indicate that the outbound API request received from the service data server 130 was processed normally. If status information 400 is provided, it may indicate that the outbound API request is invalid and has not been processed by the service data server 130. Furthermore, the user of terminal 110 can select the simulation type corresponding to the inbound API request from one of type 1, type 2, type 3, and type 4 using the simulation type information 543 field.

[0113] The user of the terminal 110 can modify the provided source code 545 to comply with the test through the simulation data setting page 540. The relevant content will be introduced in Figure 5f below.

[0114] FIG5f is a diagram showing the process of a terminal user editing object simulation data.

[0115] 5F , the simulation data setting page 550 may be a page where the source code 545 corresponding to the target simulation data in the simulation data setting page 540 is changed to a modified source code 551 .

[0116] For example, when purchasing items via terminal 110, if the purchasing user is not a member, a minimum order amount can be set corresponding to the type of item being purchased. In this regard, source code 551 may include the following: 1) setting the minimum order amount for "fast-shipping" items to 19,800 KRW, 2) setting the minimum order amount for "fresh" items to 0 KRW, and 3) setting the minimum order amount for "global" items to 29,800 KRW.

[0117] After the user of terminal 110 changes source code 545 to source code 551, he or she may input the "save" icon on simulation data setting page 550. In response to the input on the "save" icon on simulation data setting page 550, electronic device 100 may edit the content of the target simulation data to match source code 551.

[0118] FIG5g is a diagram showing a correction page of simulation data.

[0119] The revision page 560 may be a revision page for the simulation data after the source code 551 is stored via the simulation data setting page 550 .

[0120] Based on whether the activation input is applied to the icon 561 of the object simulation data on the modification page 560 of the user input of the terminal 110 , the electronic device 100 may simulate the inbound API request 511 based on the object simulation data 562 .

[0121] FIG. 5 h illustrates the result of executing the function of displaying the checkout page 502 of the first item of the terminal 110 in response to the simulated inbound API request 511 based on the object simulation data 562 .

[0122] FIG5h is a diagram for explaining the result of purchasing the first item through the detail page of the first item in the terminal when the simulation type is the first type.

[0123] Page 571 is a purchase page for red vinegar made from pomegranates as the first item. In response to input from the terminal 110 via the "buy" icon 572 on page 571, the electronic device 100 may provide a result page 573.

[0124] The user of terminal 110 can edit source code 545 into source code 551. In addition, because the user of terminal 110 activated icon 561 for selecting whether to apply object simulation data in inbound API request 511, result page 573 may be different from page 502 in which object simulation data is not applied in inbound API request 511.

[0125] Specifically, the electronic device 100 may not transmit an outbound API request to the service data server 130 and may directly accept the object simulation data as an inbound API response. The object simulation data may include content that sets a minimum order amount based on the item type. In this regard, if the "pomegranate," the first item on page 571, is included in the "Fast Delivery" category, the electronic device 100 may first confirm whether the price of the first item is less than 19,800 KRW (the minimum order amount for "Fast Delivery" items). Therefore, if the price of the first item is less than 19,800 KRW, the terminal 110 may display a page corresponding to the result page 573.

[0126] More specifically, the result page 573 may include information 574 that the minimum order amount for the "fast delivery" item is 19,800 KRW and "can be purchased with an additional order of 6,450 KRW or more" 575.

[0127] Figures 5a, 5b, 5c, 5d, 5e, 5f, 5g, and 5h merely represent an embodiment of simulating an inbound API response based on object simulation data when the simulation type is type 1. The method of providing information in this case is not limited to this.

[0128] 6a and 6b are diagrams of other embodiments of confirming an inbound API response when the simulation type of the inbound API request is type 1.

[0129] FIG. 6 a is a diagram showing an embodiment in which a user of a terminal edits object simulation data.

[0130] 6 a , the simulation data setting page 600 may be a page where the source code 545 corresponding to the target simulation data of the simulation data setting page 540 is changed to a modified source code 602 .

[0131] Specifically, source code 602 may be the same source code as source code 551, namely: 1) setting the minimum order amount for "fast delivery" items to 19,800 KRW, 2) setting the minimum order amount for "fresh" items to 0 KRW, and 3) setting the minimum order amount for "global" items to 29,800 KRW.

[0132] However, the status information 601 of the simulation data setting page 600 is "500", which may be different from the status information "200" of the simulation data setting page 550. The status information 601 showing "500" may indicate that the server has an error and cannot execute the request.

[0133] Therefore, electronic device 100 can simulate an inbound API request corresponding to the object simulation data based on the object simulation data including status information 601 as "500." The following is a page showing the results of simulating an inbound API request corresponding to the object simulation data. In this case, simulation data includes not only the source code of the simulated simulation data but also configuration information for the simulation data (e.g., status information entered when configuring the simulation data).

[0134] FIG6 b is a diagram for explaining the result of purchasing the first item through the detail page of the first item in the terminal when the simulation type is the first type.

[0135] Page 620 is a purchase page for red vinegar made from pomegranates as the first item. In response to input from the terminal 110 via the "buy" icon 621 on page 620, the electronic device 100 may provide a result page 630.

[0136] The electronic device 100 can simulate an inbound API request based on the object simulation data including the status information 601 being "500." Specifically, the electronic device 100 can directly identify the object simulation data as an inbound API response without transmitting an outbound API request to the service data server 130. Therefore, the terminal 110 can display a result page 630 including a phrase 631 corresponding to the status information 601 being "500." The phrase 631, corresponding to the status information being "500," can include "An error occurred during the order. Please try again."

[0137] FIG. 7 is a diagram illustrating an embodiment of confirming an inbound API response when the simulation type of the inbound API request is type 2.

[0138] In step S710 , the electronic device 100 may transmit an outbound API request to the service data server.

[0139] In this specification, the second type of simulation type for an inbound API request may utilize object simulation data to update the inbound API response corresponding to the inbound API request. Typically, when the service data server 130 has prepared an inbound API response corresponding to an inbound API request but needs to modify a portion of the inbound API response, the electronic device 100 may utilize the object simulation data to update the inbound API response.

[0140] In step S720 , the electronic device 100 may receive an inbound API response corresponding to the outbound API request from the service data server.

[0141] In step S730, the electronic device 100 may update the inbound API response based on the object simulation data corresponding to the inbound API request and confirm the updated inbound API response. More specifically, the electronic device 100 may update the inbound API response according to various methods based on the setting information included in the object simulation data. For example, the information of the object simulation data may include at least one of information about a field to be updated in the inbound API response and information about a field value. 1) When the information of the object simulation data includes information about a field to be updated, the electronic device 100 may add or delete the field in the inbound API response. 2) When the information of the object simulation data includes information about a field value to be updated, the electronic device 100 may update the field value in the inbound API response.

[0142] FIG8a is a diagram showing the process of a terminal user editing object simulation data.

[0143] 8a , the electronic device 100 may provide a simulation data configuration page 800 for editing simulation data used when updating an incoming API response. Simulation data configuration page 800 may include information 801 about the API URL, information 802 about the method corresponding to the API response, information about the simulation type 803, information 804 about the status corresponding to the API response, and information 805 about the source code of the simulation data.

[0144] For example, referring to the simulation data setting page 800 for updating the object simulation data of the inbound API response, the API URL information 801 may correspond to the API URL of the inbound API request whose API URL information is "http: / / search-api.coupang.netapi / v2 / plv." Furthermore, the method information 802 corresponding to the API response, the simulation type information 803, and the status information 804 corresponding to the API response may each be POST, type 2, and 200. Here, the status information 804 corresponding to the API response is 200, indicating that the outbound API request received from the service data server 130 was processed normally. The source code 805 of the object simulation data may include information with the field value "test" appended to the test field.

[0145] The user of the terminal 110 may input the “Save” icon 806 on the simulation data setting page 800. In response to the input on the “Save” icon 806 on the simulation data setting page 800, the electronic device 100 may edit the content of the target simulation data to match the source code 805.

[0146] The user of the terminal 110 can activate an icon to determine whether to apply the object simulation data. Therefore, if the electronic device 100 receives an inbound API request, it can update the inbound API response based on the object simulation data.

[0147] Page 810 may be a page displaying the inbound API request and updated inbound API response information. More specifically, page 810 may be a page displaying the updated inbound API response. More specifically, page 810 may be a page displaying the "Request," "Request Header," and "Response" tabs, including a "Response" tab 811. Furthermore, the status information 812 on page 810 may be the same as the "200" status information 804 on the simulation data setup page 800.

[0148] Source code 813 on page 810 is the source code for updating the inbound API response. Specifically, source code 813 may be the source code for updating the inbound API response received from service data server 130 to object simulation data. Referring to FIG. 8a , it can be seen that in source code 813, the field value "test" has been added to the test field, a new field that did not exist before the object simulation data was applied.

[0149] FIG8b is a diagram for explaining an embodiment of updating an inbound API response according to code content of the source code of the object simulation data.

[0150] The first source code 820 may include code content that updates the field value of a field when a specific condition is met. More specifically, the first source code 820 may include code content that updates the field value of the 'maximumBuyForPerson' field to 7 when the 'match_request_data' condition is met. Therefore, if the field value of the 'context / userNo' field in the inbound API response is '12345678', the electronic device 100 may update the field value of the 'maximumBuyForPerson' field to 7. Conversely, if the field value of the 'context / userNo' field in the inbound API response is not '12345678', the electronic device 100 may maintain the field value of the 'maximumBuyForPerson' field at its original value.

[0151] Second source code 830 may be source code that updates the value of a field when a specific condition is met. More specifically, second source code 830 may update the value of the 'deliveryTypes' field to ['CHARGE_RECEIVED'] and the value of the 'deliveryChage' field to 0 when the 'update_condition' condition is met. Here, the 'update_condition' condition may include a first condition where 'path' is '? / vendorItem / vendorItemId' and a second condition where 'value' is '1234567890'.

[0152] The information of the fields to be updated included in the object simulation data may also include information of the conditions for the fields to be updated.

[0153] The third source code 840 may be a source code for deleting the field value of a field. Referring to FIG8b, the third source code 840 may delete the field values of field 1 and field 2 on the inbound API response.

[0154] Field 1:''0 / vendorItem / properties / PRE_ORDER_delete''

[0155] Field 2:''0 / vendorItem / properties / PRE_ORDER_START_AT_delete''

[0156] The fourth source code 850 may be a source code for adding items to the item list. For example, referring to FIG. 8B , the fourth source code 850 may be a source code for adding items "a" and "b" to the item list.

[0157] The fifth source code 860 may be a source code for deleting the code content of an item in the item list. For example, referring to FIG. 8b , the fifth source code 860 may be a source code for deleting the code content of items "a" and "b" in the item list.

[0158] 9a and 9b are diagrams for explaining an embodiment of confirming an inbound API response when the simulation type of the inbound API request is type 3 or type 4.

[0159] In this specification, the third type of impersonation type for an inbound API request can be a type that modifies the header of an outbound API request based on the object impersonation data. Furthermore, the fourth type of impersonation type for an inbound API request can be a type that modifies the data of an outbound API request based on the object impersonation data. Here, the data of an outbound API request can be the payload included in the outbound API request.

[0160] When it is necessary to test a problem on the front end, the electronic device 100 may simulate the header or data of an outbound API request based on the configuration information included in the object simulation data.

[0161] Specifically, when the emulation type is type 3, the electronic device 100 may modify the header of the outbound API request based on the information of the object emulation data corresponding to the inbound API request, confirm the modified outbound API request, and transmit the modified outbound API request to the service data server 130. Furthermore, when the emulation type is type 4, the electronic device 100 may modify the data of the outbound API request based on the information of the object emulation data corresponding to the inbound API request, confirm the modified outbound API request, and transmit the modified outbound API request to the service data server 130.

[0162] Page 900 may include at least one of an inbound API request, an outbound API request, an inbound API response, and at least a portion (of an outbound API response). Referring to FIG. 9 , page 900 shows a plurality of inbound API requests corresponding to the execution of a function by terminal 110. Specifically, referring to the icons on page 900 indicating whether to apply emulated data, the plurality of inbound API requests for which emulated data is applied may include a first inbound API request 901, a second inbound API request 902, a third inbound API request 903, a fourth inbound API request 904, and a fifth inbound API request 905. Upon input via the "View" icon 906 on page 900, the electronic device 100 may provide a detailed page 910 displaying not only the header and data of the first inbound API request, but also the inbound API response corresponding to the first inbound API request.

[0163] Detail page 910 of first inbound API request 901 may include request data 911, request header 912, and response 913 corresponding to first inbound API request 901. Referring to FIG. 9B , detail page 910 may be a page containing request data 911. The URL information on detail page 910 may correspond to the URL information of first inbound API request 901.

[0164] The user of terminal 110 can confirm the code content that needs to be modified in the parameter source code 915 and data (payload) source code 916 on the detail page 910. The user of terminal 110 can edit the object simulation data using the simulation data setting page similar to Figures 5f and 8a.

[0165] FIG. 10 is a diagram for explaining in detail a correction page of simulation data.

[0166] The user of terminal 110 corresponds the project name, scene name, group name and identification information to the inputs of "Project A", "Scene A", "Coupang Test" and "165300727500707623860509" respectively, and the correction page 1000 of the simulation data provided by the electronic device 100 is shown in Figure 10.

[0167] The simulation data modification page 1000 may include an icon 1010 for linking to a detailed modification page for the simulation data corresponding to the identification information of the terminal 110. In response to input via icon 1010 on the simulation data modification page 1000, the electronic device 100 may provide the detailed modification page for the simulation data. The detailed modification page may include an icon 1020 for selecting whether to apply the respective simulation data and an icon 1030 for selecting whether to lock the respective simulation data.

[0168] FIG. 11 is a schematic block diagram of an electronic device for providing information according to an embodiment.

[0169] The electronic device 1100 in FIG. 11 may correspond to the electronic device 100 in this specification.

[0170] According to one embodiment, the electronic device 1100 of the present invention may include a transceiver 1110, a processor 1120, and a storage device 1130. The components shown in FIG. 11 are not essential for implementing the electronic device. Therefore, those skilled in the art of the present invention will appreciate that the electronic device 1100 described herein may include more or fewer components than those listed above. Furthermore, in one embodiment, the processor 1120 may include at least one processor. Furthermore, the electronic device 1100 may also operate as a server or proxy server.

[0171] Transceiver 1110 can communicate with external devices using wired and wireless communication technologies, and includes transceiver 1110. The external device may be a terminal, including a developer terminal or a quality assurance team terminal, or a server. Furthermore, the communication technology utilized by transceiver 1110 may include, but is not limited to, GSM (Global System for Mobile Communication), CDMA (Code Division Multi Access), LTE (Long Term Evolution), 5G (5th Generation Mobile Communication Technology), WLAN (Wireless LAN), Wi-Fi (Wireless Fidelity), Bluetooth, RFID (Radio Frequency Identification), Infrared Data Association (IrDA), ZigBee, NFC (Near Field Communication), and the like.

[0172] According to one embodiment, transceiver 1110 can communicate with terminal 110, simulation data server 120, and service data server 130 to exchange information. More specifically, transceiver 1110 can send and receive API requests and API responses with service data server 130. For example, transceiver 1110 can receive identification information such as a universally unique identifier (UID) and an inbound API request from terminal 110. Furthermore, transceiver 1110 can receive simulation data from simulation data server 120. Furthermore, transceiver 1110 can transmit API requests or API responses to a data storage device and provide pages related to this case to terminals, including terminal 110.

[0173] Processor 1120 can control the overall operation of electronic device 1100 and process data and signals. Processor 1120 can implement the method described above with reference to Figures 1 to 11. Processor 1120 can control the embodiments implemented by electronic device 1100 by interacting with transceiver 1110, storage 1130, and other components that electronic device 1100 may further include. According to one embodiment, processor 1120 can receive identification information and an inbound API request from terminal 110, determine the emulation type corresponding to the terminal based on at least one of the identification information and the inbound API request, determine an outbound API request based on the inbound API request, transmit an outbound API request based on the emulation type to at least one of emulation data server 120 and service data server 130, receive an inbound API response corresponding to the outbound API request, and transmit at least a portion of the inbound API response to terminal 110.

[0174] The storage 1130 can store information used to implement at least one of the methods described above with reference to Figures 1 to 11. The storage 1130 can be referred to as a memory and can be either volatile memory or non-volatile memory. For example, the storage 1130 can include the data storage device shown in Figure 3.

[0175] On the other hand, this specification and drawings disclose preferred embodiments of the present invention. Although specific terms are used, these terms are used in a general sense to facilitate the description of the technical content of the present invention and to aid understanding of the invention, and are not intended to limit the scope of the present invention. It is obvious to those skilled in the art that, in addition to the embodiments disclosed herein, other variations based on the technical principles of the present invention may be implemented.

[0176] The electronic device or terminal in the above-mentioned embodiment may include: a processor, a memory for storing and executing program data, permanent storage such as a disk drive, a communication port for communicating with external devices, and a user interface device such as a touch panel, keys, or icons. The method implemented by the software module or algorithm may be stored on a computer-readable recording medium as code or program commands executable on the processor. Computer-readable recording media include magnetic storage media (e.g., ROM (read-only memory), RAM (random-access memory), floppy disks, hard disks, etc.) and optical readable media (e.g., CD-ROMs and DVDs). The computer-readable recording media is distributed across networked computer systems, storing and executing computer-readable code in a distributed manner. The media can be read by a computer, stored in memory, and executed by the processor.

[0177] This embodiment can be represented by functional blocks and various processing steps. These functional blocks can be implemented using various hardware and / or software components that perform specific functions. For example, this embodiment can employ direct circuit components such as memory, processing, logic, and lookup tables to perform various functions within the control of one or more microprocessors or other control devices. Similar to how components can be implemented by software programs or software elements, this embodiment includes algorithms composed of combinations of data structures, programs, routines, or other program components, which can be implemented using programming or scripting languages such as C, C++, Java, assemblers, and Python. Functionally, this embodiment can be implemented using algorithms executed by one or more processors. Furthermore, this embodiment can utilize prior art technologies for electronic environment settings, signal processing, and / or data processing. Terms such as "mechanism," "element," "mechanism," and "component" are used broadly and are not limited to mechanical or physical components. These terms can be used in conjunction with processors and other devices to encompass software routines.

[0178] The above embodiment is merely an example, and other embodiments may be implemented within the scope of the patent application described below.

[0179] 100: Electronic devices 110:Terminal 120:Simulation Information Server 130: Service Data Server 300: Data storage 320: Page 321: Correction page 330: Terminal 1 500: Page 501: "Buy" icon 502: Checkout page 510: Page 511: Inbound API request 512: Icon 513: Icon 514: Save as simulation data 515:165300727500707623860509 520: Settings page 521:Project Name 522: Scene name 523: Group name 524: "Save" icon 530: Correction page 531:Project Name 532: Scene name 533: Group name 534: Identification Information 535: Object Simulation Data 536: Icon 537: Icon 540:Simulation data settings page 541:API URL Information 542: Method information corresponding to the API response 543:Simulation Type Information 544: Status information corresponding to the API response 545: Source code for simulation data 550:Simulation data settings page 551: Source code 560: Correction page 561: Icon 562: Object simulation data 571: Page 572: "Buy" icon 573:Results page 574: Information 575: Available for purchase with an additional payment of 6450 won or more 600:Simulation data setting page 601: Status Information 602: Source code 620: Page 621: "Buy" icon 630: Results page 631:Phrase 800:Simulation data setting page 801: API URL information 802: Method information corresponding to the API response 803:Simulation type information 804: Status information corresponding to the API response 805: Source code for analog data 806: "Save" icon 810: Page 811: "Answer" 812: Status Information 813: Source code 820:1st source code 830: Second source code 840:3rd source code 850: 4th source code 860:5th source code 900: Page 901: First inbound API request 902: Second inbound API request 903: 3rd inbound API request 904: Port 4 API request 905: API request for port 5 906: View icon 910:Details page 911: Request for Information 912: Request Header 913: Response 914: URL Information 915: Parameter source code 916: Source code of data (payload) 1000: Correction page 1010: Icon 1020: Icon 1030: Icon 1100: Electronic devices 1110: transceiver 1120: Processor 1130: Storage S210: Step S220: Step S230: Step S240: Steps S250: Steps S260: Steps S301: Step S302: Step S303: Step S304: Step S305: Step S306: Step S307: Step S308: Step S309: Step S310: Step S311: Step S410: Step S420: Step S710: Steps S720: Steps S730: Steps

Claims

1. A method for providing information, wherein the information is provided by an electronic device, comprising: The system receives identification information and an inbound API request for the terminal from the terminal, wherein the inbound API is an object of an API test; based on at least one of the identification information and the inbound API request information, the system confirms the simulation type corresponding to the terminal from the simulation data server and obtains object simulation data from the simulation data stored in the simulation data server; transmits the outbound API request identified based on the inbound API request to the service data server; updates the inbound API response received from the service data server in response to the outbound API request based on the object simulation data; and provides the terminal with information related to the API test, including at least a portion of the updated inbound API response.

2. The method of providing information as described in request item 1 further includes: At least a portion of the updated inbound API response will be recognized as the updated outbound API response. And to recognize at least a portion of the aforementioned inbound API responses as outbound API responses.

3. The method of providing information as described in request item 2 further includes: The aforementioned inbound API request, the aforementioned outbound API request, the aforementioned inbound API response, and the aforementioned outbound API response are stored in the data storage.

4. The method of providing information as described in request item 3 further includes: The first page, which includes at least one of the aforementioned inbound API request, the aforementioned outbound API request, the aforementioned inbound API response, and the aforementioned outbound API response stored in the aforementioned data storage, is provided to the aforementioned terminal.

5. The method of providing information as described in request item 3 further includes: A second page comprising at least one of the aforementioned inbound API request, the aforementioned outbound API request, the aforementioned inbound API response, and the aforementioned updated outbound API response shall be provided to the aforementioned terminal.

6. The method of providing information as described in request item 5, wherein the second page includes an icon for accessing a detailed correction page used to correct the above-mentioned object simulation data.

7. The method of providing information as in request item 5, wherein updating the aforementioned inbound API response includes determining whether to apply the aforementioned object simulation data based on the icon on the aforementioned second page indicating whether to apply the aforementioned object simulation data.

8. The method of providing information as in request item 1, wherein the object simulation data includes at least one of the information corresponding to the field of the updated object and the information corresponding to the field value in the inbound API response.

9. As in the method of providing information in request item 8, wherein updating the above-mentioned inbound API response includes information based on the above-mentioned fields, and adding or deleting fields of the above-mentioned inbound API response.

10. The method of providing information as in request item 8, wherein updating the above-mentioned inbound API response includes information based on the above-mentioned field values, and updating the field values ​​of the above-mentioned inbound API response.

11. An electronic device for providing information, comprising: transceiver; A memory that stores one or more instructions; The processor is configured to: receive from the terminal identification information and an inbound API request for the terminal, wherein the inbound API is an object of an API test; determine from the simulation data server the simulation type corresponding to the terminal based on at least one of the identification information and the inbound API request information, and obtain object simulation data from the simulation data stored in the simulation data server; transmit the outbound API request identified based on the inbound API request to the service data server; update the inbound API response received from the service data server in response to the outbound API request based on the object simulation data; and provide the terminal with information related to the API test, including at least a portion of the updated inbound API response.

12. A non-transitory computer-readable recording medium recording a program for performing the method as described in claim 1 on a computer.

Images