Network request collection and local response override method, apparatus, device, and medium

Abstract

The application discloses a network request collection and local response coverage method and device, equipment and medium, relates to the computer technical field, including: collecting network request and response body through browser debugger interface, and / or, analyzing user imported network request archive file, converting the collected data and / or analyzed data into a candidate request list; determining a target request from the candidate request list, normalizing the request address of the target request, generating a target request coverage rule according to the normalized path and the response body data; intercepting the request of the target page, if a request pause event is received, normalizing the request address of the paused request to obtain a to-be-matched path, comparing the to-be-matched path with the matching mode of the request coverage rule to determine a hit rule; determining the response body data of the hit rule as a target response body, and returning the target response body to the target page to realize local response coverage. The stability of the interception hit is improved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to methods, apparatus, devices and media for network request collection and local response overlay. Background Technology

[0002] Modern web applications typically retrieve data from backend services, third-party platforms, or gateways via asynchronous APIs. The development and debugging of frontend pages heavily rely on the API return values. However, during development, issues frequently arise such as incomplete backend APIs, insufficient data in the test environment, inconvenient access to online problem data, high costs or limited number of third-party API calls, prolonged API unresponsiveness due to backend debugging breakpoints, and frequent failures in login and permission states. These situations prevent the frontend page from consistently reaching the target state, thus impacting development, integration testing, reproduction, and demonstration.

[0003] Browser developer tools can display a page's network requests and export archived network request files; browser debugger interfaces also provide capabilities for network event listening, response body reading, and response filling after a request is paused. Existing interface simulation tools or testing frameworks can simulate interface responses in specific environments, and independent simulation servers can also return data according to configuration. However, existing solutions typically only address one aspect of request logging, test script replay, or server-side simulation, lacking a closed-loop solution that can be directly embedded into browser developer tools, collect current page interfaces, automatically generate coverage rules, maintain rules according to the project, and return local responses in real time. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a method, apparatus, device, and medium for network request collection and local response coverage. This method can reliably acquire interface requests and their response bodies that have occurred or are about to occur on the current browser page without modifying front-end business code, altering back-end services, or building an independent proxy server. It converts real-time collection results and external network request archives into executable and maintainable local request coverage rules, isolates rule sets across multiple business projects, and uniformly corrects interface paths through context paths. During the request interception phase, it selects the most matching rule from multiple enabled rules and returns a specified response to the target page. Furthermore, it supports multi-role collaborative debugging through project configuration and the import / export of network request archives. The specific solution is as follows: In a first aspect, this application discloses a method for network request collection and local response overlay, including: Create or select a project in the browser's developer tools panel; the project includes the context path and several request coverage rules; Collect network requests and response bodies that have occurred on the current page through the browser debugger interface, and / or parse the network request archive file imported by the user, and convert the corresponding collected data and / or parsed data into a candidate request list with a preset unified field structure; The target request is determined from the candidate request list based on the selection instruction. The request address of the target request is normalized based on the preset normalization rule to obtain the normalized path. The target request coverage rule is generated based on the normalized path and the response body data corresponding to the target request. The target request coverage rule is saved to the project. The preset normalization rule includes at least removing query parameters that belong to the preset dynamic parameter set. When a user refreshes the page or performs a click operation, the browser debugger interface is used to intercept the request to the target page. If a request pause event is received, the request address of the paused request is normalized based on the preset normalization rule to obtain the path to be matched. The path to be matched is compared with the matching mode of the request coverage rule, and the hit rule is determined according to the corresponding comparison result. The response body data of the hit rule is determined as the target response body, and the target response body is returned to the target page through the browser debugger interface to achieve local response coverage of the network request.

[0005] Optionally, before collecting the network requests and response bodies that have occurred on the current page through the browser debugger interface, the method further includes: The system detects the number of historical requests that already exist on the current page. If the number of historical requests is lower than a preset threshold, it outputs a prompt message asking whether to refresh the page. In response to the user's confirmation to refresh the page, the current page is refreshed and the data collection is re-executed.

[0006] Optionally, after collecting the network requests and response bodies that have occurred on the current page through the browser debugger interface, the method further includes: If the browser debugger interface does not obtain the response body, it falls back to the browser developer tools network panel mode to obtain the request record from the loaded resource performance entries, uses the request record as the collected data, and performs the step of converting it into a candidate request list with a preset unified field structure.

[0007] Optionally, before converting the corresponding collected data and / or parsed data into a candidate request list with a preset unified field structure, the method further includes: The collected and / or parsed data is filtered to remove script files, style files, image files, font files, audio and video files, and browser extension address requests, resulting in filtered data. From the filtered data, identify interface requests based on structured response types, and / or match interface requests based on preset interface path keywords; The identified and / or matched interface requests are the data source for determining the candidate request list.

[0008] Optionally, determining the target request from the candidate request list based on the selection instruction includes: The candidate request list is displayed in the browser developer tools panel; each entry in the candidate request list includes at least the request method, request address, response status code, and response body size. In response to a user's selection of one or more items in the candidate request list, the selected item is determined as the target request.

[0009] Optionally, the preset dynamic parameter set includes any one or a combination of several of the following: timestamp parameters, cache corruption parameters, session identifier parameters, and page offset parameters; Accordingly, the step of normalizing the request address of the target request based on a preset normalization rule to obtain a normalized path includes: After removing the query parameters that belong to the preset dynamic parameter set, the query parameters in the request address of the target request are sorted according to the key name, and the sorted query parameters are concatenated to obtain the concatenated query parameters. The concatenated query parameters are combined with the path information in the request address to obtain a normalized path.

[0010] Optionally, the matching pattern is the target path recorded in the request coverage rule or a path pattern containing wildcards; Accordingly, comparing the path to be matched with the matching pattern of the request coverage rule, and determining the hit rule based on the comparison result, includes: The path to be matched is compared sequentially with the matching pattern of the request coverage rule that is in the enabled state; If the path to be matched is the same as the matching pattern, then the request coverage rule is determined to be an exact match; If the matching pattern contains wildcards, then the matching pattern is converted into a regular expression, and the regular expression is matched against the path to be matched. If a match is found, the request coverage rule is determined to be a wildcard match; Among all the request coverage rules that are determined to be a match, the request coverage rule with the matching mode of exact match is determined as the hit rule; If no exact match request coverage rule exists, then the request coverage rule in the wildcard matching rule whose matching pattern path length meets the preset length condition will be determined as the hit rule.

[0011] Secondly, this application discloses a network request collection and local response overlay device, comprising: The project creation or selection module is used to create or select a project in the browser's developer tools panel; the project includes a context path and several request coverage rules; The candidate request list acquisition module is used to collect network requests and response bodies that have occurred on the current page through the browser debugger interface, and / or parse the network request archive file imported by the user, and convert the corresponding collected data and / or parsed data into a candidate request list with a preset unified field structure; The request coverage rule saving module is used to determine the target request from the candidate request list based on the selection instruction, normalize the request address of the target request based on the preset normalization rule to obtain the normalized path, generate the target request coverage rule according to the normalized path and the response body data corresponding to the target request, and save the target request coverage rule to the project; the preset normalization rule includes at least removing query parameters that belong to the preset dynamic parameter set; The hit rule determination module is used to intercept requests to the target page through the browser debugger interface when the user refreshes the page or performs a click operation. If a request pause event is received, the request address of the paused request is normalized based on the preset normalization rule to obtain the path to be matched. The path to be matched is compared with the matching mode of the request coverage rule, and the hit rule is determined according to the corresponding comparison result. The local response overriding implementation module is used to determine the response body data of the hit rule as the target response body, and return the target response body to the target page through the browser debugger interface, so as to realize the local response overriding of the network request.

[0012] Thirdly, this application discloses an electronic device, including: Memory, used to store computer programs; A processor for executing computer programs to implement the steps of the network request acquisition and local response coverage method as described above.

[0013] Fourthly, this application discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the aforementioned network request acquisition and local response overlay method.

[0014] This application first creates or selects a project in the browser developer tools panel; the project includes a context path and several request coverage rules; then, it collects network requests and response bodies that have occurred on the current page through the browser debugger interface, and / or parses the network request archive file imported by the user, converting the corresponding collected data and / or parsed data into a candidate request list with a preset unified field structure; then, based on the selection instruction, it determines the target request from the candidate request list, normalizes the request address of the target request based on a preset normalization rule to obtain a normalized path, generates a target request coverage rule based on the normalized path and the response body data corresponding to the target request, and saves the target request coverage rule. The data is stored in the project; the preset normalization rule includes at least removing query parameters belonging to the preset dynamic parameter set; then, when the user refreshes the page or performs a click operation, the browser debugger interface intercepts the request to the target page. If a request pause event is received, the request address of the paused request is normalized based on the preset normalization rule to obtain the path to be matched. The path to be matched is compared with the matching mode of the request coverage rule, and the hit rule is determined according to the corresponding comparison result; finally, the response body data of the hit rule is determined as the target response body, and the target response body is returned to the target page through the browser debugger interface to achieve local response coverage of the network request. It can be seen that this application, by combining browser debugger interface collection with network request archive file parsing, achieves a one-click conversion from real page requests to local response coverage rules, without modifying business code or deploying a separate server to complete interface simulation. At the same time, through the configuration of project and context paths, rules can be migrated and reused between different deployment environments, reducing the risk of cross-project path configuration errors. During the request interception phase, dynamic parameters are eliminated by pre-defined normalization rules, and a matching mechanism prioritizing precise matching and path length is combined to improve the accuracy of API hits and prevent static resources from being mistakenly intercepted and broad rules from covering specific APIs. Furthermore, this application uses a debugger interface to directly complete request interception and response return locally in the browser, independent of backend service availability, allowing frontend development, testing, and problem reproduction to be performed independently of the actual API. Ultimately, through a complete closed-loop process of data collection, rule generation, interception matching, and local response population, developers are provided with a ready-to-use, maintainable, and shareable local debugging solution. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0016] Figure 1 This is a flowchart of a network request collection and local response overlay method disclosed in this application; Figure 2 This is a schematic diagram of a developer tool panel disclosed in this application; Figure 3 This is a schematic diagram of another developer tool panel disclosed in this application; Figure 4 This is a schematic diagram illustrating the principle of a network request collection and local response overlay system disclosed in this application; Figure 5 This is a project management diagram disclosed in this application; Figure 6 This is a schematic diagram of a network request data acquisition method disclosed in this application; Figure 7 This is a schematic diagram of a file import method disclosed in this application; Figure 8 This is a schematic diagram of a network request collection and local response overlay device disclosed in this application; Figure 9 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0017] 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.

[0018] The current technology mainly has the following problems: (1) Disconnect between data collection and coverage. The browser's network panel can view and export requests, but it cannot directly turn selected interface requests into enableable response coverage rules; the simulated server can return responses, but its rules usually need to be written manually, lacking an entry point for automatically generating rules from real page requests.

[0019] (2) Unstable response body retrieval. Ordinary network panel interfaces may only be able to obtain partial request information; when the response body is not cached or the page has finished loading, it is difficult for developers to fully reuse the real response.

[0020] (3) The rules lack project context. Different projects or different deployment contexts of the same system may have the same business path but different prefixes. Manually maintaining the complete address for each rule can easily lead to path mismatch.

[0021] (4) The interception results are not easy to predict. If only simple string inclusion relationships are matched, dynamic timestamps, query parameter order, wildcards and exact paths will affect the hit results, which may lead to the overwriting of incorrect interfaces.

[0022] (5) High collaboration costs. Archive files exported by testers, simulation data maintained by front-end developers, and interface examples provided by back-end developers often cannot be converted and reused in a single tool.

[0023] (6) Page state is at risk. In order to recapture the request, some tools will directly refresh the page, which may result in the loss of unsaved forms, login status or temporary debugging status.

[0024] To address the aforementioned technical issues, this application discloses a method, apparatus, device, and medium for network request acquisition and local response coverage. This method can reliably acquire interface requests and their response bodies that have occurred or are about to occur on the current browser page without modifying front-end business code, altering back-end services, or building an independent proxy server. It converts real-time acquisition results and external network request archives into executable and maintainable local request coverage rules, isolates rule sets across multiple business projects, and uniformly corrects interface paths through context paths. During the request interception phase, it selects the most matching rule from multiple enabled rules and returns a specified response to the target page. Furthermore, it supports multi-role collaborative debugging through project configuration and the import / export of network request archives.

[0025] See Figure 1 As shown, this embodiment of the invention discloses a method for network request collection and local response overlay, including: Step S11: Create or select a project in the browser developer tools panel; the project includes a context path and several request coverage rules.

[0026] In this embodiment, as Figure 2 and Figure 3 As shown, the developer tools panel serves as the user's entry point, providing operations such as project list, project details, rule creation, real-time import, archive file import, enabling all rules, disabling all rules, clearing rules, and exporting archive files. During initialization, the panel reads the current page information, loads project data, and determines whether to notify the backend to attach a debugger based on the enabled rules. The panel does not directly intercept requests; instead, it sends the rule set and collection instructions to the backend service to avoid affecting the interception logic when the foreground interface is closed or switched.

[0027] A project is an isolated container for a set of request coverage rules. In one specific implementation, each project includes at least a project identifier, project name, project description, context path, project activation status, rule array, data version number, creation time, and update time; each rule under a project includes at least a rule identifier, rule name, request type, request method, target path, context path, origin address, response content, activation status, belonging project identifier, source type, creation time, and update time. Users can create a project by clicking "New Project" in the panel and filling in the project name and description; if a project already exists, users can select it from the project list, and the selected project becomes the current project, with subsequent rules generated by data collection being assigned to that project by default.

[0028] The context path is used to address the issue of reusing the same set of rules across different system deployment paths. For example, if a project's context path is configured as " / system A", and the target path of its next rule is " / api / user", the backend can combine them into " / system A / api / user" when building the interception pattern. When the same set of interfaces is deployed to another business system, the user only needs to change the project context path to " / system B", and all rules will automatically point to " / system B / api / user" without needing to modify each rule individually. As an optional implementation, when the target path recorded in the rule is already a complete address including the protocol and hostname, the system will not append a context path to avoid illegal concatenations such as " / system A https: / / host / api / user".

[0029] There are several ways to configure the context path. The first is manual input, where the user directly enters " / System A" in the input box on the project details page. The second is automatic inference, where after the initial data collection, the system calculates the longest common prefix for the paths of all candidate requests and displays this prefix as the recommended value for the context path to the user for confirmation. The third is an empty context path, where the project does not set a context path; in this case, the target path of the rule is directly used as the matching pattern, suitable for simple scenarios in a single deployment environment.

[0030] By introducing project and context paths, the rule body only stores relative paths. Switching environments only requires modifying one field on the project, reducing manual modifications from N times to once and the number of rule entries from N×M to N. Therefore, this implementation reduces rule maintenance while eliminating path mismatches caused by omissions in rule-by-rule modifications, thus improving the reliability of cross-project and cross-environment reuse.

[0031] Step S12: Collect the network requests and response bodies that have occurred on the current page through the browser debugger interface, and / or parse the network request archive file imported by the user, and convert the corresponding collected data and / or parsed data into a candidate request list with a preset unified field structure.

[0032] In this embodiment, the data sources include two paths: real-time acquisition and archive file parsing, both ultimately converging into the same candidate request list. In one specific implementation of the real-time acquisition path, the steps include: the panel obtaining the identifier of the currently inspected tab; the panel pre-checking the historical request count for the page if necessary; the panel deciding whether to allow page refresh based on user options; the panel sending an acquisition request to the background debugger control module; the background debugger control module attaching to the debugger session of the tab, enabling network domain events and request pause capabilities, and listening for events such as request issuance, response reception, loading completion, and loading failure; after the loading completion event arrives, the background module calls the response body reading command to obtain the response body, and organizes the response body, response headers, status code, request method, request address, time consumption, and resource type into archive entries; the background module returns the acquisition results to the panel in a network request archive format. For resource performance records already existing in the browser, the system can merge them as supplementary entries into the acquisition results to reduce reliance on page refreshes.

[0033] In one specific implementation of the archive file parsing path, the panel reads the archive file specified by the user through the file selection control. First, it verifies whether the file has a valid structure, specifically checking for the existence of log fields, an array of entries, and the presence of a request address, request method, response object, and response status code in each entry. If the verification passes, it reads the requests and responses one by one, generating candidate request objects. If the verification fails, it prompts the user that the file structure is invalid and terminates the parsing process, thereby preventing illegal data from polluting the rule base.

[0034] The candidate request with the preset unified field structure, in one specific embodiment, includes at least the following fields: candidate identifier, request method, request address, status code, status text, response size, response type, response content, request header, response header, source type, and whether it is selected. The source type is used to identify whether the candidate request comes from real-time data collection or imported from an archive file, making it easier for users to distinguish the data source in the list.

[0035] In one specific implementation, before collecting network requests and response bodies that have occurred on the current page through the browser debugger interface, the method further includes: detecting the number of historical requests that already exist on the current page; if the number of historical requests is lower than a preset threshold, outputting a prompt message asking whether to refresh the page; and in response to the user's confirmation of the page refresh instruction, refreshing the current page and re-executing the collection.

[0036] Specifically, after attaching to a tab, the debugger can only listen to network events that occur after the attachment time. For requests completed during the initial page load phase, the debugger cannot recapture their events. Therefore, if the user opens the panel and clicks "Collect" only after the page has finished loading, the collection results may be empty or severely incomplete. To address this, this implementation performs a historical request pre-detection before the actual collection.

[0037] Methods for detecting the number of historical requests include, but are not limited to, reading resource performance entries. This involves executing a script within the target page context to count the number of entries among the loaded resources that are of asynchronous or data retrieval type. Controlling refresh behavior can also be implemented in several ways. The first is "allow refresh with confirmation before refresh," where a pop-up prompt message appears, and the refresh is only performed after the user clicks confirmation. The second is "allow refresh without confirmation," suitable for purely static display pages, which can reduce one interaction.

[0038] In one specific implementation, after collecting the network requests and response bodies that have occurred on the current page through the browser debugger interface, the method further includes: if the browser debugger interface does not obtain the response body, then falling back to the browser developer tools network panel mode, so as to obtain the request record from the loaded resource performance entries, using the request record as the collected data, and performing the step of converting it into a candidate request list with a preset unified field structure.

[0039] Specifically, there are several objective failure scenarios when obtaining the response body in debugger mode: First, the target tab is already occupied by other debugging tools, and the debugger attachment fails; second, the user clicks "cancel" on the browser's pop-up debugging prompt, causing the session to be detached; third, the response body has been released from the browser's memory buffer, and the read command returns a null value; fourth, the request is cross-origin and the response is marked as unreadable; fifth, the data collection is not completed within the preset network data collection timeout period. In any of these scenarios, without processing, the user will receive a blank candidate list and an incomprehensible error message. Data acquisition after rollback can also be implemented in several ways: the address, resource type, transfer size, and time can be read from the loaded resource performance entries; or the request method, response headers, and status code can be read from the request object provided by the developer tools' network panel interface.

[0040] In this way, the overall availability of the data acquisition function is improved without sacrificing the best-case data quality, and the tool still retains basic request import capabilities in debugger-limited environments.

[0041] In one specific implementation, before converting the corresponding collected data and / or parsed data into a candidate request list with a preset unified field structure, the method further includes: filtering the collected data and / or parsed data to remove script files, style files, image files, font files, audio and video files, and browser extension address requests, to obtain filtered data; identifying interface requests from the filtered data based on structured response types, and / or matching interface requests based on preset interface path keywords; and determining the identified and / or matched interface requests as the data source for the candidate request list.

[0042] Specifically, the filtering logic can be implemented in two directions: "exclusion" and "inclusion". In the exclusion direction, firstly, exclusion can be based on the address protocol, i.e., excluding browser extension addresses, data addresses, and temporary object addresses; secondly, exclusion can be based on resource type, i.e., excluding entries whose resource type is identified as script, stylesheet, image, font, media, or document; thirdly, exclusion can be based on file extension, i.e., excluding entries whose paths end with .js, .css, .png, .jpg, .gif, .svg, .woff, .woff2, .ttf, .mp4, .mp3, .zip, etc.; and fourthly, exclusion can be based on response content type, i.e., excluding entries whose response header content type begins with text / css, image / , font / , video / , or audio / .

[0043] In terms of inclusion criteria, firstly, inclusion is based on resource type, meaning entries whose resource type is explicitly defined as asynchronous requests or data retrieval requests are directly classified as interface requests; secondly, inclusion is based on request method, meaning submission, modification, and deletion requests are directly considered interface requests, as static resources typically do not use these methods. The inclusion criteria are logically ORed, meaning that meeting any one condition is sufficient for inclusion in the candidate list, thus reducing the false negative rate.

[0044] As an optional implementation, both the exclusion and inclusion rules mentioned above can be edited by the user in the advanced settings of the panel. For example, users can add custom interface path keywords or re-include a previously excluded extension to adapt to existing systems that use unconventional path specifications.

[0045] In one specific implementation, after obtaining the filtered data and before generating the candidate request list, deduplication processing can be performed on the filtered data. One specific implementation of this deduplication processing includes: cleaning the anchor points of the request address for each data entry and removing query parameters belonging to a preset dynamic parameter set; then sorting the remaining query parameters by key name to obtain normalized addresses; performing a first round of deduplication using the composite key "request method plus normalized address"; and then grouping the results by normalized address; for multiple data entries within the same group, if both non-acquisition methods and acquisition methods exist, the entries for non-acquisition methods are retained first; if the methods are the same, the entries with more complete response bodies are retained first; if the response body lengths are the same, the more suitable entry is selected based on method priority and status code. This processing reduces duplicate rules and avoids losing more valuable response samples.

[0046] Step S13: Determine the target request from the candidate request list based on the selection instruction, normalize the request address of the target request based on the preset normalization rule to obtain the normalized path, generate the target request coverage rule based on the normalized path and the response body data corresponding to the target request, and save the target request coverage rule to the project; the preset normalization rule includes at least removing query parameters that belong to the preset dynamic parameter set.

[0047] In this embodiment, the candidate request list is displayed in the browser developer tools panel; each item in the candidate request list includes at least a request method, a request address, a response status code, and a response body size; in response to the user's check-in operation on one or more items in the candidate request list, the checked item is determined as the target request.

[0048] The selection command can be implemented in several ways: it can be to check the checkboxes one by one; it can be to click the "Select All" box in the header to select all or deselect all at once; it can be to hold down the Shift key and click to select multiple ranges; it can be to click the "Invert Selection" button to switch the selection state; or it can be to click "Select Current Filter Result" above the filter results. After the user completes the selection, the panel will display "Import N Items" on the button in real time, and clicking it will generate rules in batches.

[0049] In this embodiment, after the user determines the target request from the candidate list, the system normalizes the request address of the target request. In one specific implementation, normalization includes: parsing path information and query parameters from the complete address; removing anchor points; removing query parameters belonging to a preset dynamic parameter set; sorting the remaining query parameters by key name and re-concatenating them; and combining the concatenated result with the path information to obtain the normalized path.

[0050] In one specific implementation, the preset dynamic parameter set includes any one or a combination of several of the following: timestamp parameters, cache corruption parameters, session identifier parameters, and pagination offset parameters. Correspondingly, the step of normalizing the request address of the target request based on a preset normalization rule to obtain a normalized path includes: after removing query parameters belonging to the preset dynamic parameter set, sorting the query parameters in the request address of the target request according to their key names, and concatenating the sorted query parameters to obtain concatenated query parameters; combining the concatenated query parameters with the path information in the request address to obtain the normalized path.

[0051] Regarding the sorting and concatenation of query parameters, one specific implementation is as follows: Parse the remaining query parameters into an array of key-value pairs, sort them in ascending lexicographical order by key name, then sort multiple values ​​with the same key name in lexicographical order by their values, and finally connect them with an AND sign in the form of "key=value" to obtain the concatenated query parameters; finally, combine the path information, question marks, and concatenated query parameters sequentially to obtain the normalized path; if the remaining query parameters are empty, the normalized path consists only of the path information, without the question mark. As another implementation, the key names and key values ​​can be uniformly normalized using percent sign encoding before sorting and concatenation to eliminate the differences caused by different encoding forms of the same character.

[0052] Subsequently, the system generates target request coverage rules based on the normalized path and the response body data corresponding to the target request. In one specific implementation, the rule name is automatically generated by the request method and path; the request type is taken from the method of the target request; the target path is taken from the normalized path; the response content preferentially adopts the response body from the candidate request; if the response body is empty, empty structured data (such as an empty object) is used as a fallback to ensure that the rule always has a returnable response body, avoiding exceptions thrown at runtime due to missing response content. After the rule is generated, the system adds it to the current project, saves it to the browser's local storage, and synchronously sends all enabled rules in the current project to the background debugger control module.

[0053] There are several possible implementation methods for rule generation: First, "select-and-import" can be used, which converts only the candidate requests selected by the user into rules; second, "full automatic import" can be used, which converts all filtered candidate requests into rules at once; third, "automatic import by threshold" can be used, for example, automatically importing only candidate requests with response status codes of 2XX and response body lengths greater than a preset value. Among these, full automatic import is more efficient but is prone to generating a large number of useless rules; selection-and-import is more suitable for ensuring rule quality.

[0054] In this way, after both ends adopt the same normalization rule, they are mapped to the same stable normalized string. The matching is transformed into a deterministic string comparison, which not only ensures the repeatability of the hit, but also ensures that the same interface corresponds to only one rule when collecting data multiple times, thus fundamentally suppressing rule duplication.

[0055] Step S14: When the user refreshes the page or performs a click operation, the browser debugger interface is used to intercept the request to the target page. If a request pause event is received, the request address of the paused request is normalized based on the preset normalization rule to obtain the path to be matched. The path to be matched is compared with the matching mode of the request coverage rule, and the hit rule is determined according to the corresponding comparison result.

[0056] In this embodiment, the background debugger control module enables the request pause capability for the target tab when an enabled rule exists, and constructs an interception pattern set according to the rule. When a user refreshes the page or performs an interaction such as clicking on the page, triggering a network request, the browser generates a request pause event before sending the request; the background module retrieves the address of the paused request in this event, obtains the path to be matched according to the same preset normalization rule as in step S13, then traverses the rules in the enabled state, compares the path to be matched with the matching pattern of each rule, and determines the matching rule based on the comparison result. The matching pattern is composed of the context path of the item to which the rule belongs and the target path of the rule.

[0057] It's important to note that only enabled rules are added to the active rule set; disabled rules are not included in runtime matching. When project rules are added, deleted, modified, or activated / disabled, the panel resends all enabled rules to the backend module. The backend module then rebuilds the interception mode and re-enables request interception capabilities for connected debugger sessions, making rule changes take effect immediately without requiring a browser restart or reattaching the debugger. The resulting technical benefits are twofold: firstly, disabled rules do not enter the matching loop, reducing the loop size from the total number of rules to the number of enabled rules. This significantly reduces the number of comparisons during each request pause when the rule base is large, minimizing the impact on page load time; secondly, there is no intermediate state requiring manual restart between rule changes and their effectiveness, avoiding misjudgments where rules are modified but the old response is still returned.

[0058] In one specific implementation, the matching pattern is the target path recorded in the request coverage rule or a path pattern containing wildcards; correspondingly, comparing the path to be matched with the matching pattern of the request coverage rule and determining the hit rule based on the comparison result includes: sequentially comparing the path to be matched with the matching pattern of the request coverage rule in the enabled state; if the path to be matched is the same as the matching pattern, then the request coverage rule is determined to be an exact match; if the matching pattern contains wildcards, then the matching pattern is converted into a regular expression, and the regular expression is matched with the path to be matched; if the match is successful, then the request coverage rule is determined to be a wildcard match; among all the request coverage rules determined to be matches, the request coverage rule with an exact match matching pattern is determined to be the hit rule; if there is no exact match request coverage rule, then the request coverage rule with a matching pattern path length that meets a preset length condition among the wildcard match rules is determined to be the hit rule.

[0059] Specifically, there are several ways to construct a matching pattern: First, when the target path of a rule is a relative path and the project to which it belongs has a context path configured, the context path and the target path are concatenated together to form the matching pattern; Second, when the target path of a rule is already a complete address, the address is used directly as the matching pattern without attaching a context path; Third, when a rule is explicitly marked as "ignore context", even if the project has a context path configured, it will not be concatenated, which is used to handle a few interfaces deployed under other prefixes in the project.

[0060] The preset length condition can be implemented in several ways: First, the longest priority is selected, that is, the longest matching pattern string is selected among all wildcard matching rules; second, the longest static prefix priority is selected, that is, the longest static part before the first wildcard in the matching pattern is selected, which reflects the specificity of the rule better than simply comparing the total length; third, the deepest path level priority is selected, that is, the rule with the most segments after being divided by the delimiter is selected; fourth, the rule with the fewest wildcards is selected, that is, when the lengths are similar, the rule with fewer wildcards is selected.

[0061] In this way, for any given set of requests and rules, the hit result is uniquely determined by the rule content itself and is independent of the storage order. The tool's behavior changes from unpredictable to fully predictable and interpretable. Users can infer runtime performance solely from the rule content, significantly reducing the cognitive burden of debugging tools. During the request hit phase, dynamic parameters are cleaned up first, and then priorities are calculated based on exact matches, wildcard matches, path lengths, and non-wildcard features. Broad rules are less likely to cover specific rules, and timestamped addresses are less likely to cause duplicate rules. Therefore, this invention improves the stability and interpretability of interception behavior.

[0062] Step S15: Determine the response body data of the hit rule as the target response body, and return the target response body to the target page through the browser debugger interface to achieve local response coverage of the network request.

[0063] In one specific implementation, the local response population module takes the response content from the matched rules as the response body, sets a structured data response header (e.g., content type application / json), encodes the response body according to the requirements of the browser debugger interface (e.g., converts it to a Base64 string), and returns it to the page via the population command corresponding to the request pause event. A response status code can also be set at the same time. If an exception occurs during the population process (e.g., the response body is too large, encoding fails, or the session is disconnected), the system executes a command to continue the original request; for requests that do not match any rules, the system also directly continues the original request.

[0064] There are several possible implementations for response padding: First, the response content is static structured data, which is returned directly as is; second, the response content is template data, and the placeholders in the template are replaced with the current time, a random number, or request parameters before being returned. This implementation focuses on static response overriding, and all of the above extension methods can be implemented on the same rule model.

[0065] It should also be noted that the premise for this application to determine the response body data of the hit rule as the target response body is that the rule is hit. Once the rule is hit, the response body data of the hit rule can be determined as the target response body, and the target response body can be returned to the target page through the browser debugger interface to achieve local response overriding of the network request. If the rule is not hit, the system continues the original request without affecting normal page access. In this way, the original request continues even when the rule is not hit or the overriding execution fails, without blocking the entire page due to a single rule error. Combined with the pre-refresh confirmation mechanism, this invention can reduce the interference of debugging tools on the page state.

[0066] As can be seen, this application combines browser debugger interface collection with network request archive file parsing to achieve a one-click conversion from real page requests to local response coverage rules, completing interface simulation without modifying business code or deploying a separate server. Simultaneously, through project and context path configuration, rules can be migrated and reused across different deployment environments, reducing the risk of cross-project path configuration errors. During the request interception phase, dynamic parameters are eliminated through preset normalization rules, combined with a matching mechanism prioritizing exact matching and path length, improving interface hit accuracy and preventing the false interception of static resources and broad rules covering specific interfaces. Furthermore, this application uses the debugger interface to directly complete request interception and response return locally in the browser, independent of backend service availability, allowing frontend development, testing, and problem reproduction to be performed independently of the real interface. Finally, through a complete closed-loop process of collection, rule generation, interception matching, and local response population, it provides developers with a ready-to-use, maintainable, and shareable local debugging solution.

[0067] Based on the previous embodiment, this application discloses a method for network request collection and local response coverage. First, a project is created or selected in the developer tools panel, and the context path of that project can be configured. When the developer needs to import a request from the current page, the panel sends a collection request to the background debugger control module. The background module attempts to attach to the current tab, enables network events and request pause capabilities, prioritizes reading existing network request history, and refreshes the page to recapture the request when necessary and permitted. The background module organizes the collection results into a network request archive format and returns it to the panel. The panel can also read external network request archive files and perform the same parsing, filtering, deduplication, and selection logic. After the user selects a target request, the system generates request coverage rules based on the request method, path, response content, and the project it belongs to, and immediately saves and synchronizes them to the background module. When the page initiates a request again, the background debugger control module receives a request pause event and calls the matching priority module to find the most suitable rule among the currently enabled rules. If a matching rule is found, the local response filling module encodes the response content in the rule into a browser-acceptable response body and returns it to the page; if no matching rule is found, the original request continues. Through the aforementioned closed loop, this invention connects real request collection, rule generation, and runtime coverage into a repeatable process.

[0068] In one specific implementation, the system executing the above method runs in a browser extension environment, including a developer tools panel, a project rules management module, a network request collection module, an archive file parsing module, a request filtering and deduplication module, a rule generation module, a background debugger control module, a matching priority module, a local response filling module, and an import / export module.

[0069] The relationships between the modules in the system principle block diagram are as follows: Figure 4 As shown, the developer tools panel provides the interaction entry point; the project rules management module saves projects, context paths, and rule sets; the network request collection module collects network data from the current tab; the archive file parsing module parses external network request archive files; the request filtering and deduplication module converts requests from different sources into a unified candidate list; the rule generation module converts user-selected candidate requests into overriding rules; the background debugger control module connects to the browser debugger interface and maintains the tab session; the matching priority module selects the best match in the enabled rules; the local response population module returns an overriding response to the page; and the import / export module is used for transferring projects or archive files between teams.

[0070] Among them, such as Figure 5 As shown, the project rules management module is used to maintain multiple projects. Each project includes at least a project identifier, project name, project description, context path, enabled status, rule list, creation time, and update time. Each rule under a project includes at least a rule identifier, rule name, request type, target path or matching pattern, response content, enabled status, original address, and source information. The project rules management module supports creating projects, editing projects, deleting projects, switching the current project, adding rules to projects, updating rules, deleting rules, counting enabled rules, and saving to browser local storage.

[0071] like Figure 6 As shown, the network request acquisition module is used to obtain network request data from the current page. This module prioritizes debugger mode, and its steps include: obtaining the current tab identifier; pre-checking the number of historical requests if necessary; deciding whether to allow page refresh based on user options; sending a debugger acquisition request to the backend; reading the network request archive format data returned by the backend; and if debugger mode fails to obtain a response body, it falls back to the standard acquisition mode of the developer tools network panel.

[0072] The background debugger control module enables network events during data collection, recording events such as request issuance, response reception, loading completion, and loading failure. After loading is complete, the system attempts to read the response body and organizes the response body, response headers, status code, request method, request address, execution time, and resource type into archived entries. Existing resource performance records can be merged as supplementary entries to reduce page refresh dependencies.

[0073] like Figure 7As shown, the archive file parsing module is used to read the network request archive file selected by the user. This module first verifies whether the archive file has a valid structure, checking for the presence of log fields, an array of entries, a request address, a request method, a response object, and a response status code. After successful verification, the module reads each request and response sequentially, generating candidate request objects. Each candidate request object contains the method, address, status code, status text, response size, response type, response content, whether it is selected, and the source identifier.

[0074] The request filtering and deduplication module filters non-API requests and retains candidates that are more suitable for generating rules. The filtering logic includes: excluding browser extension addresses, data addresses, and temporary object addresses; excluding static resources such as scripts, styles, images, fonts, audio / video files, and compressed packages; prioritizing entries whose resource type is explicitly asynchronous or data retrieval; treating submission, modification, and deletion requests as API requests; and treating requests containing API critical paths, structured request headers, or structured response types as API requests.

[0075] The rule generation module converts user-selected candidate requests into overriding rules within the project. The system extracts the path and query parameters from the complete address, removes dynamic parameters such as timestamps, and uses this path as the target path. Rule names are automatically generated from the request method and path. The response content prioritizes the response body from the candidate request; if the response body is empty, empty structured data is used as a fallback. After generating the rules, the system adds them to the current project, saves them to local storage, and notifies the backend to update all enabled rules.

[0076] The background debugger control module runs within the browser extension's background service. This module is responsible for attaching and detaching debuggers from target tabs, maintaining the debugger session set, enabling network domains and request pause capabilities, listening for request pause events and network events, and handling data collection requests and rule update requests. The background module only adds enabled rules to the active rule set; disabled rules are not included in runtime matching. When project rules are added, deleted, modified, or changed (enabled or disabled), the developer tools panel sends all enabled rules to the background module. The background module constructs a complete interception pattern based on the context path and target path of each rule and re-enables request interception capabilities for connected debugger sessions, ensuring rule changes take effect immediately.

[0077] The matching priority module selects the most suitable rule from the enabled rules for the current request. The system first cleans the dynamic timestamp parameter in the request URL, then extracts the path and query portion as the matching object. For each enabled rule, the system constructs a complete matching pattern based on the context path and the base rule path. If the matching pattern exactly matches the request path, it is considered an exact match; if the matching pattern contains wildcards, it is converted to a regular expression match. The system calculates the priority based on factors such as matching type, whether it is a non-wildcard, and path length, and selects the rule with the highest priority.

[0078] The local response population module is used to return a cover response after a request is paused. When a rule is matched, the system takes the response content from the rule as the response body, sets the structured data response header, encodes the response body according to the browser debugger interface requirements, and returns it to the page. If population fails, the system continues the original request to avoid a complete interruption of the page request due to a single rule exception. For requests that do not match a rule, the system directly continues the original request.

[0079] The import / export module supports two types of data exchange. The first is project configuration import / export. During export, the project name, description, context path, and rule list are saved; during import, project identifiers and rule identifiers are regenerated to avoid conflicts with existing data. The second is network request archive import / export. During import, external archive files are parsed into candidate requests; during export, project rules are converted into a standard network request archive format, enabling team members to exchange interface data using the same file type.

[0080] In one specific implementation, the key technical parameters and their values ​​involved in this solution can be set as follows: Network data acquisition timeout, used to limit the maximum waiting time for a single real-time acquisition, with a recommended value of approximately 30 seconds, to prevent the acquisition process from occupying the debugger session for an extended period; Page refresh wait time, used to wait for network requests to complete after a page refresh, with a recommended value of approximately 5 seconds and configurable, used only when historical requests are insufficient and the user allows refresh; Request collection wait time, used to collect requests that occur after a refresh or on the current page, with a recommended value of approximately 8 seconds and configurable, to improve the integrity of the response body and request list; Response body read concurrency, used to control the number of simultaneous response body reads, with a recommended value of 1 to 6, to prevent a large number of simultaneous read requests from causing browser debugger interface errors; Dynamic parameters... The cleanup list is used to remove cache corruption or timestamp parameters. Recommended values ​​are _t, t, timestamp, ts, cacheBust, etc. The cleaned results are used for deduplication and matching without changing the original request records. The matching type weight controls the priority between exact matches and wildcard matches. The value should be set so that exact matches are prioritized over wildcard matches to ensure that specific rules are hit first. The path length weight controls the priority of more specific paths. The value should be set so that the longer the path, the higher the weight to reduce false hits on broad paths. The response body integrity priority is used to retain more complete response content entries during deduplication. The value should be set so that the response body is longer to facilitate the generation of directly usable coverage rules.

[0081] It should be noted that the above parameter values ​​are recommended rather than limited, and those skilled in the art can adjust them according to page complexity, network environment, and browser version. For example, for complex back-end pages with a large number of requests on the first screen, the request collection waiting time can be appropriately extended to 12 seconds to improve the completeness of the collection; for interfaces with large response bodies, the response body reading concurrency can be reduced to below 2 to avoid the debugger interface being overwhelmed by too many read commands in a short period of time and returning an exception.

[0082] This approach integrates real page request collection and local response overriding rule generation within the same browser developer tools panel. Developers no longer need to repeatedly copy data between the network panel, text editor, mock server, and business code. Real responses can be directly converted into rules and executed immediately, thus reducing the time required for parallel front-end and back-end development, constructing abnormal scenarios, and reproducing problems. By reading the response body in debugger mode and reverting to standard collection mode in case of failure, the system can obtain as complete response content as possible while retaining basic request import capabilities when debugger mode is limited. Therefore, compared to solutions that rely solely on network panel exports, this invention is more tolerant of missing response bodies. Setting project, context path, and enabled status transforms rules from scattered addresses and response fragments into a maintainable collection organized by business project. Developers can enable, disable, export, and import rules in batches, reducing cross-project path configuration errors and improving team collaboration efficiency.

[0083] The implementation process of this invention will be further explained below with reference to several typical application scenarios.

[0084] In Application Example 1, a front-end developer discovers that the user information interface on a business system page is incomplete. The developer opens the browser's developer tools panel, creates a new project, and sets the context path; clicking "Live Import," the system collects current page requests in debugger mode, filtering out the user information and permission verification interfaces; the developer selects these two requests and imports them, and the system automatically generates rules. Subsequent page refreshes trigger the backend module to intercept the corresponding path and return a local response, allowing development to continue even if the backend interface is incomplete. In this scenario, if the backend interface is not yet provided, the developer can also directly create new rules and manually fill in the desired response structure. Once the backend interface is complete, the real response can be overwritten by the real import, thus achieving a smooth transition from contract-based to real-data-driven development.

[0085] Application Example 2: Testers reproduced a boundary data issue in the test environment and exported a network request archive file from the browser's network panel. Front-end developers imported this file locally, and the system verified the archive structure and parsed the request entries, filtering out structured interface requests. After selecting the target interface, the developers generated rules and directly reproduced the boundary data on their local page, without requiring testers to provide database permissions or a remote login environment.

[0086] Application Example 3: Multiple projects within the same team share the same interface path but have different deployment prefixes. Developers set context paths for different projects, while relative paths can be retained for the same set of rules. The runtime backend module automatically combines context paths and rule paths, selecting rules based on exact matching and path length priority, thereby reducing cross-project path confusion.

[0087] It should be further noted that there are various alternative implementation schemes for several technical aspects of the present invention, all of which fall within the protection scope of the present invention.

[0088] (1) The interception execution method can be replaced by browser declarative network rules, browser network request interface, service worker thread proxy, or local proxy server. Different execution methods have different limitations in terms of dynamic response body return, developer tool panel linkage, or cross-domain permissions, but all can achieve local response coverage by combining the rule generation and project management mechanism of this invention.

[0089] (2) Data acquisition methods can include importing archived files from external network requests or recording requests using page scripts. The external file method involves more steps, while the page script method is difficult to cover all network requests at the browser level; a hybrid acquisition method that prioritizes debugger mode can improve completeness.

[0090] (3) Data storage methods can include browser local storage, browser synchronous storage, file system, or remote collaboration services. Using remote services is beneficial for multiple people to synchronize, but it increases permissions, privacy, and network dependence; local storage is more suitable for development and debugging scenarios.

[0091] (4) Target path matching can use exact matching, prefix matching, wildcard matching, regular expression matching, or user-defined function matching. To reduce the user's understanding cost, exact matching plus wildcard matching can be used by default, and regular expression matching can be enabled in advanced mode.

[0092] (5) The rule generation method can be set to automatically import all candidate requests or to import after the user selects. Automatic import is more efficient, but it is easy to generate a large number of useless rules; import after the user selects is more suitable for ensuring rule quality.

[0093] (6) The response content can be static structured data, template data, script-generated data, delayed response, error status code, or dynamic response that changes according to the request parameters. This implementation focuses on static response coverage, and the extension method can support the above-mentioned dynamic response forms.

[0094] (7) Collaboration formats can include network request archives, project configuration files, interface collection files, or test case files. Network request archives have good compatibility with browser web panels, while project configuration files can retain management information such as project status and activation status.

[0095] See Figure 8 As shown, this embodiment of the invention discloses a network request collection and local response overlay device, comprising: The project creation or selection module 11 is used to create or select a project in the browser developer tools panel; the project includes a context path and several request coverage rules; The candidate request list acquisition module 12 is used to collect network requests and response bodies that have occurred on the current page through the browser debugger interface, and / or parse the network request archive file imported by the user, and convert the corresponding collected data and / or parsed data into a candidate request list with a preset unified field structure. The request coverage rule saving module 13 is used to determine the target request from the candidate request list based on the selection instruction, normalize the request address of the target request based on the preset normalization rule to obtain the normalized path, generate the target request coverage rule according to the normalized path and the response body data corresponding to the target request, and save the target request coverage rule to the project; the preset normalization rule includes at least removing query parameters that belong to the preset dynamic parameter set; The hit rule determination module 14 is used to intercept requests to the target page through the browser debugger interface when the user refreshes the page or performs a click operation. If a request pause event is received, the request address of the paused request is normalized based on the preset normalization rule to obtain the path to be matched. The path to be matched is compared with the matching mode of the request coverage rule, and the hit rule is determined according to the corresponding comparison result. The local response overriding implementation module 15 is used to determine the response body data of the hit rule as the target response body, and return the target response body to the target page through the browser debugger interface, so as to realize the local response overriding of the network request.

[0096] Since the embodiments of the device part correspond to the embodiments described above, please refer to the embodiments described in the method part for the embodiments of the device part, and will not be repeated here.

[0097] As can be seen, this application combines browser debugger interface collection with network request archive file parsing to achieve a one-click conversion from real page requests to local response coverage rules, completing interface simulation without modifying business code or deploying a separate server. Simultaneously, through project and context path configuration, rules can be migrated and reused across different deployment environments, reducing the risk of cross-project path configuration errors. During the request interception phase, dynamic parameters are eliminated through preset normalization rules, combined with a matching mechanism prioritizing exact matching and path length, improving interface hit accuracy and preventing the false interception of static resources and broad rules covering specific interfaces. Furthermore, this application uses the debugger interface to directly complete request interception and response return locally in the browser, independent of backend service availability, allowing frontend development, testing, and problem reproduction to be performed independently of the real interface. Finally, through a complete closed-loop process of collection, rule generation, interception matching, and local response population, it provides developers with a ready-to-use, maintainable, and shareable local debugging solution.

[0098] Furthermore, embodiments of this application also disclose an electronic device, Figure 9 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0099] Figure 9 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the network request acquisition and local response coverage method disclosed in any of the foregoing embodiments. Alternatively, the electronic device 20 in this embodiment may specifically be a computer.

[0100] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0101] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0102] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including computer programs capable of performing the network request acquisition and local response coverage method disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs capable of performing other specific tasks.

[0103] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned network request acquisition and local response overlay method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0104] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0105] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0106] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0107] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0108] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for collecting network requests and overlaying local responses, characterized in that, include: Create or select a project in the browser's developer tools panel; the project includes the context path and several request coverage rules; Collect network requests and response bodies that have occurred on the current page through the browser debugger interface, and / or parse the network request archive file imported by the user, and convert the corresponding collected data and / or parsed data into a candidate request list with a preset unified field structure; The target request is determined from the candidate request list based on the selection instruction. The request address of the target request is normalized based on the preset normalization rule to obtain the normalized path. The target request coverage rule is generated based on the normalized path and the response body data corresponding to the target request. The target request coverage rule is saved to the project. The preset normalization rule includes at least removing query parameters that belong to the preset dynamic parameter set; When a user refreshes the page or performs a click operation, the browser debugger interface is used to intercept the request to the target page. If a request pause event is received, the request address of the paused request is normalized according to the preset normalization rule to obtain the path to be matched. The path to be matched is compared with the matching mode of the request coverage rule, and the hit rule is determined according to the corresponding comparison result. The response body data of the hit rule is determined as the target response body, and the target response body is returned to the target page through the browser debugger interface to achieve local response coverage of the network request.

2. The network request collection and local response overlay method according to claim 1, characterized in that, Before collecting network requests and response bodies that have occurred on the current page through the browser debugger interface, the process also includes: The system detects the number of historical requests that already exist on the current page. If the number of historical requests is lower than a preset threshold, it outputs a prompt message asking whether to refresh the page. In response to the user's confirmation to refresh the page, the current page is refreshed and the data collection is re-executed.

3. The network request collection and local response overlay method according to claim 1, characterized in that, After collecting the network requests and response bodies that have occurred on the current page through the browser debugger interface, the process also includes: If the browser debugger interface does not obtain the response body, it falls back to the browser developer tools network panel mode to obtain the request record from the loaded resource performance entries, uses the request record as the collected data, and performs the step of converting it into a candidate request list with a preset unified field structure.

4. The network request collection and local response overlay method according to claim 1, characterized in that, Before converting the corresponding collected data and / or parsed data into a candidate request list with a preset unified field structure, the method further includes: The collected and / or parsed data is filtered to remove script files, style files, image files, font files, audio and video files, and browser extension address requests, resulting in filtered data. From the filtered data, identify interface requests based on structured response types, and / or match interface requests based on preset interface path keywords; The identified and / or matched interface requests are the data source for determining the candidate request list.

5. The network request collection and local response overlay method according to claim 1, characterized in that, The step of determining the target request from the candidate request list based on the selection instruction includes: The candidate request list is displayed in the browser developer tools panel; each entry in the candidate request list includes at least the request method, request address, response status code, and response body size. In response to a user's selection of one or more items in the candidate request list, the selected item is determined as the target request.

6. The network request collection and local response overlay method according to claim 1, characterized in that, The preset dynamic parameter set includes any one or a combination of several of the following: timestamp parameters, cache corruption parameters, session identifier parameters, and page offset parameters. Accordingly, the step of normalizing the request address of the target request based on a preset normalization rule to obtain a normalized path includes: After removing the query parameters that belong to the preset dynamic parameter set, the query parameters in the request address of the target request are sorted according to the key name, and the sorted query parameters are concatenated to obtain the concatenated query parameters. The concatenated query parameters are combined with the path information in the request address to obtain a normalized path.

7. The network request collection and local response overlay method according to any one of claims 1 to 6, characterized in that, The matching pattern is the target path recorded in the request coverage rule or a path pattern containing wildcards; Accordingly, comparing the path to be matched with the matching pattern of the request coverage rule, and determining the hit rule based on the comparison result, includes: The path to be matched is compared sequentially with the matching pattern of the request coverage rule that is in the enabled state; If the path to be matched is the same as the matching pattern, then the request coverage rule is determined to be an exact match; If the matching pattern contains wildcards, then the matching pattern is converted into a regular expression, and the regular expression is matched against the path to be matched. If a match is found, the request coverage rule is determined to be a wildcard match; Among all the request coverage rules that are determined to be a match, the request coverage rule with the matching mode of exact match is determined as the hit rule; If no exact match request coverage rule exists, then the request coverage rule in the wildcard matching rule whose matching pattern path length meets the preset length condition will be determined as the hit rule.

8. A network request collection and local response overlay device, characterized in that, include: The project creation or selection module is used to create or select a project in the browser's developer tools panel; the project includes a context path and several request coverage rules; The candidate request list acquisition module is used to collect network requests and response bodies that have occurred on the current page through the browser debugger interface, and / or parse the network request archive file imported by the user, and convert the corresponding collected data and / or parsed data into a candidate request list with a preset unified field structure; The request coverage rule saving module is used to determine the target request from the candidate request list based on the selection instruction, normalize the request address of the target request based on the preset normalization rule to obtain the normalized path, generate the target request coverage rule according to the normalized path and the response body data corresponding to the target request, and save the target request coverage rule to the project. The preset normalization rule includes at least removing query parameters that belong to the preset dynamic parameter set; The hit rule determination module is used to intercept requests to the target page through the browser debugger interface when the user refreshes the page or performs a click operation. If a request pause event is received, the request address of the paused request is normalized based on the preset normalization rule to obtain the path to be matched. The path to be matched is compared with the matching mode of the request coverage rule, and the hit rule is determined according to the corresponding comparison result. The local response overriding implementation module is used to determine the response body data of the hit rule as the target response body, and return the target response body to the target page through the browser debugger interface, so as to realize the local response overriding of the network request.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing a computer program to implement the steps of the network request acquisition and local response overlay method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, A computer program is stored on a computer-readable storage medium, which, when executed by a processor, implements the steps of the network request acquisition and local response overlay method as described in any one of claims 1 to 7.

Images