A front-end interface request management method, an electronic device, a storage medium and a program product

Abstract

This application provides a front-end interface request management method, electronic device, storage medium, and program product. The method includes: obtaining context features of interface requests initiated by a front-end application; the context features are used to characterize the real-time attributes, execution environment, and user intent of the interface request; classifying the interface requests based on the context features and determining processing strategies corresponding to different categories; and performing corresponding processing operations on the interface requests according to the processing strategies, the processing operations including at least one of request aggregation, cache reading, or real-time forwarding. Different categories of requests can be matched with the most suitable processing strategies, and differentiated scheduling of request traffic is achieved, reducing network resource waste caused by redundant requests, improving cache hit rate and response speed, and constructing a full-link request management system with context awareness, dynamic decision-making, and strategy coordination capabilities.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a front-end interface request management method, electronic device, storage medium, and program product. Background Technology

[0002] Modern web front-end applications are becoming increasingly complex. Architectural patterns such as Single Page Applications (SPAs) and Progressive Web Applications (PWAs) require frequent data exchange between front-end applications and back-end services via APIs.

[0003] Currently, there is a need for a front-end API request management solution that can deeply integrate intelligent aggregation, adaptive caching, and dynamic retry strategies to improve network resource utilization, enhance system stability, and improve user experience. Summary of the Invention

[0004] The purpose of this application is to provide a front-end interface request management method, electronic device, storage medium, and program product to achieve end-to-end management of front-end interface requests, improve network resource utilization, system response speed and stability, and optimize user experience.

[0005] The first aspect of this application provides a front-end interface request management method, the method comprising: Obtain the context features of the interface request initiated by the front-end application; the context features are used to characterize the real-time attributes, execution environment, and user intent of the interface request; Based on the aforementioned contextual features, the interface requests are categorized, and processing strategies corresponding to different categories are determined. According to the processing strategy, corresponding processing operations are performed on the interface request, including at least one of request aggregation operation, cache read operation, or real-time forwarding operation.

[0006] In the above implementation process, by obtaining the context features of the interface request, the request is dynamically classified based on the context features, so that different types of requests can be matched with the most appropriate processing strategy. By executing at least one of the processing operations of request aggregation, cache reading or real-time forwarding, differentiated scheduling of request traffic is realized, reducing the waste of network resources caused by redundant requests, improving cache hit rate and response speed, and building a full-link request management system with context awareness, dynamic decision-making and strategy coordination capabilities.

[0007] Furthermore, obtaining the contextual features of the interface request initiated by the front-end application includes: Extract the request initiation timestamp, request parameter set, and request header information of the interface request; The context features are determined based on the request initiation timestamp, the request parameter set, and the request header information.

[0008] In the above implementation process, by extracting the request initiation timestamp, request parameter set, and request header information of the interface request, context features are constructed from the time dimension, query intent dimension, and environment dimension. This enables the system to accurately perceive the real-time status of the request, user needs, and operating environment, providing a basis for subsequent classification and differentiated scheduling.

[0009] Furthermore, classifying the interface requests based on the context features and determining the processing strategies corresponding to different categories includes: Based on at least one of the following characteristics of the interface request: request method, criticality level, and response data characteristics, the interface request is classified to obtain a classification result; the criticality level is used to characterize the priority of the interface request determined based on user intent or business requirements. Based on the classification results, the appropriate processing strategy for the interface request is determined.

[0010] In the above implementation process, by classifying interface requests based on at least one of the following characteristics: request method, criticality level, and response data characteristics, the system can match the most suitable processing strategy for each request according to its inherent attributes and business semantics. This achieves differentiated scheduling of request traffic, ensures the real-time performance of high-priority requests, and improves the utilization efficiency of cache resources.

[0011] Further, the request aggregation operation is performed through the following steps: Multiple interface requests belonging to the same batch processing group are merged and scheduled to generate an aggregated request. Configure a time window; the time window is used to control the aggregated waiting time for interface requests; When the time window expires, the aggregation request is sent, and the received response data is distributed to the corresponding interface requests.

[0012] In the above implementation, multiple interface requests belonging to the same batch processing group are merged and scheduled into an aggregate request. A dynamically adjustable time window is used to control the aggregation waiting time. When the time window expires, the aggregate request is sent uniformly, and the response data is distributed to each original request. This merges multiple network round trips into one, reducing network connection overhead and server load. Simultaneously, a balance is achieved between aggregation efficiency and response latency through dynamic configuration of the time window.

[0013] Further, perform the cache read operation through the following steps: If the cached data corresponding to the interface request is hit, the response data is read from the cache and returned to the front-end application; If the cached data corresponding to the interface request is not found, a real-time request is initiated to obtain the response data and return it to the front-end application.

[0014] In the above implementation, a fast response channel for frontend interface requests is established through cache read operations that return results upon cache hit and retrieve data in real time upon cache miss. When the cache is hit, network waiting time and backend load are reduced, improving user experience; when the cache is missed, real-time requests ensure data retrieval.

[0015] Furthermore, real-time forwarding is performed through the following steps: Send the interface request; If a success response is received, the success response is returned to the front-end application; If the request fails, the failed request is classified as an error, and a retry request is initiated based on the corresponding retry strategy determined according to the error type.

[0016] In the above implementation process, by classifying failed requests in real-time forwarding operations and retrying based on error type, the system can identify the cause of failure and dynamically select the most appropriate retry strategy, thereby ensuring the final success rate of requests while avoiding request storms or resource waste caused by blind retries.

[0017] Furthermore, after performing the corresponding processing operation on the interface request according to the processing strategy, the method further includes: Obtain performance metrics for the processing operation, including at least one of request latency, cache hit rate, aggregation efficiency, retry success rate, and error distribution; The processing strategy is adjusted based on the performance metrics.

[0018] In the above implementation process, by obtaining performance indicators such as request latency, cache hit rate, aggregation efficiency, retry success rate and error distribution after the processing operation is executed, and adjusting the processing strategy based on the real-time feedback of these indicators, the problems of static parameter configuration and lack of self-optimization capability in related technologies are solved.

[0019] Furthermore, adjusting the processing strategy based on the performance metrics includes: Adjust the upper limit of concurrent requests based on network connection type or network quality; and / or, Adjust the time window length for request aggregation based on request latency or aggregation efficiency.

[0020] In the above implementation process, it can accurately respond to changes in the external network environment and internal performance feedback, ensuring the real-time performance of high-priority requests while dynamically balancing response speed and resource utilization, thereby improving the overall performance of the system under complex and ever-changing network conditions.

[0021] Furthermore, the method also includes: The performance indicators are input into a multi-dimensional evaluation model to obtain the evaluation results; If the evaluation results indicate that the strategy is less effective than the expected threshold, the processing strategy will be adjusted.

[0022] In the above implementation process, the problems of optimization blind spots and decision-making biases caused by the lack of comprehensive evaluation were solved, and the refined, goal-oriented adaptive tuning of the processing strategy was achieved.

[0023] A second aspect of this application provides an electronic device, the electronic device comprising: processor; Memory used to store processor-executable instructions; Wherein, when the processor invokes the executable instructions, it implements any of the methods described in the first aspect.

[0024] A third aspect of this application provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of any of the methods described in the first aspect.

[0025] A fourth aspect of this application provides a computer program product, the computer program product including a computer program, which, when executed by a processor, implements any of the methods described in the first aspect. Attached Figure Description

[0026] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 A flowchart illustrating a front-end interface request management method provided in an embodiment of this application; Figure 2 A schematic diagram of an overall process provided for an embodiment of this application; Figure 3 An example diagram of enterprise protection provided for embodiments of this application; Figure 4This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0028] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0029] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0030] Among related technologies, mainstream API request management solutions suffer from the following technical problems: 1. Request redundancy and network resource waste: Multiple components or modules in a front-end application may request the same or similar data simultaneously or within a short period of time. Due to the lack of an intelligent aggregation mechanism, a large number of duplicate requests occupy network connections, increase server load, and reduce overall performance.

[0031] 2. Problems with simplistic caching strategies and rigid invalidation mechanisms: Traditional front-end caching solutions often use simple key-value pair storage, lacking multi-level caching strategies based on data characteristics, access patterns, and real-time network conditions. The cache invalidation mechanism is inflexible, which can easily lead to outdated data or low cache hit rates.

[0032] 3. Lack of intelligent adaptability in retry mechanisms: Traditional retry strategies typically use a fixed number of retries and intervals, which cannot be adaptively adjusted according to error type, network status, and historical success rate, easily causing request storms or delays in fault recovery.

[0033] 4. Resource contention and priority conflict issues: The lack of a unified priority scheduling mechanism between different types of requests (such as critical business requests, preloading requests, and retry requests) may cause low-priority requests to block high-priority requests, affecting user experience.

[0034] 5. Static configuration of system parameters and lack of self-optimization: Traditional solutions mostly use static parameter settings, which cannot be dynamically adjusted according to runtime performance data and user behavior, and lack a closed-loop mechanism from execution feedback to strategy optimization.

[0035] Specifically, one related API request processing method includes: receiving an API request sent by a client, wherein the API request includes the target domain name to be accessed by the API request and the target interface identifier under the target domain name; obtaining the target domain name and target interface identifier from the API request; determining the target business server cluster corresponding to the API request based on configuration data, the target domain name and target interface identifier, and determining the target business server in the target business server cluster that receives the API request; and sending the API request to the target business server. This method achieves API request routing based on the target domain name and target interface identifier in the API request. By considering more information in the API request during API request routing, the accuracy of API request routing is improved.

[0036] However, this related technology does not address issues such as performance optimization, resource management, and fault tolerance.

[0037] Another related API request processing method, applied to an edge computing platform, includes the following steps: The API request is first input into an Nginx server acting as an HTTP server. The Nginx server then reverse proxies the API request and inputs it into the API gateway service layer. The API gateway service layer maps the API request information into an MQTT message and sends the MQTT message to the backend sub-service layer. The sub-service process subscribes to the corresponding topic based on the type of information being processed. When the sub-service program subscribes to the response MQTT message, it parses the MQTT message, performs logical processing, and generates a response message, which is then published through the MQTT proxy server. The response message is sent back to the API gateway service layer to generate an API request response, which is then transmitted to the Nginx server. Finally, the Nginx server outputs the API request response.

[0038] However, this technology only solves the protocol compatibility problem in specific scenarios. At the architectural adaptation level, its technical solution does not address challenges such as network performance optimization, resource scheduling, and adaptive fault tolerance, and does not possess context awareness, predictive optimization, and continuous learning capabilities.

[0039] To address any of the aforementioned issues, this application proposes a method for intelligent aggregation, caching, and retry strategy management of front-end API requests (which shares the same concept as the aforementioned front-end interface request management method). By acquiring the contextual features of the interface request, the method dynamically classifies the request based on the contextual features to match differentiated processing strategies. After performing processing operations such as request aggregation, cache reading, or real-time forwarding, the method continuously monitors performance indicators and adaptively adjusts the processing strategy to achieve intelligent management of the entire lifecycle of the interface request.

[0040] Based on this, embodiments of this application provide a front-end interface request management method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating a front-end interface request management method provided in an embodiment of this application.

[0041] In this embodiment, the method includes: Step S10: Obtain the context features of the interface request initiated by the front-end application; the context features are used to characterize the real-time attributes, execution environment, and user intent of the interface request; It should be noted that when a front-end application (such as a single-page application in a browser, a mobile application, or a mini-program) needs to interact with a back-end service, it will initiate an interface request (such as an HTTP request). In this embodiment, the interface request is intercepted or captured at the beginning of the request, and contextual features that can describe the scenario and attributes of the request are extracted from it.

[0042] Real-time attributes: The characteristics of the request in the time dimension, such as the timestamp of the request (which can be used to determine whether it is during peak hours, request intervals, etc.), network connection type (Wi-Fi, 5G, weak network, etc.), and current network quality (such as signal strength, bandwidth estimate).

[0043] Execution environment: Characteristics of the application environment in which the request is initiated, such as device type (phone, tablet, PC), operating system version, browser type, the current page route of the application, device memory status, battery status, etc. This information helps to determine the device's processing capabilities and resource limitations.

[0044] User intent: The purpose of user behavior inferred from the request itself. For example, this can be gleaned from information such as the request's Uniform Resource Identifier (URI), request parameters (e.g., query keywords, pagination information), and the triggering method of the request (whether it's triggered by a user's active click or by automatic page preloading). For instance, a request to access a product details page may indicate a user's purchase intent.

[0045] Step S20: Based on the context features, classify the interface requests and determine the processing strategies corresponding to different categories; It should be noted that classification can be based on multiple dimensions. For example: Request methods: GET requests are generally used to query data and may be suitable for caching; while POST, PUT, and DELETE requests are used to modify data and usually require real-time forwarding.

[0046] Criticality Level: Assign different priorities to requests based on user intent or business needs. For example, requests in core business processes such as payment and order placement are of high criticality level and their timeliness and success rate should be prioritized; while requests used to preload the next page of content or report logs have a lower criticality level and can tolerate some delay or retrying on failure.

[0047] Response data characteristics: Classify the data based on the characteristics of the requested data. For example, requests for static data that does not change frequently, such as device lists or product categories, are suitable for a caching-first strategy; requests for dynamic data with extremely high timeliness requirements, such as real-time stock prices or online user counts, are suitable for a real-time direct connection strategy.

[0048] Based on the above classification, the processing strategy corresponding to each category can be determined. For example, three basic strategy pipelines are defined: Request aggregation pipeline: Suitable for a type of request that can be processed in a combined manner, such as multiple GET requests that query the same API but have different parameters.

[0049] Cache-first pipeline: Suitable for requests that do not have high requirements for data real-time performance but require fast response. The system will prioritize reading data from the cache.

[0050] Real-time direct connection pipeline: Suitable for requests that are highly critical or have strict requirements for data real-time performance. The system will directly forward the requests to the backend service.

[0051] Step S30: According to the processing strategy, perform corresponding processing operations on the interface request. The processing operations include at least one of request aggregation operation, cache read operation, or real-time forwarding operation.

[0052] It's important to note that request aggregation involves merging multiple API requests that arrive within a short period (within a dynamically adjusted time window) and belong to the same batch processing group into a single aggregated request, which is then sent to the backend service. After receiving the batch response data from the backend, the system then distributes the data back to the respective frontend callers based on the original request mappings. This reduces network round trips and lowers server load.

[0053] Cache read operations: If a request is categorized into the cache-first pipeline, the system first queries the local or remote cache. If the cache is hit, the response data is read directly from the cache and returned to the frontend; the entire process requires no network requests, resulting in a fast response. If the cache is missed, the process falls back to a real-time forwarding operation, retrieving data from the backend and determining whether to write the newly retrieved data to the cache and, if so, which cache level, based on the data access pattern and real-time requirements.

[0054] Real-time forwarding operation: If the request is categorized into the real-time direct connection pipeline, the system will send the request directly to the backend service. If the request succeeds, the response returned by the backend will be returned to the frontend via the same path. If the request fails, the system will adaptively select a retry strategy (such as incremental interval) and initiate a retry based on the error type (such as network timeout) and the current context information to improve the success rate of the request.

[0055] In this embodiment, by obtaining the context features of the interface request, the request is dynamically classified based on the context features, so that different types of requests can be matched with the most appropriate processing strategy. By executing at least one processing operation among request aggregation, cache reading or real-time forwarding, differentiated scheduling of request traffic is realized, reducing the waste of network resources caused by redundant requests, improving cache hit rate and response speed, and building a full-link request management system with context awareness, dynamic decision-making and strategy coordination capabilities.

[0056] Based on any of the above embodiments, obtaining the context features of the interface request initiated by the front-end application includes: Extract the request initiation timestamp, request parameter set, and request header information of the interface request; The context features are determined based on the request initiation timestamp, the request parameter set, and the request header information.

[0057] It's important to note that the request initiation timestamp represents the precise moment the frontend application initiated the API request. For example, 1648456789123 (corresponding to Beijing time 2022-03-28 15:19:49.123). This timestamp can be used to analyze the temporal distribution characteristics of requests, such as whether it occurs during peak business hours and the time interval between adjacent requests, thus providing a basis for subsequent strategies such as aggregation window adjustment and cache preloading.

[0058] Request parameter set: All parameter information carried in the API request, including query parameters and path parameters in the URL, as well as form parameters or JSON data in the request body. These parameters reflect the user's specific query intent and data requirements, and serve as the basis for judging request similarity, performing aggregation, or caching.

[0059] Request headers refer to the metadata contained in the HTTP request headers, including User-Agent (client type and version), Accept-Language (language preference), Authorization (identity credentials), Referer (originating page), and custom business header fields. Request headers are used to infer the execution environment (such as device capabilities), user identity, and the context of the request.

[0060] After extracting the above three types of raw data, a comprehensive analysis is performed to transform them into structured contextual features that can characterize the real-time attributes of the request, the execution environment, and the user's intent. Specifically: By using the request initiation timestamp, the initiation time of the request, its temporal order relative to other requests, and the time interval with the previous request of the same type can be calculated, thus obtaining real-time attribute characteristics (such as peak-hour requests, dense request sequences). By using the request parameter set, the user's specific operational intent (such as pagination, search, filtering), the granularity of the data query, and the idempotency characteristics of the request can be parsed, thus generating user intent characteristics (such as browsing intent, query intent). By using the request header information, device type (mobile / PC), browser version, network standard (indirectly inferred through User-Agent or a custom header), user identity level, and source page path can be extracted, thus obtaining execution environment characteristics (such as weak network environment, high-privilege user, homepage source).

[0061] By integrating the above multi-dimensional information, the complete contextual characteristics of the interface request can be obtained. For example, the system may comprehensively determine that this is a product category query request initiated by a high-privilege user during a low-peak business period in a PC Wi-Fi environment. This provides a basis for subsequent classification decisions (such as whether aggregation is possible or whether to prioritize caching).

[0062] In this embodiment, by extracting the request initiation timestamp, request parameter set, and request header information of the interface request, contextual features are constructed from the time dimension, query intent dimension, and environment dimension. This enables the system to accurately perceive the real-time status of the request, user needs, and operating environment, providing a basis for subsequent classification and differentiated scheduling.

[0063] Based on any of the above embodiments, classifying the interface requests based on the context features and determining the processing strategies corresponding to different categories includes: Based on at least one of the following characteristics of the interface request: request method, criticality level, and response data characteristics, the interface request is classified to obtain a classification result; the criticality level is used to characterize the priority of the interface request determined based on user intent or business requirements. Based on the classification results, the appropriate processing strategy for the interface request is determined.

[0064] It's important to note that the request method refers to the HTTP method type used for the API request, including GET (retrieving resources), POST (creating resources), PUT (updating resources), and DELETE (deleting resources). The request method is fundamental for determining the idempotency and safety of a request: for example, GET requests are generally used for queries, do not change the server-side state, and are suitable for caching and aggregation; while POST, PUT, and DELETE requests involve data changes and typically require real-time forwarding to ensure data consistency.

[0065] Criticality Level: A priority label set for API requests based on user intent or business requirements. This level can be carried by the frontend when initiating the request (e.g., through request headers) or dynamically determined by the system based on contextual characteristics such as the request's URI and originating page. For example: High Criticality Level: Requests involving critical business operations such as payment, order placement, and login have extremely high requirements for real-time performance and success rate, and require priority to ensure network resources and retry opportunities.

[0066] Medium-criticality level: Core data requests during page initialization (such as product lists and dashboard main charts) have certain requirements for response speed, but short-term delays or degradation are acceptable.

[0067] Low Criticality Level: Non-core requests such as preloading requests, log reporting, and user behavior tracking can tolerate higher latency and aggregation waiting.

[0068] Response data characteristics: The inherent attributes of the data expected to be obtained in the request, which can be characterized from dimensions such as data change frequency, timeliness requirements, and data volume. For example: Static data, such as device type enumeration values, country / region lists, and system configuration parameters, rarely changes and are suitable for long-term caching.

[0069] Near real-time data: such as product inventory, user points, and statistical indicators for the most recent hour, with a moderate change frequency, which can be cached for a short period of time.

[0070] Real-time data, such as real-time stock prices, number of online users, and chat messages, has extremely high timeliness requirements and is not suitable for caching; it must be obtained in real time.

[0071] Specifically, based on one or more of the above characteristics, each interface request is classified to obtain a classification result. This result can be a label or identifier used to characterize the category to which the request belongs. For example, requests can be classified as "aggregatable query requests," "high-priority real-time change requests," or "static data requests suitable for caching," etc.

[0072] After obtaining the classification results, they are mapped to a predefined processing strategy pipeline to match the most appropriate processing method for each request. Optionally, the following mapping relationship can be established: If the classification result is "aggregable query requests" (feature combination: GET request + low to medium criticality level + near real-time data characteristics), then the appropriate request aggregation strategy is determined.

[0073] If the classification result is "static data requests suitable for caching" (feature combination: GET request + low to medium criticality level + static data characteristics), then the caching priority strategy is determined to be applicable.

[0074] If the classification result is "high-priority real-time change request" (feature combination: POST / PUT / DELETE request + high criticality level + real-time data characteristics), then the real-time forwarding strategy is determined to be applicable.

[0075] In this embodiment, interface requests are classified based on at least one of the following features: request method, criticality level, and response data characteristics. This enables the system to match the most suitable processing strategy for each request based on its inherent attributes and business semantics, thereby achieving differentiated scheduling of request traffic, ensuring the real-time performance of high-priority requests, and improving the utilization efficiency of cache resources.

[0076] Based on any of the above embodiments, the request aggregation operation is performed through the following steps: Multiple interface requests belonging to the same batch processing group are merged and scheduled to generate an aggregated request. Configure a time window; the time window is used to control the aggregated waiting time for interface requests; When the time window expires, the aggregation request is sent, and the received response data is distributed to the corresponding interface requests.

[0077] It should be noted that once an interface request is categorized as applicable to a request aggregation strategy, the system will assign it to the corresponding batch processing group for unified management.

[0078] Batch group: A collection of API requests with the same or similar characteristics that can be processed together. Specifically, the criteria for determining whether requests belong to the same batch group may include: the same API endpoint (e.g., / api / products), similar request structure, compatible parameter formats, etc. For example, multiple GET requests targeting the product query API / api / products but with different parameters can be grouped into the same batch group.

[0079] Merging and scheduling refers to the process of integrating and processing multiple independent requests belonging to the same batch processing group. The system does not immediately forward each arriving request, but instead temporarily stores them in the batch processing queue, awaiting subsequent unified processing.

[0080] Specifically, multiple independent interface requests are merged into a single request containing multiple parts of information (i.e., the aggregated request).

[0081] It should be understood that a time window is configured for each batch group in order to strike a balance between waiting for more aggregateable requests and avoiding excessively long response delays.

[0082] Time window: The duration from when the first request enters the batch processing group until the aggregation request is triggered and sent. The length of this time window is not fixed but can be dynamically adjusted based on network conditions, request priorities, historical data, etc. For example, in scenarios with good network conditions and users expecting fast responses, the time window can be set to a shorter 10-20 milliseconds; in scenarios with network congestion or low request priority, the time window can be appropriately extended to 50-100 milliseconds to aggregate more requests and reduce the overall number of network round trips.

[0083] Aggregation wait time: The time a request waits in the batch queue to be merged. During this period, newly arriving requests belonging to the same batch group will be continuously added to the batch.

[0084] In the implementation, when the time window expires, the system stops waiting for the batch and enters the sending phase. The generated aggregation request is sent to the backend service via a single network round trip. This reduces network connection overhead by merging requests that would otherwise require multiple round trips into one. After processing the aggregation request, the backend returns an aggregated response containing multiple data parts. Upon receiving this response, the system needs to break down the data according to the correspondence between the original requests and distribute it to the callers of the original interface requests.

[0085] In this embodiment, multiple interface requests belonging to the same batch processing group are merged and scheduled into an aggregated request. A dynamically adjustable time window is used to control the aggregation waiting time. When the time window expires, the aggregated request is sent uniformly, and the response data is distributed to each original request. This merges multiple network round trips into one, reducing network connection overhead and server load. Simultaneously, a balance is achieved between aggregation efficiency and response latency through dynamic configuration of the time window.

[0086] Based on any of the above embodiments, the cache read operation is performed through the following steps: If the cached data corresponding to the interface request is hit, the response data is read from the cache and returned to the front-end application; If the cached data corresponding to the interface request is not found, a real-time request is initiated to obtain the response data and return it to the front-end application.

[0087] It should be noted that when an interface request is determined to be subject to the cache priority strategy, the system first checks the cache storage to see if there is valid response data corresponding to the current request.

[0088] A cache hit occurs when the system queries the cache using the identifier of the current API request (such as a cache key generated based on the URI and request parameters) and finds a valid, usable copy of the response data. The cache can be deployed in memory (such as Redis or browser memory), local persistent storage (such as IndexedDB or LocalStorage), or a server-side cache, with the specific level and location determined by system configuration. Once a hit occurs, the system directly reads the pre-saved response content from the cache storage without initiating a network request. This process reduces response latency. The retrieved response data is then encapsulated in a standard format (such as JSON) and returned to the front-end caller via a callback or Promise mechanism from the original request. The front-end application then uses this data for UI rendering or business logic processing.

[0089] For example, in an e-commerce application, when a user visits a product category page for the first time, they request a "list of mobile phone products." The system determines that this request is suitable for caching, but there is no data in the cache yet, so it misses the cache and proceeds to the step of "initiating a real-time request to obtain the response data and return it to the front-end application." Subsequently, when the user visits the same category page again, the system intercepts the request again. This time, the product list data stored in the previous request already exists in the cache and has not expired, so it hits the cache. The system then reads the data from the cache and returns it, and the page renders quickly without the user having to wait for network loading.

[0090] If valid data for the current request is not found in the cache, a fallback process will be performed, and the latest data will be retrieved from the backend using a regular network request.

[0091] Possible reasons for a cache miss include: the first request for the data, the cache having expired, the cache being actively cleared, or the requested identifier not matching the cache key.

[0092] Initiating a real-time request refers to the system constructing a standard network request (such as an HTTP request), including the original request's URI, parameters, headers, and other information, and sending it to the backend service. This process is no different from the traditional direct request method. Afterward, the backend processes the request and returns response data. The system receives this data and returns it to the frontend caller, completing the processing of this request.

[0093] For example, when a user first visits a product category page, if the cache is not hit, the system initiates a real-time request, and the backend returns a list of products. The system then sends this data to the frontend, and the page renders normally. Subsequent requests (such as those accessed within the cache's validity period) will be responded to quickly due to a cache hit.

[0094] In this embodiment, a fast response channel is established for front-end interface requests through a cache read operation that returns a result upon cache hit and retrieves data in real time upon cache miss. When the cache is hit, network waiting time and backend load are reduced, improving user experience; when the cache is missed, a real-time request ensures data retrieval.

[0095] Based on any of the above embodiments, the real-time forwarding operation is performed through the following steps: Send the interface request; If a success response is received, the success response is returned to the front-end application; If the request fails, the failed request is classified as an error, and a retry request is initiated based on the corresponding retry strategy determined according to the error type.

[0096] It should be noted that when an interface request is classified as applicable to the real-time forwarding strategy, the system will construct a standard network request based on the original request's target address, parameters, and header information, and send it to the backend service.

[0097] After processing the request, the backend service returns an HTTP response containing a status code and response body data. Upon receiving this response, the system first determines if it is a successful response (usually based on the status code). If it is a successful response, the system directly returns the response data to the frontend application, completing the processing of this request. A successful response indicates that the request has been successfully received, understood, and processed.

[0098] If an exception occurs during the request sending process, or if the backend returns a response indicating failure (such as 4xx client error, 5xx server error, network timeout, connection reset, etc.), the system will enter the error handling and retry process.

[0099] First, the reasons for failure are categorized to allow for differentiated responses. Optionally, error categorization can be based on multiple dimensions: Errors are categorized by source: client-side errors (e.g., incorrect request parameters, insufficient permissions, corresponding to 4xx), server-side errors (e.g., internal errors, service unavailable, corresponding to 5xx), and network layer errors (e.g., DNS resolution failure, connection timeout, TLS handshake failure). Errors are categorized by nature into retryable errors (such as network timeouts and temporary server 5xx failures) and non-retryable errors (such as 400 Bad Request and 401 Unauthorized, where retries are meaningless). For non-retryable errors, the system typically throws the error directly to the upper layer without initiating a retry. Based on severity, errors are divided into minor errors (such as occasional packet loss) and major errors (such as service outages).

[0100] Specifically, based on the error category, the most suitable retry strategy is selected from a predefined or dynamically adjusted retry strategy library. A retry strategy includes the following elements: Maximum number of retries: Set based on the error type and request criticality level. For example, a network timeout can be retried 3 times, a server 5xx error can be retried 2 times, while a 4xx error cannot be retried.

[0101] Retry interval: Determines the waiting time between two retries.

[0102] Retry conditions: Specify under what circumstances retries are allowed. For example, only idempotent requests (such as GET and PUT) should be retried, while non-idempotent requests (such as POST) should be handled with caution.

[0103] Timeout control: Each retry can be set with an independent timeout period to avoid retries accumulating due to slow service.

[0104] Based on the selected retry strategy, the original request is resent after a specified interval. After each retry, the system updates the retry counter and dynamically adjusts subsequent strategies based on real-time feedback (e.g., if there are consecutive failures, the next retry interval can be extended). If the maximum number of retry attempts is reached and the request still fails, the failure result is finally returned to the frontend application.

[0105] In this embodiment, by classifying failed requests in real-time forwarding operations and retrying based on error type, the system can identify the cause of failure and dynamically select the most appropriate retry strategy, thereby ensuring the final success rate of requests while avoiding request storms or resource waste caused by blind retries.

[0106] Based on any of the above embodiments, after performing the corresponding processing operation on the interface request according to the processing strategy, the method further includes: Obtain performance metrics for the processing operation, including at least one of request latency, cache hit rate, aggregation efficiency, retry success rate, and error distribution; The processing strategy is adjusted based on the performance metrics.

[0107] It should be noted that the processing operations refer to the aforementioned request aggregation operations, cache read operations, or real-time forwarding operations. Each operation generates corresponding execution records and performance data upon completion.

[0108] Request latency: The total time elapsed from the initiation (or interception) of an API request to the receipt of a complete response. This metric directly reflects user experience and system response speed. For aggregated requests, latency refers to the time from the first request entering the batch processing group to the return of the aggregated response; for cache reads, it refers to the time for cache lookup plus data return; for real-time forwarding, it refers to the network round-trip time plus backend processing time.

[0109] Cache hit rate: The percentage of cache read requests that successfully retrieve data from the cache out of the total number of cache read requests. Cache hit rate reflects the effectiveness of the caching strategy and the utilization of cache space.

[0110] Aggregation efficiency: The percentage of network requests saved by request aggregation operations. This metric reflects the effectiveness of aggregation strategies in saving network resources.

[0111] Retry success rate: In real-time forwarding operations, the proportion of requests that are retried due to failures but ultimately succeed.

[0112] Error distribution: The frequency and percentage of various error types (such as network timeouts, server-side 5xx errors, client-side 4xx errors, etc.) in total requests. By analyzing the error distribution, we can identify system weaknesses and abnormal patterns. For example, a sudden increase in the error rate of a certain type may indicate backend service failure or network problems.

[0113] Adjusting processing strategies: Based on performance feedback, modify the decision logic, parameter configuration, or execution method of the strategies to adapt to the current system state and user behavior patterns. The targets of adjustment are request aggregation strategies, cache read strategies, real-time forwarding strategies, and their classification rules. Adjustment methods include, but are not limited to: Adjusting classification rules: For example, if it is found that the response data of a certain type of GET request changes frequently (the cache hit rate continues to decline), the system can reclassify it from the cache priority pipeline to the real-time direct connection pipeline or the short-term cache pipeline. Adjusting aggregation parameters: For example, if the monitored request latency is too high and the aggregation efficiency improvement is not significant (i.e., there are few aggregateable requests collected within the aggregation window), the system can shorten the aggregation time window to prioritize response speed; conversely, if the network is idle and the aggregation efficiency is high, the window can be appropriately extended to aggregate more requests. Adjust caching strategies: For example, if the cache hit rate of a certain type of data is consistently low, the system can extend its cache expiration time or upgrade it to a faster cache level (such as upgrading from disk cache to memory cache); if the hit rate is normal but complaints about outdated data are increasing, the expiration time can be shortened or a cache refresh mechanism can be added. Adjust retry strategies: For example, if the retry success rate of a certain type of error is extremely low (such as the continuous occurrence of server-side 5xx errors), the system can reduce the number of retries, extend the retry interval, or directly downgrade the handling (such as returning a friendly prompt) to avoid unnecessary retries increasing the server load; if frequent network fluctuations lead to an increase in timeout errors, the number of retries can be appropriately increased. Adjusting concurrency control: For example, the system can dynamically adjust the upper limit of the number of concurrent requests based on the overall request latency and error distribution. When network congestion or increased backend pressure is detected, the concurrency of low-priority requests is automatically reduced to prioritize bandwidth for high-priority requests; as network conditions improve, the restrictions are gradually lifted.

[0114] Through continuous monitoring and dynamic adjustments, the system can adaptively optimize its behavior and maintain optimal performance under different load conditions, network environments, and user scenarios.

[0115] In this embodiment, by obtaining performance indicators such as request latency, cache hit rate, aggregation efficiency, retry success rate, and error distribution after the processing operation is executed, and adjusting the processing strategy based on the real-time feedback of these indicators, the problems of static parameter configuration and lack of self-optimization capability in related technologies are solved.

[0116] Based on any of the above embodiments, adjusting the processing strategy according to the performance indicators includes: Adjust the upper limit of concurrent requests based on network connection type or network quality; and / or, Adjust the time window length for request aggregation based on request latency or aggregation efficiency.

[0117] It's important to note that network connection type refers to the network access method currently used by the front-end application, typically including Wi-Fi, 5G, 4G, 3G, and weak network conditions (such as 2G / Edge when the signal is extremely poor). Different types of networks have different bandwidth, latency, and stability characteristics. For example, Wi-Fi generally has high bandwidth, low latency, and good stability; 5G networks have high bandwidth but latency may vary due to signal fluctuations; 4G networks are relatively stable but have limited bandwidth; and weak network environments have extremely low bandwidth, high latency, and a high packet loss rate. The system can obtain this information through the Network Information API provided by the browser or the network status interface of the mobile system.

[0118] Network quality: A quantitative assessment of the current network connectivity status, which may include dynamic metrics such as real-time signal strength, estimated bandwidth, round-trip time (RTT), and packet loss rate. Compared to relatively static network connection types, network quality better reflects instantaneous changes in network conditions. For example, even if a user is in a Wi-Fi environment, network quality metrics can promptly reflect changes in signal strength caused by interference.

[0119] Maximum number of concurrent requests: The maximum number of network requests the system is allowed to initiate at the same time. Excessive concurrency may exhaust the browser's connection pool, put excessive pressure on backend services, or cause network congestion; insufficient concurrency will limit page loading speed and resource utilization.

[0120] The system dynamically adjusts the maximum number of concurrent requests based on real-time monitoring of network connection types or network quality indicators. For example: Scenario 1 (Network Type Driven): When the system detects that a user has switched from Wi-Fi to 4G, it automatically reduces the concurrent request limit from 12 to 6 to avoid request queuing and congestion due to bandwidth reduction; when the user reconnects to Wi-Fi, the limit is restored to 12.

[0121] Scenario 2 (Network Quality Driven): The system continuously monitors the round-trip time (RTT) and packet loss rate of requests. When the average RTT increases from 50ms to 200ms, or the packet loss rate exceeds 2%, it is determined that the network quality has deteriorated. In this case, the concurrency limit for low-priority requests is reduced from 8 to 3 to prioritize bandwidth for high-priority requests. Once the network quality recovers, the restrictions are gradually lifted.

[0122] Request latency refers to the time from when a request is initiated to when a complete response is received. In aggregation operations, latency includes aggregation waiting time plus backend processing time and network transmission time. Excessive request latency directly impacts user experience.

[0123] Aggregation efficiency: The percentage of network requests saved through aggregation operations, or the average number of original requests contained in an aggregation batch. For example, if an aggregation request combines 5 original requests, the aggregation efficiency can be quantified as "saving 4 network round trips" or "average batch size = 5". The higher the aggregation efficiency, the more significant the saving effect on network resources.

[0124] Time window length: A parameter used to control the aggregation waiting time. The window length directly affects the aggregation effect: the longer the window, the more requests may be aggregated (higher aggregation efficiency), but the waiting time will increase (higher request latency); the shorter the window, the faster the response, but it may miss aggregateable requests (reduced aggregation efficiency).

[0125] Specifically, based on real-time monitored request latency or aggregation efficiency metrics, the length of the time window is dynamically adjusted to strike a balance between response speed and aggregation effectiveness. For example: Scenario 1 (Latency-Driven): The system monitors that the request latency of a certain API consistently exceeds a preset threshold (e.g., 500ms). Analysis reveals that the latency is mainly due to excessively long aggregation wait times. Therefore, the system shortens the time window of the batch group corresponding to this API from 50ms to 20ms, prioritizing response speed.

[0126] Scenario 2 (Efficiency Driven): System analysis of aggregation operation logs revealed that a certain batch processing group could only aggregate an average of 1.2 requests within a 50ms window (i.e., most batches contained only 1 request, resulting in low aggregation efficiency). Due to good network conditions and users' insensitivity to latency, the system extended the time window from 50ms to 80ms to aggregate more requests. After the adjustment, the average batch size increased to 2.5, significantly reducing the overall number of network requests.

[0127] Scenario 3 (Comprehensive Trade-off): The system establishes a multi-objective optimization model, simultaneously monitoring request latency and aggregation efficiency. When the latency is found to be within an acceptable range (e.g., <300ms), the system prioritizes extending the window to improve efficiency; when the latency approaches the threshold, the system shortens the window to ensure user experience.

[0128] In addition, in some embodiments, adjusting the processing strategy based on the performance metrics includes at least one of the following: Adjust the upper limit of the number of concurrent requests based on the network connection type or network quality; Adjust the time window length for request aggregation based on request latency or aggregation efficiency; Adjust the expiration time or cache level of the caching strategy based on the cache hit rate; Adjust the number of retries or the retry interval of the retry strategy based on the retry success rate or error distribution; Adjust the priority scheduling rules for requests based on real-time network conditions.

[0129] In this embodiment, the system can accurately respond to changes in the external network environment and internal performance feedback. While ensuring the real-time performance of high-priority requests, it dynamically balances response speed and resource utilization, thereby improving the overall performance of the system under complex and ever-changing network conditions.

[0130] Based on any of the above embodiments, the method further includes: The performance indicators are input into a multi-dimensional evaluation model to obtain the evaluation results; If the evaluation results indicate that the strategy is less effective than the expected threshold, the processing strategy will be adjusted.

[0131] It should be noted that a multi-dimensional evaluation model is a mathematical model or algorithm used to analyze and quantify the effectiveness of an evaluation strategy.

[0132] Optionally, the multi-dimensional evaluation model is constructed based on any of the following methods: Weighted scoring model: Different weights are assigned to each performance metric, and a weighted composite score is calculated. For example, for critical business scenarios, request latency and retry success rate can be given higher weights; for resource-sensitive scenarios, aggregation efficiency and cache hit rate can be given higher weights.

[0133] Threshold assessment model: A baseline threshold is set for each indicator, and the indicator is graded based on the degree to which it exceeds or falls below the threshold. For example, a request latency of <200ms is excellent, 200-500ms is good, and >500ms is poor.

[0134] Machine learning models: These utilize historical data to train classification or regression models to predict and evaluate the effectiveness of current strategies. For example, an anomaly detection model can be trained to identify anomalous patterns in a combination of indicators.

[0135] Rule Engine: A comprehensive evaluation is made based on a set of rules developed with expert experience. For example, Rule 1: If the cache hit rate is <30% and the request latency is >1 second, the caching strategy is deemed invalid; Rule 2: If the retry success rate is <50% and the proportion of 5xx errors in the error distribution is >20%, the backend service is deemed unstable.

[0136] The evaluation results may be: Numerical type: such as a comprehensive score of 85 points (out of 100).

[0137] Grade-based: such as Excellent, Good, Average, Poor.

[0138] Tag type: such as normal, need attention, abnormal, invalid.

[0139] Binary type: such as above the threshold / below the threshold.

[0140] Expected thresholds can be absolute values ​​(e.g., overall score < 60 points), grade boundaries (e.g., a poor evaluation result), or dynamic benchmarks (e.g., below 20% of historical averages). Thresholds can be dynamically adjusted based on business objectives, service level agreements, or historical data. For example: For the core transaction chain, a strict threshold can be set: an adjustment will be triggered if the overall score is less than 90 points.

[0141] For non-core data preloading requests, a relatively lenient threshold can be set: adjustments are only triggered when the evaluation result is poor.

[0142] A strategy's effectiveness falling below the expected threshold indicates that the evaluation results did not meet the preset acceptable standards, suggesting that the current processing strategy may be ineffective, inefficient, or mismatched with the current environment and needs. For example, a weighted scoring model outputting a comprehensive score of 55 (threshold 60) suggests that the overall strategy performance is poor. A rating evaluation result of "poor" (threshold set to "medium" or above) suggests that intervention is needed. An anomaly detection model outputs anomaly labels, indicating that an abnormal pattern exists in the combination of indicators.

[0143] Once the effectiveness of the strategy is detected to be below the threshold, optimization adjustments to the processing strategy are triggered. These adjustments include, but are not limited to: adjusting classification rules (reclassifying requests); adjusting aggregation parameters (modifying time window length and batch group division rules); adjusting caching strategies (changing cache levels, expiration times, and refresh mechanisms); adjusting retry strategies (modifying the number of retries, interval algorithms, and retry conditions); and adjusting concurrency control (modifying the maximum number of concurrent requests and priority scheduling rules).

[0144] Optionally, the method further includes: The performance indicators are input into a multi-dimensional evaluation model to obtain the evaluation results; If the evaluation results indicate that the strategy is less effective than the expected threshold, the processing strategy will be adjusted.

[0145] If the assessment results indicate the presence of an abnormal pattern, an alert is triggered.

[0146] Understandably, when the evaluation results indicate that the strategy's effectiveness is below the expected threshold, it means that the current processing strategy has experienced quantifiable performance degradation (such as slower response and reduced hit rate). In this case, optimization should be performed through automatic strategy adjustments (such as modifying the aggregation window and cache time) to restore the system to normal levels. When the evaluation results indicate the presence of abnormal patterns, it means that unexpected abnormal states, possibly caused by faults or external attacks, have been detected (such as a sudden increase in error rate or drastic fluctuations in metrics). In this case, an alert should be triggered first to notify operations and maintenance personnel to intervene and investigate, avoiding potential misoperations that may result from automatic adjustments.

[0147] In this embodiment, the problems of optimization blind spots and decision-making biases caused by the lack of comprehensive evaluation are solved, and the refinement and goal-oriented adaptive tuning of the processing strategy are realized.

[0148] Furthermore, based on the same concept as the aforementioned front-end API request management method, this application embodiment also provides a method for intelligent aggregation, caching, and retry strategy management of front-end API requests. (Refer to...) Figure 2 , Figure 2 This is a schematic diagram of an overall process provided for an embodiment of this application.

[0149] In this embodiment, the method includes: 1: Request reception and feature extraction.

[0150] The system receives API requests initiated by the front-end application layer and extracts the data characteristics of the requests. These metadata characteristics include: the request's Uniform Resource Identifier (URI), HTTP method type, request parameter set, request header information, and request initiation timestamp. The request parameter set is then normalized, including sorting parameter key-value pairs, filtering null values, and masking specific parameters to generate a standardized parameter representation.

[0151] 2: Classification decision generation.

[0152] Based on the metadata features extracted in step 1, a globally unique request fingerprint is generated using a preset hash function. A request classification decision tree is then established, and requests are classified according to a classification function based on the request's HTTP method, criticality level, response data characteristics, etc. Based on the classification results, requests are routed to the corresponding processing pipeline: a batch aggregation pipeline, a cache-first pipeline, or a real-time direct connection pipeline.

[0153] 3: Batch scheduling.

[0154] For requests routed to different pipelines, batch scheduling and execution optimization are performed: After a batch request group issues a request, an intelligent scheduler is established to monitor the following status indicators of each batch processing group: number of requests within the group, number of times a request is initiated, and request response time. These values ​​are recorded to optimize subsequent request strategies. A dynamic time window is maintained for each batch processing group. The initial value of the time window is set based on historical statistics of network latency and can be dynamically adjusted according to the current network quality.

[0155] 4: Request processing and fault tolerance management.

[0156] The response to a successful request is formatted and returned to the front end. At the same time, the size of the response content and the response speed are recorded for the optimizer to use as a reference.

[0157] For all failed network requests, error classification and root cause analysis are performed. An error classifier is built to categorize request errors based on their source and nature, and feature vectors are extracted to guide the initiation of retry requests. For different error types, appropriate retry strategies are selected, and retry requests are initiated.

[0158] 5: Performance monitoring and adaptive strategy optimization.

[0159] Establish a continuous monitoring and optimization loop: Collect detailed performance metrics for each request, including but not limited to: Request latency: the time from request initiation to receiving a response; Cache hit rate: the hit rate of each cache level; Aggregation efficiency: the network overhead saved by batch requests; Retry success rate: the success rate of various retry strategies; Error distribution: the frequency and distribution of various errors. Dynamically adjust the upper limit of concurrent requests based on the current network connection type and quality. When network congestion is detected, automatically reduce the concurrency of low-priority requests and prioritize bandwidth for high-priority requests.

[0160] 6: Strategy effectiveness evaluation and analysis.

[0161] Establish a multi-dimensional evaluation model to quantitatively evaluate the effectiveness of various strategies. Based on the evaluation results, dynamically adjust system parameters and establish an anomaly detection mechanism. When an abnormal pattern is detected, trigger an early warning.

[0162] In practical implementation, within the data analysis dashboard of enterprise security equipment, users need to view multiple data charts simultaneously, each requiring data to be retrieved from the backend. (Refer to...) Figure 3 The intelligent aggregation, caching, and retry strategy management method for front-end API requests provided in this application is implemented as follows: 1. Batch Aggregation: The system identifies multiple chart data requests that have the same target API endpoint but different query parameters, and aggregates these requests into a single batch query request, significantly reducing the number of network round trips.

[0163] 2. Caching strategy: For dimension data that does not change frequently (such as device list, device status), set a longer cache expiration time; for metric data with high real-time requirements, set a shorter cache expiration time.

[0164] 3. Parameter Adaptation: The system monitors the response time and error rate of each data interface and dynamically adjusts the aggregation time window and retry parameters. For interfaces with slow responses, the aggregation time window is appropriately extended to reduce the request frequency; for unstable interfaces, a more conservative retry strategy is adopted.

[0165] Furthermore, in scrolling pages used for product display, such as shopping websites, the front-end page needs to continuously scroll and load new product data. In related technologies, a new API request is initiated every time the page is scrolled to the bottom, which may lead to request waterfall and performance bottlenecks. The intelligent aggregation, caching, and retry strategy management method for front-end API requests provided in this application is implemented as follows: 1. Intelligent Aggregation: When the system detects multiple requests with similar URI patterns and parameter structures, it groups them into the same batch processing group. The scheduler then sends requests to the backend in a unified manner.

[0166] 2. Cache optimization: Basic product information (such as name and price) is cached in memory, while product detail data is cached in persistent storage. When a user repeatedly browses the same product category, most data can be read directly from the cache without network requests.

[0167] 3. Retry Fault Tolerance: If a data request for a product fails, the system will retry using an exponential backoff strategy based on the current peak traffic, device memory status, and number of retries, further improving the user experience.

[0168] In this embodiment, the three major strategies of aggregation, caching, and direct connection are deeply integrated and managed through a unified execution method, enabling them to work collaboratively rather than operating in isolation, resulting in systemic optimization effects. All core decisions (whether to aggregate, how to cache, whether to retry) are made dynamically based on real-time context information (network conditions, device capabilities, user needs), rather than relying on static configuration. The front-end application can maintain high performance, high availability, and an excellent user experience in complex and ever-changing network environments and user interaction scenarios, while reducing the pressure on back-end services and improving the overall system's scalability and maintainability.

[0169] Based on the methods described in any of the above embodiments, this application also provides, as follows: Figure 4 The diagram shows the structure of an electronic device. Figure 4 At the hardware level, the electronic device includes a processor, an internal bus, a network interface, memory, and non-volatile memory, and may also include other hardware required for business operations. The processor reads the corresponding computer program from the non-volatile memory into memory and then runs it to implement the methods described in any of the above embodiments.

[0170] Based on the methods described in any of the above embodiments, this application also provides a computer storage medium storing a computer program, which, when executed by a processor, can be used to perform the methods described in any of the above embodiments.

[0171] Based on the methods described in any of the above embodiments, this application also provides a computer program product, which includes one or more computer programs or instructions. The computer program or instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. When executed by a processor, the computer program implements the methods described in any of the above embodiments.

[0172] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0173] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0174] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0175] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0176] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

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

Claims

1. A front-end interface request management method, characterized by, The method comprises: obtaining context features of an interface request initiated by a front-end application; the context features are used to represent real-time attributes, execution environment, and user intention of the interface request; based on the context features, classifying the interface request and determining processing strategies corresponding to different categories; according to the processing strategies, performing corresponding processing operations on the interface request, the processing operations including at least one of request aggregation operation, cache reading operation, or real-time forwarding operation.

2. The method of claim 1, wherein, The method comprises: extracting request initiation time stamp, request parameter set, and request header information of the interface request; based on the request initiation time stamp, the request parameter set, and the request header information, determining the context features.

3. The method of claim 1, wherein, The method comprises: based on at least one feature of request mode, criticality level, and response data characteristics of the interface request, classifying the interface request to obtain a classification result; the criticality level is used to represent the priority of the interface request determined based on user intention or business requirement; according to the classification result, determining the processing strategy applicable to the interface request.

4. The method of claim 1, wherein, The request aggregation operation is performed by the following steps: merging and scheduling a plurality of interface requests belonging to the same batch processing group to generate an aggregated request; configuring a time window; the time window is used to control the aggregation waiting time length of the interface request; when the time window expires, sending the aggregated request and distributing the received response data to the corresponding interface requests.

5. The method of claim 1, wherein, The cache reading operation is performed by the following steps: if the cache data corresponding to the interface request is hit, reading the response data from the cache and returning to the front-end application; if the cache data corresponding to the interface request is not hit, initiating a real-time request to obtain the response data and returning to the front-end application.

6. The method of claim 1, wherein, The real-time forwarding operation is performed by the following steps: sending the interface request; if a successful response is received, returning the successful response to the front-end application; if the request fails, classifying the failed request according to the error type and determining the corresponding retry strategy to initiate a retry request.

7. The method of claim 1, wherein, After performing the corresponding processing operation on the interface request according to the processing strategy, the method further comprises: obtaining performance indicators of the processing operation, the performance indicators including at least one of request delay, cache hit rate, aggregation efficiency, retry success rate, and error distribution; adjusting the processing strategy according to the performance indicators.

8. The method of claim 7, wherein, The method comprises: adjusting the upper limit of the number of concurrent requests according to the network connection type or network quality; and / or adjusting the time window length of request aggregation according to request delay or aggregation efficiency.

9. The method of claim 7, wherein, The method further comprises: inputting the performance indicators into a multi-dimensional evaluation model to obtain an evaluation result; if the evaluation result indicates that the strategy effect is lower than the expected threshold, adjusting the processing strategy.

10. An electronic device, comprising: The electronic device comprises: a processor; Memory used to store processor-executable instructions; Wherein, when the processor invokes the executable instructions, it implements the method according to any one of claims 1-9.

11. A computer readable storage medium, characterized in that, It stores computer instructions that, when executed by a processor, implement the steps of any of the methods described in claims 1-9.

12. A computer program product, characterised in that, The computer program product includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-9.

Images