Web page caching method based on http request

Abstract

The invention discloses a Web page caching method based on an http (Hyper Text Transport Protocol) request. The page caching method comprises the following steps: requesting interface identifier setting; unifying request methods; performing cache judgment and acquiring data; carrying out data decryption and verification; performing data display and updating decision making; original request processing and data returning are carried out; and the page logic is re-executed and rendered. The security of the cache data is effectively protected, and the intelligent front-end page request cache optimization system is realized.

Description

Technical Field

[0001] The present invention relates to the field of web pages, and particularly to a Web page caching method based on HTTP requests. Background Art

[0002] With the continuous development and complexity of Web applications, the frequency of data interaction between the front-end pages and the back-end services has increased significantly. Traditional data request patterns often rely on frequent network requests, which not only increases the processing pressure on the server but also may degrade the user experience due to network latency. To alleviate this problem, front-end developers usually adopt caching techniques to store the already fetched data so that it can be directly retrieved locally when needed later, reducing network requests. However, traditional caching strategies often have the following problems: First, they lack flexibility and cannot dynamically adjust the caching usage strategy according to the timeliness of data, the request status, and business logic; second, it is difficult to ensure data consistency, and the cached data may become outdated due to server data updates; third, they have insufficient security, and the cached data may face the risk of leakage.

[0003] To implement caching of page data, existing technical solutions usually make corresponding preparations from the very beginning of the engineering design and are bound to the state management of single-page applications (SPAs). Specifically, it is to design which data needs to be cached during the project preparation stage in advance, and then develop the code accordingly. Although this method improves the data interaction efficiency to a certain extent, it has the following deficiencies.

[0004] 1. High transformation difficulty. For projects that have been developed halfway or are about to end, adding the need for page caching often requires a large amount of transformation work, which not only increases the development cost but also may affect the already developed pages and functions.

[0005] 2. Poor data security. Due to the scattered cache points and the lack of a unified data encryption mechanism, the cached data is prone to the risk of leakage.

[0006] 3. Complex system state management. In an SPA, the management of the cached application state and the current application state becomes complex, which is likely to cause abnormal system behavior or crashes. Summary of the Invention

[0007] In view of the above problems, the present invention is proposed to provide a Web page caching method based on HTTP requests that overcomes the above problems or at least partially solves the above problems.

[0008] According to one aspect of the present invention, there is provided a Web page caching method based on HTTP requests, the page caching method comprising:

[0009] Setting of request interface identifiers;

[0010] Unified request method;

[0011] Perform cache judgment and obtain data;

[0012] Perform data decryption and verification;

[0013] Perform data display and update decision-making;

[0014] Perform original request processing and data return;

[0015] Re-execute and render the page logic.

[0016] Optionally, the setting of the request interface identifier specifically includes:

[0017] Users or developers first specify in the configuration file or directly in the code which HTTP request interface data needs to be cached;

[0018] The setting of the interface identifier uniquely identifies the characteristics of the request based on the request URL, request method, and request parameters.

[0019] Optionally, the unified request method specifically includes:

[0020] Responsible for handling all HTTP requests sent by the front end;

[0021] Realize unified monitoring, logging, and application of cache logic for requests;

[0022] Integrate a request interceptor for cache judgment before the request is sent;

[0023] Integrate a response interceptor for data processing and cache update after the response is received;

[0024] Interrupt the request in a timely manner when it is determined that the request is not required.

[0025] Optionally, the HTTP request specifically includes initiating a request, receiving a response, and handling errors.

[0026] Optionally, the performing cache judgment and obtaining data specifically includes:

[0027] In the unified request management method, when a request is received, check whether the interface identifier of the request has been set to require caching;

[0028] If so, further determine whether the time since the last successful request to this interface exceeds the preset cache expiration period, or whether an error occurred in the last request;

[0029] If the cache usage conditions are met, instead of immediately initiating a new network request, an attempt is made to read data from the local cache.

[0030] Optionally, the local cache uses the browser's localStorage, sessionStorage, or IndexedDB storage mechanism, and a suitable storage method is selected according to the persistence and access frequency of the data.

[0031] Optionally, the data decryption and verification specifically include:

[0032] Since the cached data involves sensitive information, when reading the cached data, decryption processing is first performed;

[0033] The decryption process uses a pre-defined encryption algorithm and key;

[0034] After successful decryption, the original data that can be used for subsequent processing is obtained;

[0035] After decryption, the system performs validity verification on the data;

[0036] The verification content includes the timestamp, signature, and version number information of the data;

[0037] If the data verification fails, the data is regarded as invalid data, and the system will continue to wait for the return of the data of the original request or display an error prompt message to the front-end user according to the preset rules.

[0038] Optionally, the data display and update decision specifically includes:

[0039] If the cached data is determined to be valid and suitable for display after decryption and verification, the data in the local cache is directly used as the result returned by the interface for the front-end page to use;

[0040] The front-end page processes the data according to the normal business process for page rendering and interaction;

[0041] A flag or timer is set to track the progress or waiting time of the original request;

[0042] If the original request successfully returns data within the preset time, compare the returned data with the cached data to determine whether to update the cache or trigger a page re-render;

[0043] If the original request fails or times out, select to use the cached data or display an error prompt message according to the business requirements.

[0044] Optionally, the original request processing and data backhaul specifically include:

[0045] While the page is displaying the cached data, the original request successfully returns data and processes the data;

[0046] The processing content includes data decryption, formatting, and verification;

[0047] After the processing is completed, the system will update the local cache, encrypt the new data, and store it in the corresponding storage mechanism;

[0048] Trigger a callback mechanism or event notification to pass the new data back to the front-end page;

[0049] After the front-end page receives the new data, it selects whether to immediately use the new data to re-render the page or execute other business logics according to the business requirements.

[0050] Optionally, the re-execution and rendering of the page logic specifically include:

[0051] According to the characteristics of the new data and the business requirements, the front-end page will re-execute the corresponding business logic;

[0052] The business logic includes data parsing, status update, and event triggering;

[0053] After the execution is completed, the front-end page will use the new data to re-render the page;

[0054] The rendering process includes DOM operations, style updates, and animation effects;

[0055] By re-rendering the page, it ensures that the information seen by the user is always the latest and meets the requirements of the business logic;

[0056] Record the timestamp or version number information of the page rendering for performance monitoring and optimization.

[0057] A Web page caching method based on http requests provided by the present invention, the page caching method includes: setting the request interface identifier; unifying the request method; performing cache judgment and obtaining data; performing data decryption and verification; making decisions on data display and update; performing original request processing and data back transmission; re-executing and rendering the page logic. It effectively protects the security of the cached data and realizes an intelligent front-end page request caching optimization system.

[0058] The above description is only an overview of the technical solution of the present invention. In order to be able to understand the technical means of the present invention more clearly, it can be implemented according to the content of the description. And in order to make the above and other purposes, features, and advantages of the present invention more obvious and understandable, the specific embodiments of the present invention are specifically given below. Brief Description of the Drawings

[0059] To more clearly illustrate the technical solutions of the embodiments of the present invention, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0060] Figure 1 It is a flowchart of a Web page caching method based on HTTP requests provided by an embodiment of the present invention. Detailed implementation manners

[0061] The following will describe the exemplary embodiments of the present disclosure in more detail with reference to the drawings. Although the exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided so that the present disclosure can be more thoroughly understood and the scope of the present disclosure can be fully conveyed to those skilled in the art.

[0062] The terms "including" and "having" and any variations thereof in the description of the embodiments, the claims and the drawings of the present invention are intended to cover non-exclusive inclusion. For example, a series of steps or units are included.

[0063] The following will further describe the technical solutions of the present invention in detail in combination with the drawings and embodiments.

[0064] As Figure 1 shown, a Web page caching method based on HTTP requests includes:

[0065] Step 1: Request interface identifier setting

[0066] The user or developer first specifies through a configuration file or directly in the code which data of the HTTP request interfaces needs to be cached. This step is the basis for the subsequent caching logic, ensuring that only specific requests will be included in the cache management scope of the system. The setting of the interface identifier can be based on the characteristics that uniquely identify the request, such as the URL of the request, the request method (such as GET, POST, etc.), and the request parameters.

[0067] Step 2: Unified request method

[0068] To uniformly manage and optimize the request process, the present invention designs a unified request management method. This method is responsible for processing all HTTP requests sent by the front end, including initiating requests, receiving responses, handling errors, etc. The unified request management method not only simplifies the request process but also realizes unified monitoring of requests, logging, and application of cache logic. In the method, request interceptors can be integrated to perform cache judgment before the request is sent; at the same time, response interceptors can also be integrated to perform data processing and cache update after the response is received. And the request can be interrupted in time when it is determined that the request is not needed.

[0069] Step 3: Cache Judgment and Data Retrieval

[0070] In the unified request management method, when a request is received, first check whether the interface identifier of the request has been set to require caching. If so, further determine whether the time since the last successful request for this interface exceeds the preset cache expiration period, or whether an error occurred in the last request (such as network timeout, server error, etc.). If the cache usage conditions are met (i.e., the expiration period is exceeded or an error occurred), do not immediately initiate a new network request, but try to read data from the local cache. The local cache can use storage mechanisms such as the browser's localStorage, sessionStorage, or IndexedDB, and select an appropriate storage method according to the persistence and access frequency of the data.

[0071] Step 4: Data Decryption and Verification

[0072] Since the cached data may involve sensitive information (such as user information, payment vouchers, etc.), during the process of reading the cached data, decryption processing needs to be performed first. The decryption process uses a pre-defined encryption algorithm and key to ensure data security. After successful decryption, the original data that can be used for subsequent processing can be obtained. After decryption, the system also needs to perform validity verification on the data. The verification content can include information such as the timestamp, signature, and version number of the data to ensure the timeliness, integrity, and correctness of the data. If the data verification fails (such as the data has expired, the signature does not match, etc.), the data is regarded as invalid data, and the system will continue to wait for the data returned by the original request or display an error prompt message to the front-end user according to the preset rules.

[0073] Step 5: Data Display and Update Decision

[0074] If the cached data is determined to be valid and suitable for display after decryption and verification, the system directly uses the locally cached data as the result returned by the interface for the front-end page to use. The front-end page processes this data according to the normal business process for page rendering and interaction. At the same time, the system also needs to set a flag or timer to track the progress or waiting time of the original request. If the original request successfully returns data within the preset time, the system needs to compare the returned data with the cached data to determine whether to update the cache or trigger a page re-render. If the original request fails or times out, the system can choose to use the cached data or display an error message according to the business requirements.

[0075] Step 6: Original Request Processing and Data Transmission

[0076] While the cached data is being displayed on the page, the system does not give up waiting for the original request. Once the original request successfully returns data, the system immediately processes the data. The processing content can include data decryption (if the data is encrypted), formatting, verification, etc. After processing, the system updates the local cache, encrypts the new data and stores it in the corresponding storage mechanism. At the same time, the system triggers a callback mechanism or event notification to transmit the new data back to the front-end page. After receiving the new data, the front-end page can choose whether to immediately use the new data for page re-rendering or execute other business logic according to the business requirements.

[0077] Step 7: Re-execution and Rendering of Page Logic

[0078] According to the characteristics of the new data and the business requirements, the front-end page re-executes the corresponding business logic. The business logic can include data parsing, status update, event triggering, etc. After execution, the front-end page re-renders the page using the new data. The rendering process can include DOM operations, style updates, animation effects, etc. By re-rendering the page, it ensures that the information seen by the user is always the latest and meets the requirements of the business logic. At the same time, the system also needs to record information such as the timestamp or version number of the page rendering for subsequent performance monitoring and optimization.

[0079] A Web page caching system based on HTTP requests, comprising:

[0080] A request interface identifier setting module for setting the request interface identifier;

[0081] A unified request encapsulation module for unifying the request method;

[0082] A cache judgment and data acquisition module for cache judgment and data acquisition;

[0083] A data decryption and verification module for data decryption and verification;

[0084] Data display and update decision-making module, used for data display and update decision-making;

[0085] Original request processing and data feedback module, used for original request processing and data feedback;

[0086] Page logic re-execution and rendering module, used for page logic re-execution and rendering, realizing the functions of the intelligent front-end page request caching optimization system.

[0087] Beneficial effects:

[0088] Performance improvement: Through the caching mechanism, unnecessary network requests are significantly reduced, the server load is decreased, the page loading speed is accelerated, and the user experience is improved.

[0089] Data consistency: Through the refined caching management strategy and the intelligent data verification and update mechanism, the consistency between the cached data and the server data is ensured, avoiding page display problems caused by expired or incorrect data.

[0090] Flexibility: The system supports custom caching strategies. Developers can flexibly set the caching time, encryption method, verification rules, etc. according to business requirements, improving the adaptability and maintainability of the system.

[0091] Security: Through the data encryption and decryption mechanism, data verification mechanism, and secure storage method, the security of the cached data is guaranteed, preventing the leakage of sensitive information.

[0092] Scalability: The system is designed modularly, which is easy to integrate into the existing front-end framework and is also convenient for subsequent function expansion and optimization. For example, integrating more caching strategies, data verification rules, or combining with other front-end performance optimization technologies (such as code splitting, lazy loading, etc.).

[0093] Intelligence: The system realizes intelligent caching and dynamic update of front-end page requests through the intelligent data verification and update mechanism, page logic re-execution and rendering mechanism, etc., improving the intelligence level and automation degree of the system.

[0094] The above specific implementation manners further elaborate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above are only the specific implementation manners of the present invention and are not used to limit the protection scope of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A web page caching method based on http request, characterized in that: The page caching method comprises: Request interface identification setting; Unified request method; Perform cache judgment and obtain data; Decrypt and verify data; Make data display and update decisions; Perform original request processing and data return; Page logic is re-executed and rendered.

2. A method for caching web pages based on http requests according to claim 1, characterized in that: The request interface identification setting specifically includes: The user or developer first specifies which HTTP request interface data needs to be cached through a configuration file or directly in the code; The interface identifier is set based on the request URL, request method, and request parameters to uniquely identify the request characteristics.

3. A method for caching web pages based on http requests according to claim 1, characterized in that: The unified request method specifically includes: Responsible for processing all HTTP requests issued by the front end; Implemented unified monitoring, logging, and caching logic for requests; Integrated request interceptor to make cache decisions before a request is sent; Integrated response interceptor for data processing and cache update after receiving the response; After determining that the request is not necessary, interrupt the request in time.

4. A method for caching web pages based on http requests according to claim 3, characterized in that: The HTTP request specifically includes initiating a request, receiving a response, and handling an error.

5. A method for caching web pages based on http requests according to claim 1, characterized in that: The cache determination and data acquisition specifically include: In the unified request management method, when a request is received, it is checked whether the interface identifier of the request has been set to require caching; If yes, then further determine whether the current time from the last successful request to the interface exceeds the preset cache validity period, or whether an error occurred in the last request; If the cache usage conditions are met, a new network request is not initiated immediately, but an attempt is made to read data from the local cache.

6. A method for caching web pages based on http requests according to claim 5, characterized in that: The local cache uses the browser's localStorage, sessionStorage or IndexedDB storage mechanism, and selects a suitable storage method according to the persistence and access frequency of the data.

7. A method for caching web pages based on http requests according to claim 1, characterized in that: The data decryption and verification specifically include: Since the cached data involves sensitive information, decryption is performed first when reading the cached data; The decryption process uses a predefined encryption algorithm and key; After successful decryption, the original data is obtained and can be used for subsequent processing; After decryption, the system verifies the validity of the data; The verification content includes the data’s timestamp, signature, and version number information; If the data verification fails, it will be regarded as invalid data, and the server will continue to wait for the data of the original request to be returned or display an error prompt message to the front-end user according to the preset rules.

8. A method for caching web pages based on http requests according to claim 1, characterized in that: The data display and update decision specifically include: If the cached data is determined to be valid and suitable for display after decryption and verification, the locally cached data is directly used as the result returned by the interface for use by the front-end page; The front-end page processes data according to normal business processes and performs page rendering and interaction; Set a flag or timer to track the progress or wait time of the original request; If the original request successfully returns data within the preset time, the returned data is compared with the cached data to determine whether the cache needs to be updated or the page needs to be re-rendered; If the original request fails or times out, choose to use cached data or display an error message based on business needs.

9. A method for caching web pages based on http requests according to claim 1, characterized in that: The processing of the original request and the data transmission specifically include: While the page displays the cached data, the original request successfully returns the data and processes the data; The processing content includes data decryption, formatting, and verification; After the processing is completed, the system will update the local cache and encrypt the new data and store it in the corresponding storage mechanism; Trigger a callback mechanism or event notification to pass the new data back to the front-end page; After the front-end page receives new data, it chooses whether to use the new data to re-render the page or execute other business logic immediately based on business needs.

10. A method for caching web pages based on http requests according to claim 1, characterized in that: The page logic re-execution and rendering specifically include: According to the characteristics of the new data and business requirements, the front-end page will re-execute the corresponding business logic; Business logic includes data parsing, status updating, and event triggering; After the execution is completed, the front-end page will re-render the page with the new data; The rendering process includes DOM operations, style updates, and animation effects; By re-rendering the page, it ensures that the information the user sees is always up-to-date and meets the requirements of business logic; Record the timestamp or version number information of page rendering for performance monitoring and optimization.

Images