A front-end debugging method, calling method and debugging device simulating real requests

Abstract

The application discloses a front-end debugging method, a calling method and a debugging device simulating real requests, which comprises the following steps: creating a project and creating an interface classification; adding an interface in the project: selecting an interface classification, an interface name, an interface protocol and an interface path; configuring an operation mode, the operation mode comprising query, addition, deletion and modification, when the operation mode is 'addition, deletion and modification', an associated interface is specified, indicating that the current interface will modify the Mock data of the associated interface; configuring Mock data for the interface; and saving the Mock data. Through the interface creation mode, the front-end webpage can directly change the Mock data through the calling of the created API interface, real API operations are simulated, the development cycle of the front-end webpage is reduced, and the efficiency of the front-end and back-end joint debugging work is improved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, specifically to a front-end debugging method, invocation method, and debugging device that simulates real requests. Background Technology

[0002] A complete website application consists of a client (hereinafter referred to as the "front-end webpage") and a server (hereinafter referred to as the "back-end service"). The front-end webpage needs to call the API (Application Programming Interface) of the back-end service to render the page content and data, ultimately presenting the functionality of the entire application. It can be said that the appearance of the front-end page is heavily dependent on the back-end service. During project development, front-end work often encounters the following problems, leading to task delays or adjustments to front-end display requirements:

[0003] 1. The basic functions of the front-end page have been implemented, but the back-end interface has not been developed or is incomplete;

[0004] 2. The backend environment is unstable and frequently encounters errors, blocking the frontend integration testing and causing task delays;

[0005] 3. Due to client or project requirements, a demonstration of the current project is needed during development, but the backend functionality is not yet supported; only the frontend can be provided.

[0006] To address the above issues, a front-end development debugging tool (hereinafter referred to as a Mock tool) is needed to simulate the API interfaces of back-end services, thereby ensuring the development efficiency of front-end pages and supporting the display of front-end page effects. Summary of the Invention

[0007] The purpose of this invention is to provide a front-end debugging method that simulates real requests, so as to solve the problems mentioned in the background art.

[0008] To solve the above-mentioned technical problems, the present invention provides the following technical solution: a front-end debugging method for simulating real requests, comprising the following steps:

[0009] Create a project and create an API category;

[0010] Add an interface to the project:

[0011] Select the interface category, interface name, interface protocol, and interface path;

[0012] Configure the operation mode, which includes query, add, delete, and modify. When the operation mode is "add, delete, modify", specify the associated interface, indicating that the current interface will modify the Mock data of the associated interface.

[0013] Configure Mock data for the interface;

[0014] Save the mock data.

[0015] Preferably, when creating a project, the front-end page of the Mock tool calls the HTTP protocol using the POST method to send a request to the back-end of the Mock tool, saves the project information in the "project" table in the database, and automatically generates a unique identifier _id for the project.

[0016] Preferably, when creating an interface category, the front-end page of the Mock tool calls the HTTP protocol using the POST method to send a request to the back-end of the Mock tool, saves the interface category information in the "interface_cat" table in the database, and automatically generates a unique identifier _id for each category.

[0017] Preferably, when adding an interface, the front-end page of the Mock tool sends a POST HTTP request to the back-end of the Mock tool, saves the interface information in the "interface" table of the database, and automatically generates a unique identifier ID for the interface.

[0018] Preferably, the Mock data includes three types: expected Mock, Mock source, and ordinary Mock. The operation method is that the Mock source data must be configured when querying.

[0019] Priority for using Mock data: Expected Mock > Mock source > Regular Mock.

[0020] Preferably, when configuring the expected Mock, the basic information of the expected data and the response result are configured. The basic information includes: expected name, whether IP filtering is enabled, and filtering parameters. The response result includes: response HTTP code, response data, HTTP headers, and delayed response time.

[0021] When configuring "Mock source" data, configure "Mock data list fields", "Number of Mock data list entries", "Whether to enable Mock source", "Current page fields", "Number of fields to display per page", and "Mock data".

[0022] Preferably, when saving Mock data, the front-end page of the Mock tool sends a POST HTTP request to the back-end of the Mock tool to save the relevant information of the Mock data in the "adv_source_mock" table of the database, and automatically generates a unique identifier ID for the Mock data. The Mock data is associated with the API interface through the API interface ID.

[0023] Preferably, when configuring regular mock data, the open-source library Mock.js is used to configure the mock rules of the interface and generate data randomly;

[0024] Saving "normal Mock" data involves updating the API interface. The front-end page of the Mock tool sends a POST HTTP request to the back-end of the Mock tool, saving the "Mock rule" data as a string in the "res_body" field of the "interface" table in the database.

[0025] A method for processing front-end web pages to call Mock data, wherein the front-end web page initiates an interface request to the "Mock tool";

[0026] After receiving the request, the "Mock tool" parses it to obtain the "interface type", "interface path" and "request parameters", and obtains the interface information through the "interface type" and "interface path". This interface is the interface created by the aforementioned front-end debugging method that simulates a real request.

[0027] The interface information includes the associated interface and the operation method. Then, based on the "operation method", it is determined whether to directly read "Mock" data.

[0028] When the operation method is query, return the Mock data of the current interface according to the request parameters;

[0029] When the operation method is add, delete, or modify, first obtain the "Mock source" data of the "related interface", modify the data according to the operation method type, and after the modification is completed, return the Mock data of the current interface.

[0030] A front-end debugging device for simulating real requests includes a first module, which is configured to create interfaces with operation modes of "query", "add", "delete" and "modify", and configure Mock data.

[0031] The second module is configured to call the interface created by the first module and call the mock data of the interface to perform the selected operation.

[0032] Compared with the prior art, the beneficial effects of the present invention are:

[0033] This invention enables front-end web pages to directly modify mock data by calling the created API interface, simulating real API operations. This reduces the development cycle of front-end web pages and improves the efficiency of front-end and back-end integration testing. Attached Figure Description

[0034] Figure 1 The process for creating the API interface of this invention;

[0035] Figure 2 The flowcharts for the creation of the APIs for the four types of operations of "query", "add", "delete" and "modify" in this invention are visualized in the Mock platform;

[0036] Figure 3 This is a flowchart illustrating the process of adding the "expected Mock" in this invention.

[0037] Figure 4 This is a flowchart illustrating the process of adding "Mock source" data in this invention.

[0038] Figure 5 This is a flowchart illustrating the configuration process for ordinary Mock data in this invention.

[0039] Figure 6 This describes the process of calling Mock data on the front-end page of this invention. Detailed Implementation

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

[0041] A front-end debugging method and invocation method that simulates real requests, see reference. Figure 1 As shown, the steps include the following:

[0042] Create a project

[0043] Project names are unique. Due to business requirements, different projects have different APIs. Even with the same API path and HTTP protocol, the backend service returns different data across different projects. During "creation," the Mock tool's frontend page calls the POST HTTP protocol to send a request to the Mock tool's backend, storing the "project" information (including: project name, base path, project type, and project space) in the "project" table of the database, and automatically generating a unique identifier _id for the project. The POST request body includes:

[0044] {

[0045] "name":"test",

[0046] "basepath":" / api",

[0047] "group_id":"16",

[0048] "project_type":"private"

[0049] }

[0050] Interface Category Management

[0051] Enter the project and add an "Interface Category". The category name is customizable, generally named according to the project's business or functional dimensions. The front-end page of the mock tool uses the POST HTTP protocol to send a request to the back-end of the mock tool, storing the "Interface Category" information (including: category name, category description, and associated project) in the "interface_cat" table in the database, and automatically generating a unique identifier _id for the category. The POST request body includes:

[0052] {"name":"User Management","desc":"User Management","project_id":"35"}

[0053] Added "API" (Add Interface)

[0054] The new "API" consists of 6 parts, including:

[0055] API Classification: An API can only belong to one category.

[0056] Interface Name: A semantically defined interface name that provides a simple description of the interface, allowing developers to quickly understand its purpose.

[0057] Interface Type: An API can only use one protocol type. The HTTP protocol types for APIs include: GET, POST, DELETE, PUT, HEAD, OPTIONS, PATCH, and CONNECT.

[0058] Interface path: This refers to the URL (Uniform Resource Locator) provided by the backend service when connecting frontend and backend data.

[0059] Operation methods: The operation methods for Mock data are one of the key configurations for the front-end page to call the Mock tool and modify the Mock data. There are 5 types: query, add, delete, modify, and other (the Mock data is not processed and the API directly returns the Mock data).

[0060] When creating an API with the "Operation Method" of "Add", "Delete", or "Modify", the "Associated Interface" must be filled in. When the front-end pages of each project call these three "Operation Method" APIs to add, delete, or modify the "Mock Data" of the "Mock Tool", the back-end of the Mock Tool will first obtain the "Mock Source" of the associated "Operation Method - Query" API.

[0061] The API for the four types of operations—"query," "add," "delete," and "modify"—is visualized in the Mock platform, showing the main creation process. Figure 2 It is worth mentioning that, for associated interfaces: when the "operation method" is add, delete, or modify, an "associated interface" must be specified, indicating that the current interface will modify the mock data of the "associated interface" (the "associated interface" can only be an API of the "operation method - query" type).

[0062] The front-end page of the mock tool sends a POST HTTP request to the back-end of the mock tool, storing the "API" information (the above 6 items) in the "interface" table of the database and automatically generating a unique API identifier ID. An example of the request body is as follows:

[0063] {

[0064] "method":"GET", / / Interface type

[0065] "catid":"31", / / ID of the interface category

[0066] "title":"Add User", / / API Name

[0067] "path":" / user / add", / / API path

[0068] "associated_interface_id":"25", / / The ID of the associated interface

[0069] "operation":1, / / Operation method: Query-0, Add-1, Delete-2, Modify-3, Other-4

[0070] "project_id":"19" / / Project ID

[0071] }

[0072] The combination of "interface type" and "interface path" must be unique within a given project.

[0073] Add "Mock data":

[0074] There are three main types of mock data: expected mocks, mock sources (this type of mock data is only available in "Operation Mode - Query"), and regular mocks.

[0075] The priority for using mock data is: Desired Mock > Mock Source > Regular Mock. The three types of mock data are configured according to the developer's usage.

[0076] Expected Mock: Configure specific mock data under certain filtering conditions. Multiple expected values ​​can be added and displayed in a list format.

[0077] Configuring a mock request requires configuring the "basic information" (including: mock name, whether IP filtering is enabled, and filtering parameters) and the "response result" (including: response HTTP code, response data, HTTP headers, and delayed response time). When saving data, the mock tool's front-end page sends a POST HTTP request to the mock tool's back-end, storing the "mock data" in the "adv_mock_case" table in the database and automatically generating a unique identifier ID for the mock data. An example request body is shown below:

[0078] {

[0079] "name":"User List", / / Expected Name

[0080] "ip_enable":false, / / Whether to enable IP filtering

[0081] "params":{"pageNum":"1"}, / / Filter parameters

[0082] "code":"200", / / HTTP response code

[0083] "delay":0, / / delay response time

[0084] "headers":[], / / HTTP headers

[0085] "res_body":"{\n\"code\":200,\n\"data\":{\n\"records\":[{\"id\":1,\"name\":\"Tom\"}],\n\"totals\":10\n}\n}", / / Response data

[0086] "interface_id":"25", / / API interface ID

[0087] "project_id":"19" / / The ID of the current project

[0088] }

[0089] The process of adding "expected Mock" is as follows: Figure 3 As shown.

[0090] Mock source: Mock data that can be dynamically manipulated (added, deleted, modified, filtered) by various APIs.

[0091] Configuring the "Mock Source" data requires configuring the "Mock Data List Fields", "Number of Mock Data List Items", "Whether to Enable Mock Source", "Current Page Fields", "Number of Fields to Display per Page", and "Mock Data". The default format for "Mock Data" is as follows:

[0092] {

[0093] "success":true,

[0094] "message":"SUCCESS",

[0095] "code":200,

[0096] "data":{

[0097] "total":2,

[0098] "records":[

[0099] {

[0100] "id":1,

[0101] "name":"Tom"

[0102] } ]

[0104] }

[0105] }

[0106] When saving data, the front-end page of the Mock tool sends a POST HTTP request to the back-end of the Mock tool, storing the relevant information of the "Mock data" in the "adv_source_mock" table of the database, and automatically generating a unique identifier ID for the Mock data. The Mock data is associated with the API interface through the "API interface ID (interface_id)". An example request body is shown below:

[0107] {

[0108] "project_id":"19", / / Project ID

[0109] "interface_id":"25", / / API interface ID

[0110] "mock_data":"{\"data\":{\"list\":[{\"name\":\"tom\",

[0111] ["age":20},{"name":"john","age":21}],"total":10}}\n", / / Mock data

[0112] "enable":true, / / Whether to enable "Mock source" (the "Query" class interface is enabled by default).

[0113] "mock_path":"data.list", / / Mock data list field

[0114] "num_name":"data.total", / / Number of rows in the Mock data list

[0115] "max_num":50, / / Maximum number of records can be added.

[0116] "page_num":"pageNum", / / Current page field

[0117] "page_size":"pageSize" / / Number of fields to display per page

[0118] }

[0119] The process for adding "Mock source" data is as follows: Figure 4 As shown.

[0120] Regular Mock: Configures the API's mock rules (implemented using the open-source library Mock.js) to randomly generate data. Example data for the configured "Mock Rules":

[0121] {

[0122] "type":"object",

[0123] "title":"title",

[0124] "properties":{

[0125] "code":{"type":"string","description":"status code"},

[0126] "data":{

[0127] "type":"object",

[0128] "properties":{

[0129] "records":{

[0130] "type":"array",

[0131] "items":{

[0132] "type":"object",

[0133] "properties":{

[0134] "id":{"type":"string"},

[0135] "name":{"type":"string"}

[0136] },

[0137] "required":["id","name"]

[0138] }

[0139] },

[0140] "totals":{"type":"number"}

[0141] },

[0142] "required":["records","totals"]

[0143] }

[0144] },

[0145] "required":["code","data"]

[0146] }

[0147] Each property in the "properties" section is a "node," with the property name being the "node name," "type" indicating the node's data type, and "description" providing a description of the node's function. Clicking "Save Normal Mock Data" updates the API interface. The front-end page of the Mock tool sends a POST HTTP request to the back-end, saving the "Mock Rules" data as a string in the "res_body" field of the "interface" table in the database.

[0148] The process of creating "normal Mock" data is as follows: Figure 5 As shown.

[0149] Each front-end project is configured with a proxy forwarding mechanism. After connecting to the "Mock tool" to obtain Mock data, the page is rendered.

[0150] The front-end webpage sends an API request to the "Mock tool". After receiving the request, the "Mock tool" parses it to obtain the "interface type", "interface path", and "request parameters". Using the "interface type" and "interface path", it retrieves the interface information, such as the associated interface and operation method. Then, based on the "operation method", it determines whether to directly read "Mock" data. For interfaces with "operation method - query" and "operation method - other" categories, it returns the current interface's Mock data based on the "request parameters". For interfaces with "operation method - add", "operation method - delete", and "operation method - modify" categories, it first retrieves the "Mock source" data from the "associated interface", modifies the data according to the operation method type, and then returns the current interface's Mock data. The specific process is as follows: Figure 6 .

[0151] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A front-end debugging method simulating real requests, characterized in that: Includes the following steps: Create a project and create an API category; Add an interface to the project: Select the interface category, interface name, interface protocol, and interface path; Configure the operation mode, which includes query, add, delete, and modify. When the operation mode is "add, delete, modify", specify the associated interface, indicating that the current interface will modify the Mock data of the associated interface; Configure Mock data for the interface; Save the mock data; Mock data includes three types: expected Mock, Mock source, and regular Mock. The operation method is that Mock source data must be configured when querying. The priority for using mock data is: expected mock > mock source > regular mock; The front-end webpage sends an API request to the mock tool. After receiving the request, the mock tool parses it to obtain the API type, API path, and request parameters, and obtains the API information through the API type and API path. The API information includes the associated API and the operation method. Then, it determines whether to directly read the mock data based on the operation method. When the operation method is a query API, it returns the mock data of the current API based on the request parameters. When the operation method is add, delete, or modify, it first obtains the mock source data of the associated API, modifies the data according to the operation method type, and returns the mock data of the current API after the modification is completed.

2. The front-end debugging method for simulating real requests according to claim 1, characterized in that: When a project is created, the front-end page of the Mock tool calls the HTTP protocol using the POST method to send a request to the back-end of the Mock tool, saves the project information in the "project" table in the database, and automatically generates a unique identifier _id for the project.

3. The front-end debugging method for simulating real requests according to claim 1, characterized in that: When creating an interface category, the front-end page of the Mock tool calls the HTTP protocol using the POST method to send a request to the back-end of the Mock tool, saves the interface category information in the "interface_cat" table in the database, and automatically generates a unique identifier _id for each category.

4. The front-end debugging method for simulating real requests according to claim 1, characterized in that: When adding an interface, the front-end page of the Mock tool sends a POST HTTP request to the back-end of the Mock tool, saves the interface information in the "interface" table of the database, and automatically generates a unique identifier ID for the interface.

5. The front-end debugging method for simulating real requests according to claim 4, characterized in that: When configuring the expected Mock, configure the basic information of the expected data and the response result. The basic information includes: expected name, whether IP filtering is enabled, and filtering parameters. The response result includes: response HTTP code, response data, HTTP headers, and delayed response time. When configuring "Mock source" data, configure "Mock data list fields", "Number of Mock data list entries", "Whether to enable Mock source", "Current page fields", "How many fields to display per page", and "Mock data".

6. The front-end debugging method for simulating real requests according to claim 5, characterized in that: When saving mock data, the front-end page of the mock tool sends a POST HTTP request to the back-end of the mock tool to save the relevant information of the mock data in the "adv_source_mock" table of the database, and automatically generates a unique identifier ID for the mock data. The mock data is associated with the API interface through the API interface ID.

7. The front-end debugging method for simulating real requests according to claim 6, characterized in that: When configuring regular mock data, the open-source library Mock.js is used to configure the mock rules of the interface and generate data randomly. Saving "normal Mock" data involves updating the API interface. The front-end page of the Mock tool sends a POST HTTP request to the back-end of the Mock tool, saving the "Mock rule" data as a "string" in the "res_body" field of the "interface" table in the database.

Images