Interface aggregation request method and device, equipment, storage medium and program product

Abstract

The invention discloses an interface aggregation request method and device, equipment, a storage medium and a program product. The method comprises the steps that an aggregation request sent by a client is received, the aggregation request comprises at least two interface identifiers selected by the client, and the interface identifiers are used for indicating interfaces needing to be called by a server; interface information corresponding to the interfaces indicated by the at least two interface identifiers is obtained from a global configuration table, the global configuration table is used for storing information of the interfaces accessed by the server side, and the interface information comprises calling modes of the interfaces; under the condition that the ith interface in the at least two interfaces meets a preset interface condition, the ith interface is called based on the interface information of the ith interface, the calling result of the ith interface is obtained, the preset interface condition is related to the historical calling condition of the ith interface, and i is a positive integer; and sending the calling result to the client, so that the calling flexibility for different interfaces in the aggregation request can be improved, and the response efficiency for the aggregation request can be improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to an interface aggregation request method, apparatus, device, storage medium, and program product. Background Art

[0002] In modern distributed systems, clients (such as mobile applications and web applications) often need to obtain data from multiple APIs on the server to complete complex business logic. To improve system performance and user experience, API aggregation technology has emerged. API aggregation combines requests from multiple APIs into a single request, reducing the number of interactions between the client and the server, thereby reducing network latency and improving overall system performance.

[0003] In related technologies, when a client needs to obtain results from multiple server interfaces, the server typically uses a method whereby it concurrently requests multiple interfaces. Specifically, after receiving a client's request, the server concurrently initiates requests to multiple backend interfaces, waits for these interfaces to return results, aggregates the results from the different interfaces, and ultimately returns them to the client through a unified interface. This aggregation method allows the client to interact with only one server interface, simplifying the client's logic and reducing the number of network requests.

[0004] However, since the above method sets a unified timeout period based on aggregated requests, it has low flexibility in addressing the differences in response time between different interfaces. Summary of the Invention

[0005] The embodiments of the present application provide an interface aggregation request method, apparatus, device, storage medium, and program product, which can improve the flexibility of calling different interfaces in the aggregation request and improve the efficiency of responding to the aggregation request. The technical solution is as follows.

[0006] In one aspect, a method for requesting an interface aggregation is provided, the method comprising:

[0007] Receive an aggregation request sent by a client, wherein the aggregation request includes at least two interface identifiers selected by the client, and the interface identifiers are used to indicate interfaces that the server needs to call;

[0008] Obtaining interface information corresponding to the interfaces respectively indicated by the at least two interface identifiers from a global configuration table, wherein the global configuration table is used to store information about the interfaces accessed by the server, the interface information including a calling method of the interface;

[0009] If an i-th interface among at least two interfaces meets a preset interface condition, calling the i-th interface based on the interface information of the i-th interface to obtain a calling result of the i-th interface, where the preset interface condition is related to a historical calling situation of the i-th interface, and i is a positive integer;

[0010] Send the call result to the client.

[0011] On the other hand, an interface aggregation request device is provided, the device comprising:

[0012] A receiving module, configured to receive an aggregation request sent by a client, wherein the aggregation request includes at least two interface identifiers selected by the client, and the interface identifiers are used to indicate interfaces that the server needs to call;

[0013] a processing module, configured to obtain, from a global configuration table, interface information corresponding to the interfaces respectively indicated by the at least two interface identifiers, wherein the global configuration table is used to store information about the interfaces accessed by the server, the interface information including a calling method of the interface;

[0014] The processing module is further configured to, when an i-th interface among the at least two interfaces meets a preset interface condition, call the i-th interface based on the interface information of the i-th interface to obtain a call result of the i-th interface, wherein the preset interface condition is related to a historical call status of the i-th interface, and i is a positive integer;

[0015] A sending module is used to send the call result to the client.

[0016] In some embodiments, the processing module is further configured to:

[0017] Obtain a timeout configuration table, where the timeout configuration is used to indicate delay thresholds corresponding to all interfaces, including interfaces accessed by the server;

[0018] Obtaining the delay threshold corresponding to the i-th interface from the timeout configuration table;

[0019] In a case where the calling delay of the i-th interface does not exceed the delay threshold, the i-th interface is called based on the interface information of the i-th interface to obtain the calling result of the i-th interface.

[0020] In some embodiments, the processing module is further configured to:

[0021] Traversing the full set of interfaces accessed by the server based on the global configuration table;

[0022] Calculate the weighted average delay of the j-th interface based on the call delay of calling the j-th interface in the full set of interfaces within a historical time period as the delay threshold corresponding to the j-th interface, where j is a positive integer;

[0023] The delay threshold corresponding to the j-th interface is written into the timeout configuration table.

[0024] In some embodiments, the processing module is further configured to:

[0025] If the i-th interface meets the preset interface condition, write the i-th interface into an aggregation queue, where the aggregation queue is used to indicate the interface to be called as indicated by the aggregation request;

[0026] The interface in the aggregation queue is called based on the interface information to obtain the calling result.

[0027] In some embodiments, the processing module is further configured to:

[0028] Obtaining interface evaluation data corresponding to the i-th interface, the interface evaluation data including at least one of the call delay, call failure rate, call timeout rate, and call data volume of the interface;

[0029] When the interface evaluation data of the i-th interface meets the preset interface condition, the i-th interface is written into the aggregation queue.

[0030] In some embodiments, the preset interface condition includes at least one of the following:

[0031] The call delay of the i-th interface does not exceed a delay threshold corresponding to the i-th interface, where the delay threshold is determined based on an average call duration of calls to the i-th interface in a historical time period;

[0032] The call failure rate of the i-th interface is less than a preset failure rate threshold;

[0033] The call timeout rate of the i-th interface is less than a preset timeout rate threshold;

[0034] The call data volume of the i-th interface does not exceed a data volume threshold corresponding to the i-th interface, and the data volume threshold is determined based on an average call data volume of the i-th interface in the historical time period.

[0035] In some embodiments, the processing module is further configured to:

[0036] Evaluating the interface priority of the i-th interface by using a pre-trained interface evaluation model, wherein the interface evaluation model is a machine learning model for evaluating the call priority of an interface based on an interface call scenario;

[0037] When the interface priority of the i-th interface reaches a preset priority range, it is determined that the i-th interface meets the preset interface condition, and the i-th interface is written into the aggregation queue.

[0038] In some embodiments, the processing module is further configured to:

[0039] Get the interface information corresponding to the newly added interface;

[0040] Writing the interface information corresponding to the newly added interface into the global configuration table;

[0041] A full interface identifier is synchronized to the client based on the global configuration table, where the full interface identifier is used to indicate to the client the full interface accessed by the server.

[0042] In some embodiments, the processing module is further configured to:

[0043] In response to a cold start of the client, synchronizing the full interface identifier to the client based on the global configuration table;

[0044] The updated global configuration table is obtained at preset time intervals, and the full interface identifier is synchronized to the client based on the updated global configuration table.

[0045] On the other hand, a computer device is provided, which includes a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set or an instruction set, and the at least one instruction, the at least one program, the code set or the instruction set is loaded and executed by the processor to implement the interface aggregation request method as described in any of the above-mentioned embodiments of the present application.

[0046] On the other hand, a computer-readable storage medium is provided, in which at least one instruction, at least one program, a code set or an instruction set is stored. The at least one instruction, the at least one program, the code set or the instruction set is loaded and executed by a processor to implement the interface aggregation request method as described in any of the above-mentioned embodiments of the present application.

[0047] In another aspect, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the interface aggregation request method described in any of the above embodiments.

[0048] The beneficial effects of the technical solutions provided in the embodiments of the present application include at least:

[0049] Through a mechanism that associates preset interface conditions with historical call situations, differentiated evaluation criteria are dynamically set for each interface. For example, differentiated timeout thresholds are dynamically set (such as shorter timeouts for high-frequency query interfaces and longer response times for complex calculation interfaces), breaking through the restriction of mandatory unified timeouts for all interfaces. This can improve the flexibility of handling differences in response times for different interfaces, avoid affecting the overall response to aggregated requests due to the fact that some interfaces have a long response time but do not actually time out, and thus improve the response efficiency to aggregated requests. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0051] Figure 1 is a schematic diagram of a computer system provided by an exemplary embodiment of the present application;

[0052] Figure 2 This is a flowchart of an interface aggregation request method provided by an exemplary embodiment of the present application;

[0053] Figure 3 This is a flowchart of an interface aggregation calling method based on dynamic timeout evaluation provided by an exemplary embodiment of the present application;

[0054] Figure 4 This is a flowchart of an interface aggregation calling method based on a screening mechanism provided by an exemplary embodiment of the present application;

[0055] Figure 5 is a flowchart of an interface synchronization method provided by an exemplary embodiment of the present application;

[0056] Figure 6 This is a structural diagram of an interface aggregation request system provided by an exemplary embodiment of the present application;

[0057] Figure 7 This is a structural block diagram of an interface aggregation request device provided by an exemplary embodiment of the present application;

[0058] Figure 8 It is a structural block diagram of a terminal provided by an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0059] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0060] It should be understood that although the terms first, second, etc. may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, a first parameter may also be referred to as a second parameter, and similarly, a second parameter may also be referred to as a first parameter without departing from the scope of this disclosure. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0061] In modern distributed systems, clients (such as mobile applications, web applications, etc.) often need to obtain data from multiple interfaces from the server to complete a complex business logic. In order to improve the performance of the system and the user experience, interface aggregation technology has emerged. Interface aggregation reduces the number of interactions between the client and the server by combining requests from multiple interfaces into one request, thereby reducing network latency and improving the overall performance of the system. In related technologies, when the client needs to obtain the return results of multiple interfaces on the server, the server usually uses a method of concurrently requesting multiple interfaces. Specifically, after receiving the client's request, the server will concurrently initiate requests to multiple back-end interfaces, wait for these interfaces to return results, and then aggregate the return results of different interfaces, and finally return them to the client through a unified interface. This aggregation method allows the client to interact with only one interface on the server, simplifies the client's logic, and also reduces the number of network requests. However, since the above method sets a unified timeout based on the aggregated request, it has low flexibility in responding to the differences in response time of different interfaces.

[0062] The interface aggregation request method provided in the embodiment of the present application dynamically sets differentiated evaluation criteria for each interface through a mechanism that associates preset interface conditions with historical call situations. For example, differentiated timeout thresholds are dynamically set (such as setting a shorter timeout for high-frequency query interfaces and allowing longer response times for complex calculation interfaces), breaking through the limitation of forcing a unified timeout for all interfaces. It can improve the flexibility of handling response time differences for different interfaces, avoid affecting the overall response to the aggregation request due to the fact that some interfaces have a long response time but do not actually time out, thereby improving the response efficiency to the aggregation request.

[0063] On the other hand, by associating preset interface conditions with historical call data, a health status pre-screening mechanism (based on historical call data) can be implemented to eliminate unstable interfaces before initiating actual calls, avoid invalid requests to interfaces with known faults, and reduce the waste of server-side threads and connection resources. Furthermore, by centrally managing interface metadata through a global configuration table, clients only need to pass the interface identifier rather than the complete call parameters, shifting the complexity of interface routing, protocol conversion, and other aspects to the server, simplifying client logic.

[0064] First, let's introduce the computer system of this application. Figure 1 , which shows a schematic diagram of a computer system provided by an exemplary embodiment of the present application, wherein the computer system includes: a terminal 10 and a server 20.

[0065] The terminal 10 and the server 20 are connected via a network. The terminal 10 can act as a client. When the client needs to obtain interface data through an interface, it can initiate an interface request to the server providing the interface service, requesting the server to call the corresponding interface. The server 20 can act as a corresponding server to provide the interface service.

[0066] In some embodiments, the client may request the server to obtain interface data in batches based on a single request by sending an aggregate request.

[0067] Schematically, the server receives an aggregation request sent by the client, which includes at least two interface identifiers selected by the client, and the interface identifier is used to indicate the interface that the server needs to call; the server obtains interface information corresponding to the interfaces respectively indicated by the at least two interface identifiers from the global configuration table, and the global configuration table is used to store information of the interfaces accessed by the service client, and the interface information includes the calling method of the interface; under the generalization that the i-th interface among at least two interfaces meets the preset interface conditions, the i-th interface is called based on the interface information of the i-th interface to obtain the calling result of the i-th interface, where the preset interface conditions are related to the historical calling situation of the i-th interface, and i is a positive integer; and the calling result is sent to the client.

[0068] The server maintains a global configuration table, and can synchronize the interface identifiers corresponding to all interfaces accessed by the server to the client based on the global configuration table, so that the client can initiate an aggregation request to the server by selecting the interface identifier.

[0069] The above-mentioned terminal is optional. The terminal can be a desktop computer, a laptop computer, a mobile phone, a tablet computer, an e-book reader, a Moving Picture Experts Group Audio Layer III (MP3) player, a Moving Picture Experts Group Audio Layer IV (MP4) player, a smart TV, a smart car, and other terminal devices in various forms. The embodiments of the present application are not limited to this.

[0070] It is worth noting that the above-mentioned servers can be independent physical servers, or they can be server clusters or distributed systems composed of multiple physical servers. They can also be cloud servers that provide basic cloud computing services such as cloud services, cloud security, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), as well as big data and artificial intelligence platforms.

[0071] Among them, cloud technology refers to a hosting technology that unifies hardware, software, network and other resources within a wide area network or local area network to achieve data calculation, storage, processing and sharing.

[0072] In some embodiments, the above-mentioned server can also be implemented as a node in a blockchain system.

[0073] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of relevant data must comply with the relevant laws, regulations, and standards of the relevant regions. For example, the operational data and account information involved in this application are obtained with full authorization.

[0074] To further explain, this application can display a prompt interface, pop-up window or output voice prompt information before collecting relevant user data (for example, account information, historical operation data and real-time operation data involved in this application) and during the process of collecting relevant user data. The prompt interface, pop-up window or voice prompt information is used to remind the user that its relevant data is currently being collected, so that this application only starts to execute the relevant steps of obtaining user-related data after obtaining the user's confirmation operation on the prompt interface or pop-up window. Otherwise (that is, when the user's confirmation operation on the prompt interface or pop-up window is not obtained), the relevant steps of obtaining user-related data are terminated, that is, the user's relevant data is not obtained. In other words, all user data collected by this application are collected with the user's consent and authorization, and the collection, use and processing of relevant user data need to comply with the relevant laws, regulations and standards of the relevant region.

[0075] For illustration, please refer to Figure 2 , which shows a flowchart of an interface aggregation request method provided by an exemplary embodiment of the present application. The method can be executed by a terminal, a server, or both. The embodiment of the present application takes the method executed by the server as an example for explanation. Figure 2 As shown, the method includes the following steps:

[0076] Step 210: Receive an aggregation request sent by the client.

[0077] The aggregation request includes at least two interface identifiers selected by the client, and the interface identifiers are used to indicate the interfaces that the server needs to call.

[0078] An aggregate request is a composite request in which the client requests the server to obtain data from at least two interfaces simultaneously through a single network call.

[0079] Schematically, a client can construct a structured request message that explicitly lists the set of interface identifiers to be called and includes the necessary parameter information. This request can be transmitted via the HTTP / 2 protocol, leveraging its multiplexing capabilities for efficient transmission. When the server receives the aggregated request, it can first distribute it through a load balancing node, then verify identity and permissions through the authentication middleware, and finally enter the request parsing phase to verify the request format and extract key elements.

[0080] It is worth noting that the above-mentioned method of sending and receiving aggregation requests is only an example and is not limited to this embodiment of the present application.

[0081] The interface identifier is a unique name for each access interface on the server.

[0082] Instructively, a three-part naming convention of "business domain_function_version" can be adopted. For example, for user-related core businesses, such as user management and user information storage, the business domain is named "user", and the function template for functions such as user profile or information management is named "profile". For different version interfaces of corresponding functions in the business domain, version numbers are named, such as "v2", indicating the second iterative version of the function. The interface identifier "user_profile_v2" can indicate the second version interface of user profile management in the user business field.

[0083] It is worth noting that the above interface identification method is only an illustrative example and is not limited to this embodiment of the present application.

[0084] In some embodiments, when the client selects an interface identifier to send an aggregation request, the interface identifier may be selected based on a static configuration or a dynamic rule.

[0085] Taking the statically configured interface identifier as an example, a basic interface set can be preset according to the client type (such as iOS / Android). When the client needs to obtain interface data based on the first function, the interface identifier pre-bound to the first function is automatically selected to generate an aggregate request. That is, when the same function is triggered for the same type of client, at least two interface identifiers in the aggregate request sent by the client are clearly fixed.

[0086] Schematically, a predefined rule mapping table is used to bind client types to a set of basic interfaces, ensuring that similar clients always request the same interface combination in the same business scenario. For example, for the application scenario of loading the homepage of an e-commerce application, the static rule indicates: iOS clients must request the interfaces ["user_profile", "banner_ios", "goods_list"], and Android clients must request the interfaces ["user_profile", "banner_android", "goods_list"]. This ensures that interface elements match platform characteristics (for example, iOS uses a dedicated banner style) and reduces client logic branch judgment.

[0087] Taking the selection of interface identifiers based on dynamic rules as an example, interfaces can be added or deleted in real time based on user characteristics (such as VIP level) or environmental parameters (such as network quality) to achieve personalized data aggregation.

[0088] In an illustrative manner, for the recommendation scenario on the homepage of the video platform, for users whose user status belongs to "new user + WiFi network", an interface for obtaining popular content in real time based on trends is used for recommendation; for users whose user status belongs to "old VIP user + 4G network", an interface for recommending personalized content based on offline cache is used; for users whose user status belongs to "low-end device + weak network", an interface for returning only text summary recommended content is used.

[0089] In some embodiments, a hybrid mode combining static and dynamic can also be adopted. Static configuration is used in the basic layer to ensure core functions, so that all clients must request preset basic interfaces. Dynamic rules are used in the enhanced layer to achieve optimization, and corresponding optional interfaces are superimposed according to real-time conditions.

[0090] The selection process takes interface dependencies into consideration to ensure that required interfaces are included first, and optional interfaces can be dynamically adjusted based on business scenarios.

[0091] By using the hybrid mode, fault isolation can be achieved without affecting basic functions in the event of dynamic interface anomalies. When adding new business dimensions, only the rule engine needs to be updated, and the aggregation request method can be flexibly expanded. Basic data can be loaded quickly, and enhanced content can be presented progressively to achieve a smooth user experience.

[0092] It is worth noting that the above interface selection methods and scenarios are only illustrative examples and are not limited to the embodiments of the present application.

[0093] In some embodiments, the client stores an interface identifier synchronized by the server to the client. By synchronizing the interface identifier from the server to the client, the client can clearly request the server to call the interface, so that the client can send a personalized aggregation request to the server by selecting the interface identifier.

[0094] Step 220: Obtain interface information corresponding to the interfaces indicated by at least two interface identifiers from the global configuration table.

[0095] The global configuration table contains information about the interface used to store client access. The interface information includes the interface calling method.

[0096] The global configuration table is the core database that maintains metadata for all interfaces and can be implemented using distributed key-value storage.

[0097] Optionally, each interface information includes but is not limited to at least one of the network positioning information, service quality parameters, security control elements, and traffic management policies of the interface.

[0098] Network location information includes endpoint Uniform Resource Locator (URL) and request method, among which the endpoint URL refers to the complete network address of the interface, which may include protocol type, domain name IP, path and optional port, etc. The request method includes Get method, Post method, etc.

[0099] Quality of Service parameters include timeouts and retry policies. The timeout is the latency threshold for calling an interface. If the latency reaches this threshold, the request times out. The retry policy indicates whether to retry calling the interface if a request times out.

[0100] Security control elements include authentication methods and parameter signature rules. Authentication methods refer to security mechanisms that verify the legitimacy of the requester's identity, ensuring that only authorized clients can access the interface. Parameter signature rules refer to anti-tampering mechanisms that ensure that the request is not modified during transmission.

[0101] Traffic management strategies include circuit breaker thresholds and current limiting configurations. Circuit breaker thresholds refer to the failure judgment criteria that trigger service circuit breaking to prevent cascading failures; current limiting configurations control the number of requests per unit time to protect the system from overload.

[0102] Illustratively, the interface information at least includes information such as the interface name, interface domain name, interface address, and interface URL, which are used to indicate the interface calling method.

[0103] In some embodiments, the server can write the newly added interfaces that need to be aggregated into the global configuration table through global configuration, and maintain interface information such as the interface name (interface identifier), interface domain name, interface address, interface URL, etc. Upon receiving an aggregation request sent by a client, the server searches the global configuration table for the information of the interface indicated by the aggregation request based on the mapping relationship between the interface identifier and the interface information, and calls the corresponding interface according to the calling method indicated by the interface information.

[0104] Step 230: When the i-th interface among the at least two interfaces meets the preset interface condition, the i-th interface is called based on the interface information of the i-th interface to obtain a calling result of the i-th interface.

[0105] The preset interface condition is related to the historical call status of the i-th interface, where i is a positive integer.

[0106] The preset interface conditions are used to implement the interface screening mechanism, screening interfaces that meet the requirements for aggregate calls, and preventing some interfaces from affecting the overall response efficiency of the aggregated requests.

[0107] In some embodiments, the preset interface condition is based on a multi-dimensional dynamic health assessment system. Optionally, the assessment indicators include but are not limited to at least one of a timeliness indicator, a reliability indicator, and a capacity indicator.

[0108] Taking the evaluation indicators including timeliness indicators as an example, the preset interface conditions are related to the historical call delay of the i-th interface.

[0109] In principle, the timeliness index includes the average call delay of calling the i-th interface within a historical time period. When the timeliness index of the i-th interface meets the timeliness requirements (for example, the average call delay does not exceed the preset delay threshold, which is personalized for the i-th interface), it is determined that the i-th interface meets the preset interface conditions and is called.

[0110] Taking the evaluation indicators including reliability indicators as an example, the preset interface condition is related to the historical call failure rate (or success rate) of the i-th interface.

[0111] Schematically, the reliability index includes the historical call failure rate of calling the i-th interface within a historical time period. When the reliability index of the i-th interface meets the reliability requirements (such as the historical call failure rate does not exceed the preset failure rate threshold, which is personalized for the i-th interface), it is determined that the i-th interface meets the preset interface conditions and is called.

[0112] Taking the evaluation indicators including capacity indicators as an example, the preset interface condition is related to the historical call data volume of the i-th interface.

[0113] Schematically, the capacity indicator includes the unit data call volume of the i-th interface during the historical time period. When the capacity indicator of the i-th interface meets the capacity requirements (such as the unit data call volume does not exceed the preset data volume threshold, which is personalized for the i-th interface), it is determined that the i-th interface meets the preset interface conditions and is called.

[0114] The evaluation system continuously tracks interface status and automatically triggers downgrade decisions when it detects abnormal indicators. Different thresholds are applied to different interface types, with more relaxed criteria for core interfaces to ensure availability.

[0115] In some embodiments, the historical call status of the i-th interface can be compared with the call evaluation parameters personalized for the i-th interface to evaluate the interface that meets the preset interface conditions, and dynamic evaluation can be achieved by dynamically updating the historical call status according to the time window; the current call status of the i-th interface can also be compared with the historical call status of the i-th interface to evaluate the interface that meets the preset interface conditions, and dynamic evaluation can be achieved by dynamically updating the historical call status as the call evaluation parameter according to the time window.

[0116] In some embodiments, a dynamic double comparison strategy can be adopted to determine whether the i-th interface meets the preset interface conditions. Taking the preset interface conditions related to the call delay of the i-th interface as an example, the first layer adopts the historical delay benchmark check to compare the current real-time call delay of the i-th interface with the historical weighted average delay (EMA) of the interface, and the judgment conditions include the current real-time call delay ≤ historical weighted average delay; the second layer adopts the static threshold bottom-up check to compare the current real-time call delay of the i-th interface with the maximum tolerable delay threshold of the interface, and the judgment conditions include the current real-time call delay ≤ maximum tolerable delay threshold.

[0117] It is worth noting that the above interface evaluation method is only an illustrative example and is not limited to this embodiment of the present application.

[0118] Step 240: Send the call result to the client.

[0119] In some embodiments, after the server completes the interface call, it performs standardized processing on the returned results.

[0120] Optionally, the standardization process includes but is not limited to data cleaning, intelligent compression, incremental assembly, etc.

[0121] Among them, data cleaning is used to filter sensitive fields and unify the error code format, intelligent compression is used to select the optimal compression algorithm according to content characteristics (Brotli for text and LZ4 for binary), and incremental assembly is used to gradually build the response body using streaming processing technology.

[0122] The final call result is sent gradually through block transfer encoding, and the client can render while receiving.

[0123] The call results may include analysis of the reasons for the excluded interface, recommended retry time and other auxiliary information. Among them, abnormal situations can be returned through a dedicated error channel and transmitted separately from normal business data.

[0124] To sum up, the method provided in the embodiment of the present application dynamically sets differentiated evaluation criteria for each interface through a mechanism that associates preset interface conditions with historical call situations. For example, differentiated timeout thresholds are dynamically set (such as setting a shorter timeout for high-frequency query interfaces and allowing longer response times for complex calculation interfaces), breaking through the restriction of forcing a unified timeout for all interfaces. It can improve the flexibility of handling response time differences for different interfaces, avoid the overall response to aggregated requests being affected by the fact that some interfaces have a long response time but do not actually time out, thereby improving the response efficiency to aggregated requests.

[0125] In some embodiments, the interface aggregation request method provided in the embodiment of the present application provides a dynamic timeout algorithm that can dynamically evaluate the timeout of the interface for different interfaces. Figure 3 , Figure 3 This is a flowchart of an interface aggregation calling method based on dynamic timeout evaluation provided by an exemplary embodiment of the present application. The method can be executed by a terminal, a server, or both. The embodiment of the present application takes the method executed by the server as an example for explanation. Figure 3 As shown, the above step 230 includes the following steps:

[0126] Step 231: Obtain a timeout configuration table.

[0127] The timeout configuration table is used to indicate the delay thresholds corresponding to all interfaces, including the interfaces accessed by the server.

[0128] The delay threshold corresponding to all interfaces can be a fixed delay threshold configured for the interface, or a dynamic delay threshold determined based on the historical call delay of the interface.

[0129] This embodiment of the application takes as an example a dynamic delay threshold value determined based on the historical interface call delay as the delay threshold in the timeout configuration identifier. The acquisition process of the timeout configuration table may include the following steps:

[0130] The first step is to traverse all interfaces accessed by the server based on the global configuration table.

[0131] For all interfaces, the call latency of each interface is recorded each time it is called during the historical time period.

[0132] In the second step, based on the call latency of the jth interface in all interfaces during the historical time period, the weighted average latency of the jth interface is calculated as the latency threshold corresponding to the jth interface, where j is a positive integer.

[0133] Indicatively, for each interface, an exponential moving average (EMA) dynamic timeout algorithm is used in the remote procedure call (RPC) request, and a weighted moving average timeout is used instead of a fixed timeout to dynamically evaluate the interface call timeout.

[0134] The third step is to write the delay threshold corresponding to the jth interface into the timeout configuration table.

[0135] Indicatively, the interface identifier of the jth interface and the delay threshold corresponding to the jth interface are associated and written into the timeout configuration table, so that the delay threshold of the corresponding interface can be queried through the interface identifier.

[0136] By calculating the weighted average delay based on the call delay of the interface call in the historical time period as the delay threshold corresponding to the interface, a dynamic delay evaluation mechanism can be implemented to ensure that the interface can be successfully called as much as possible, and will not be mistakenly judged as a timed-out call based on a fixed delay threshold, thereby improving the efficiency of interface calls.

[0137] Step 232: Obtain the delay threshold corresponding to the i-th interface from the timeout configuration table.

[0138] Illustratively, the corresponding delay threshold is queried from the timeout configuration table based on the interface identifier of the i-th interface.

[0139] In some embodiments, if the i-th interface has not been called based on an aggregate request within a historical time period, the server may simulate calling the i-th interface in advance to test and obtain the historical call delay as the delay threshold of the i-th interface.

[0140] Step 233: When the calling delay of the i-th interface does not exceed the delay threshold, the i-th interface is called based on the interface information of the i-th interface to obtain the calling result of the i-th interface.

[0141] In some embodiments, when the call delay of the i-th interface exceeds the delay threshold, the call to the i-th interface can be canceled, or an independent attempt can be made to call the i-th interface. During the request attempt, the call results of other interfaces in the aggregated request do not need to wait for the call results of the i-th interface. If the i-th interface is successfully called, the aggregated results of the i-th interface can be returned to the client independently.

[0142] To sum up, the method provided in the embodiment of the present application records the delay threshold corresponding to each interface through a timeout configuration table. When the call delay of the i-th interface does not exceed the delay threshold, the i-th interface is called based on the aggregation request. This can avoid waiting for the interface with too long call delay based on the aggregation request, which affects the overall response efficiency of the aggregation request. It can also reduce invalid calls and improve the efficiency of interface calls based on aggregation requests when there is a high probability that some interfaces will timeout.

[0143] In some embodiments, the interface aggregation request method provided in the embodiment of the present application also provides a multi-dimensional health interface evaluation mechanism, which can evaluate the interface based on multiple dimensions, initiate calls for healthy interfaces, and reduce invalid calls. Figure 4 , Figure 4 This is a flowchart of an interface aggregation calling method based on a screening mechanism provided by an exemplary embodiment of the present application. The method can be executed by a terminal, a server, or both. The embodiment of the present application takes the method executed by the server as an example for explanation. Figure 4 As shown, the above step 230 includes the following steps:

[0144] Step 410: When the i-th interface meets the preset interface condition, write the i-th interface into the aggregation queue.

[0145] The aggregation queue is used to indicate the interface to be called as indicated by the aggregation request.

[0146] The aggregation queue can be used to indicate the interface that needs to feedback the call results based on the aggregate request as a whole.

[0147] By writing the i-th interface into the aggregation queue when the i-th interface meets the preset interface conditions, it is possible to perform interface aggregation calls when the i-th interface is evaluated as a healthy interface based on the preset interface conditions, thereby avoiding the impact of unhealthy interfaces on the overall response efficiency of aggregation requests.

[0148] In some embodiments, whether the interface meets the preset interface conditions can be evaluated based on multi-dimensional interface evaluation data.

[0149] The evaluation process based on multi-dimensional interface evaluation data includes the following two steps:

[0150] The first step is to obtain the interface evaluation data corresponding to the i-th interface.

[0151] The interface evaluation data includes at least one of the interface call delay, call failure rate, call timeout rate, and call data volume.

[0152] The call delay refers to the time required to call the interface to obtain relevant data. The call failure rate refers to the failure probability of calling the interface a unit number of times within the preset time period. The call timeout rate refers to the timeout probability of calling the interface a unit number of times within the preset time period. The call data volume refers to the amount of data required to call the interface.

[0153] In some embodiments, the server maintains an interface evaluation table, which is used to store interface evaluation data corresponding to each interface. The corresponding interface evaluation data can be obtained by querying the interface identifier from the interface evaluation table.

[0154] It is worth noting that the above-mentioned interface evaluation data and acquisition methods are merely illustrative examples and are not limited to these in the embodiments of the present application.

[0155] In the second step, if the interface evaluation data of the i-th interface meets the preset interface conditions, the i-th interface is written into the aggregation queue.

[0156] Optionally, the preset interface condition includes at least one of the following:

[0157] The call delay of the i-th interface does not exceed the delay threshold corresponding to the i-th interface. The delay threshold is determined based on the average call duration of the i-th interface in the historical time period.

[0158] The call failure rate of the i-th interface is less than the preset failure rate threshold;

[0159] The call timeout rate of the i-th interface is less than the preset timeout rate threshold;

[0160] The call data volume of the i-th interface does not exceed the data volume threshold corresponding to the i-th interface. The data volume threshold is determined based on the average call data volume of the i-th interface in a historical time period.

[0161] In some embodiments, at least two interfaces may be written into the aggregation queue based on the aggregation request, and if the i-th interface does not meet the preset interface condition, the i-th interface may be removed from the aggregation queue.

[0162] Optionally, the interface elimination process includes at least one of the following situations:

[0163] When the call delay of the i-th interface exceeds the delay threshold corresponding to the i-th interface, the i-th interface is removed from the aggregation queue; or,

[0164] When the call failure rate of the i-th interface reaches the preset failure rate threshold, the i-th interface is removed from the aggregation queue; or,

[0165] When the call timeout rate of the i-th interface reaches the preset timeout rate threshold, the i-th interface is removed from the aggregation queue; or,

[0166] When the call data volume of the i-th interface exceeds the data volume threshold corresponding to the i-th interface, the i-th interface is removed from the aggregation queue.

[0167] It is worth noting that the above interface screening method is only an illustrative example and is not limited to this embodiment of the present application.

[0168] By obtaining multi-dimensional interface evaluation data, it is possible to evaluate the interface call situation from multiple dimensions, ensure the efficiency of interface calls based on aggregated requests as much as possible, and improve the overall response efficiency to aggregated requests.

[0169] Step 420: Call the interface in the aggregation queue based on the interface information to obtain a call result.

[0170] In some embodiments, for the interfaces in the aggregated queue, the call results can be sent to the client separately after obtaining them, or they can be aggregated as a whole and sent to the client. This embodiment of the present application does not limit this.

[0171] In some embodiments, the interfaces of the aggregated requests may also be filtered based on interface priority (related to business value, resource consumption, etc.).

[0172] For example, even if some interfaces occasionally time out, they are highly business-critical (such as payment risk control) and should not be easily eliminated.

[0173] In some embodiments, the interface priority of the i-th interface is evaluated by a pre-trained interface evaluation model, which is a machine learning model used to evaluate the call priority of the interface based on the interface call scenario; when the interface priority of the i-th interface reaches a preset priority range, it is determined that the i-th interface meets the preset interface conditions, and the i-th interface is written into the aggregation queue.

[0174] Optionally, the following evaluation data of the interface can be collected as input data for the interface evaluation model: business priority (such as payment interface weight > recommended interface), historical success rate, average response time, current server load (memory, network status), client device type (mobile / PC, network environment), etc.

[0175] In some embodiments, evaluation data of interfaces within a historical time period can be obtained as training data, and the priorities of at least two interfaces in the aggregated requests within the historical time period can be manually labeled as reference labels. An interface evaluation model can be obtained based on the training data and reference labels.

[0176] The server can dynamically adjust the aggregation weight of interfaces based on the interface priority output by the model. For example, even if the timeout rate of a high-priority interface is slightly higher, it will remain in the aggregation queue, but the timeout period will be extended. Low-priority interfaces will be quickly removed to avoid affecting the core link.

[0177] Through the intelligent evaluation method of the above interface priority, the system can adapt to business needs rather than just technical indicators (such as timeout rate), and can be suitable for complex business scenarios, such as guaranteeing payment interfaces during promotions and downgrading recommendation interfaces.

[0178] Correspondingly, the client can also implement adaptive degradation processing for aggregated requests.

[0179] In principle, when the network is poor, the client automatically skips non-core interfaces, such as advertisements, and only requests key data. Alternatively, when the device performance is low, the client automatically reduces the data accuracy, such as returning thumbnails instead of original images. When the corresponding interface is unavailable, the client automatically returns locally cached data, such as yesterday's popular product list.

[0180] It is worth noting that the above-mentioned adaptive degradation processing method of the client is only an illustrative example and is not limited to this embodiment of the present application.

[0181] Through the above method, the client has the ability to intelligently downgrade, which can reduce dependence on the server and improve the user experience in a weak network environment.

[0182] To sum up, the method provided in the embodiment of the present application writes the interface into the aggregation queue when the interface meets the preset interface conditions, calls the interface in the aggregation queue based on the interface information, and obtains the call result, thereby realizing an interface screening mechanism based on the aggregation queue and preset interface conditions, and can perform aggregation calls on interfaces that meet the preset interface conditions, thereby improving the overall response efficiency to aggregation requests.

[0183] In some embodiments, before the client sends an aggregation request by selecting an interface identifier, the server needs to synchronize the client's selectable interface identifiers with the client. Figure 5 , Figure 5 This is a flowchart of an interface synchronization method provided by an exemplary embodiment of the present application. The method can be executed by a terminal, a server, or both. The embodiment of the present application takes the method executed by the server as an example for explanation. Figure 5 As shown, the method includes the following steps:

[0184] Step 510: Synchronize all interface identifiers to the client based on the global configuration table.

[0185] The full interface identifier is used to indicate to the client the full interface accessed by the server.

[0186] The core design goals of the synchronization mechanism include interface discoverability: enabling the client to dynamically perceive all available interfaces on the server; refined permission control: differentiating open interfaces based on client attributes; and real-time guarantee: ensuring that changes to interfaces take effect promptly.

[0187] In some embodiments, by synchronizing the full set of interface identifiers to the client, the interface selection authority can be fully opened to the client, so that the client can fully construct a personalized aggregation request based on the full set of interface identifiers.

[0188] In some embodiments, different interface identifiers may also be synchronized to the client based on the client's calling authority.

[0189] The interface synchronization process based on calling permissions includes obtaining the client identifier of the client, which is used to uniquely identify the client; based on the client identifier, filtering at least one interface that the client has calling permissions for from the global configuration table, where the calling permissions are related to at least one of the client's client type, client level, and client's historical calling status; and synchronizing the interface identifier of the above at least one interface to the client.

[0190] For example, the following table 1 shows how to grant different interface call permissions to ordinary users and member users.

[0191] Table 1 Calling permission comparison table

[0192] Interface properties Ordinary users Member User Basic data interface allow allow Advanced Analysis Interface prohibit allow Historical data export 10 times / day No restrictions

[0193] When synchronizing the interface identifier to the client, the interface identifier of the basic data interface can be synchronized for the client corresponding to ordinary users, and the interface identifiers of the basic data interface and the advanced analysis interface can be synchronized for member users.

[0194] By synchronizing different interface identifiers to the client based on calling permissions, it is possible to ensure that the interface identifiers that the client can select are all interfaces that the client has calling permissions for. This can simplify the interface screening logic of the client and server when processing aggregation requests, thereby improving the efficiency of aggregation requests.

[0195] In some embodiments, the process of synchronizing the full interface identifier from the server to the client includes: synchronizing the full interface identifier to the client based on the global configuration table in response to a cold start of the client; obtaining the updated global configuration table at preset time intervals, and synchronizing the full interface identifier to the client based on the updated global configuration table.

[0196] Optionally, the preset time interval may be related to the frequency of adding / deleting interfaces in the server, or to the network conditions of the client, etc., which is not limited in the embodiments of the present application.

[0197] A client cold start refers to the first time a client is started within a historical period, or when a version is updated.

[0198] When the client is cold started, the full interface identifier is synchronized to the client based on the global configuration table. For clients that have already synchronized the full interface identifier, when synchronizing the full interface identifier to the client at a preset time interval, only the interface identifiers that have changed can be synchronized, such as new interface identifiers or offline interface identifiers, etc., to reduce the amount of data sent and received during the synchronization process and save network transmission resources; the full interface identifier can also be directly synchronized to overwrite the original full interface identifier in the client, while ensuring the accuracy of the interface identifier recorded in the client, simplifying the interface synchronization logic of the server and client.

[0199] Optionally, the server may automatically synchronize the full interface identifier to the client at a preset time interval, or the client may poll the server at a preset time interval to obtain the full interface identifier. This embodiment of the present application is not limited to this.

[0200] The server automatically synchronizes the full interface identifier to the client at preset time intervals, and can synchronize the updated information to the client in a timely manner based on the interface update status in the server; the client actively polls to obtain the full interface identifier, and can obtain the full interface identifier based on the actual needs of the client, thereby reducing the amount of invalid data sent and received.

[0201] In some embodiments, the interface synchronization mode can be determined according to the network conditions of the client. When the client is in a WiFi network, the server automatically synchronizes the interface identifier to the client. When the client is in a traffic network state, the client actively polls for the synchronization interface identifier.

[0202] In some embodiments, the server may change information of the interface to which the server is connected by changing a global configuration table.

[0203] The update process for the newly added interface includes: obtaining interface information corresponding to the newly added interface; writing the interface information corresponding to the newly added interface into the global configuration table to obtain an updated global configuration table.

[0204] In principle, for a newly added interface, the operation and maintenance personnel can submit the interface description through the configuration center. The configuration center will call the service network, generate routing rules, submit them to the monitoring system to check the registration health of the interface, and return the health status to the configuration center. The configuration center will include the newly added interface when it synchronizes with the client next time.

[0205] In some embodiments, the interface version can be updated in the global configuration table. Optionally, when synchronizing the interface identifier to the client, the latest version can be synchronized to the client by default. The client can also specify to call the historical version. This embodiment of the present application does not limit this.

[0206] In some embodiments, a progressive processing method may be used to process the interface offline.

[0207] Indicatively, the interface to be taken offline is marked as "still callable but with warning", and after 3 days the interface is changed to "not callable", and after 7 days the interface is removed from the global configuration table.

[0208] By writing the interface information corresponding to the newly added interface into the global configuration table, or removing the interface from the global configuration table to take the interface offline, the interface update management function based on the global configuration table can be implemented, simplifying the interface management logic. There is no need to modify the aggregation request processing logic for the newly added or offline interface. It is only necessary to update the synchronization interface identifier to the client based on the global configuration table, thereby improving the interface configuration efficiency.

[0209] To sum up, the method provided in the embodiment of the present application, by synchronizing the full set of interfaces accessed to the client based on the global configuration table, enables the client to send a personalized aggregation request to the server by selecting an interface identifier, so that the server can call the corresponding interface in a targeted manner based on the personalized aggregation request. It does not require modifying the code logic based on the client adding or deleting the interface identifier in the aggregation request, nor does it require returning the full set of interface call results to the client based on the aggregation request. It can support the client to freely select the interface that needs to be aggregated by the server, thereby improving the flexibility and stability of the interface aggregation request as a whole.

[0210] For illustration, please refer to Figure 6 , Figure 6 This is a structural diagram of an interface aggregation request system provided by an exemplary embodiment of the present application. Figure 6 As shown, the interface aggregation request system 600 includes a client 610 and a server 620. The client 610 includes a to-be-aggregated interface selection module 601, and the server 620 includes an aggregation interface registration module 602, a configuration center module 603, an aggregation layer module 604, and an RPC timeout configuration module 605.

[0211] The aggregation interface registration module 602 is used to write the newly added interfaces that need to be aggregated into the configuration table through global configuration, and maintain information such as the interface name, interface domain name, interface address, interface URL, etc. When a client initiates a request to aggregate a specified interface, it finds the necessary information of the requested interface through the mapping relationship of the interface name and then makes the interface request.

[0212] The configuration center module 603 is used to provide global configuration functions, mainly including three functions: interface information configuration module, aggregation evaluation module, and aggregation interface synchronization module.

[0213] The interface information configuration module is used to configure and maintain the interface information of the server-side aggregation request, including: interface name, interface domain name, interface address, interface URL and other information. When a new interface that needs to be aggregated is added, only the corresponding information needs to be added to register the interface. The configuration and service are decoupled, which greatly improves the access efficiency.

[0214] Configure the EMA dynamic timeout parameters for the aggregation request interface, including RPC_ReadTimeout, RPC_Next_Upstream_Timeout, and other information.

[0215] The aggregation assessment module is mainly responsible for collecting information such as latency, failure rate (including the number of 499, 5xx, etc.), timeout rate, and request body size of each interface when the aggregation service requests are made to each upstream backend interface. Based on the above interface-related information, it is used to evaluate whether the interface needs to make an aggregation request. If the failure rate, latency, or timeout rate is too high, it will be removed from the queue of interfaces that can aggregate requests.

[0216] The aggregation interface synchronization module mainly maintains an upstream backend interface queue that can aggregate requests on the server side. It is divided into two synchronization modes: cold start and real-time acquisition. When the client is cold started, the interfaces that can aggregate requests are combined into the aggregation queue and then delivered to the client locally. Subsequently, new queue results are pulled at fixed intervals and overwrite the local client data.

[0217] The aggregation layer module 604 is the external interface module of the server, responsible for processing requests initiated by the client, receiving and parsing the background interface that the client needs to request, and compressing the data returned by each background interface before returning it to the client.

[0218] The RPC timeout configuration module 605 obtains the RPC timeout time of different interfaces that need to aggregate requests from the globally configured EMA dynamic timeout configuration parameter information, thereby flexibly implementing personalized RPC timeout configuration for different interfaces and decoupling different interfaces to improve the stability and success rate of the overall aggregation service.

[0219] The EMA dynamic timeout algorithm is a dynamic timeout algorithm for RPC requests. It uses a weighted moving average timeout instead of a fixed timeout. This can maximize the success rate of requests to the upstream interface when the upstream interface fluctuates, thereby improving the stability of the aggregate interface.

[0220] The interface selection module 601 to be aggregated is used to maintain the module name information of different versions that need to be aggregated by the server on the client. When making a request, you only need to select the interface that needs to correspond to the server request and pass in the interface name. The server will obtain the necessary information related to the request of the corresponding interface from the configuration information based on the interface name.

[0221] By logically connecting the above five modules, the client can flexibly select the interfaces that need to be aggregated by the server. The server can flexibly register the interfaces to be aggregated through global configuration. The aggregate interface evaluation and synchronization module can realize the real-time addition and kicking of aggregate interfaces, and provide independent RPC timeout configuration for different interfaces, thereby improving the overall stability of the service.

[0222] During the interaction between the client and the server, the client may need to obtain the return results of multiple APIs on the server at the same time. For example, an e-commerce client may need to obtain data from multiple APIs at the same time, such as product details, inventory information, and user reviews.

[0223] In some embodiments, a request is sent from the client to the server. After receiving the request, the server concurrently initiates requests to multiple internal interfaces. After waiting for these internal interfaces to return results, the server aggregates these results and returns the aggregated results to the client through a unified interface.

[0224] This approach allows the client to interact with only one interface on the server, rather than multiple internal interfaces.

[0225] However, when the client adds a new API request, the server needs to implement code-level compatibility. For example, if the client adds a new API request to obtain logistics information, the server needs to modify the code logic, add the new API to the list of concurrent requests, and adjust the logic for aggregating results.

[0226] The above-mentioned request aggregation method cannot customize timeouts for different interfaces. For example, some interfaces may have large data volumes and require longer processing times, while others may have smaller data volumes and require shorter processing times. Since only a single timeout can be set, some interfaces may not return results properly due to improper timeout settings.

[0227] The method provided in the embodiment of the present application can perform customized timeout processing for different interfaces without changing the code logic, thereby improving the overall response efficiency to aggregate requests.

[0228] On the other hand, the client cannot specify which interface modules the server should aggregate requests for. For example, a client may only need to obtain product details and inventory information, but in some embodiments, the server will aggregate data from all interfaces and return it to the client. The client must filter out the required data from the large amount of data, which increases the client's processing burden.

[0229] The number of aggregated interfaces and interfaces is entirely handled by the server. The server may aggregate certain interfaces based on its own logic without considering the actual needs of the client, resulting in the data obtained by the client being suboptimal.

[0230] With the method provided in the embodiment of the present application, the client can independently select the interface that needs to be called by the server based on the interface identifier to form a personalized aggregation request. The server can call the corresponding interface according to the interface identifier indicated by the aggregation request based on the global configuration table without modifying the code logic or making a full call. This can reduce unnecessary calls and improve the efficiency and flexibility of interface aggregation calls.

[0231] Furthermore, the server and client cannot evaluate the need for request aggregation based on factors such as traffic volume, failure rate, and timeout rate. For example, if an interface has very high traffic volume but low failure and timeout rates, request aggregation may not be necessary. However, if an interface has high failure and timeout rates, request aggregation may be necessary to optimize performance. In some embodiments, it is not possible to determine whether aggregation is necessary based on these dynamic factors.

[0232] There is no mechanism to dynamically add or remove interfaces from the aggregation request based on the interface request status. For example, if the performance of an interface suddenly deteriorates, it cannot be automatically removed from the aggregation request. Or, when a new interface with good performance is added, it cannot be automatically added to the aggregation request.

[0233] The method provided in the embodiment of the present application, through multi-dimensional interface evaluation, dynamically adds and removes interfaces to be aggregated, which can ensure the efficiency of interface calls based on aggregation requests, avoid invalid calls to unhealthy interfaces, and affect the overall response efficiency of aggregation requests.

[0234] Figure 7 This is a structural block diagram of an interface aggregation request device provided by an exemplary embodiment of the present application. Figure 7 As shown, the device includes the following parts:

[0235] The receiving module 710 is configured to receive an aggregation request sent by a client, wherein the aggregation request includes at least two interface identifiers selected by the client, and the interface identifiers are used to indicate interfaces that the server needs to call;

[0236] Processing module 720 is configured to obtain interface information corresponding to the interfaces respectively indicated by the at least two interface identifiers from a global configuration table, wherein the global configuration table is used to store information about the interfaces accessed by the server, the interface information including a calling method of the interface;

[0237] The processing module 720 is further configured to, when an i-th interface among the at least two interfaces meets a preset interface condition, call the i-th interface based on the interface information of the i-th interface to obtain a call result of the i-th interface, where the preset interface condition is related to a historical call status of the i-th interface, and i is a positive integer;

[0238] The sending module 730 is configured to send the call result to the client.

[0239] In some embodiments, the processing module 720 is further configured to:

[0240] Obtain a timeout configuration table, where the timeout configuration is used to indicate delay thresholds corresponding to all interfaces, including interfaces accessed by the server;

[0241] Obtaining the delay threshold corresponding to the i-th interface from the timeout configuration table;

[0242] In a case where the calling delay of the i-th interface does not exceed the delay threshold, the i-th interface is called based on the interface information of the i-th interface to obtain the calling result of the i-th interface.

[0243] In some embodiments, the processing module 720 is further configured to:

[0244] Traversing the full set of interfaces accessed by the server based on the global configuration table;

[0245] Calculate the weighted average delay of the j-th interface based on the call delay of calling the j-th interface in the full set of interfaces within a historical time period as the delay threshold corresponding to the j-th interface, where j is a positive integer;

[0246] The delay threshold corresponding to the j-th interface is written into the timeout configuration table.

[0247] In some embodiments, the processing module 720 is further configured to:

[0248] If the i-th interface meets the preset interface condition, write the i-th interface into an aggregation queue, where the aggregation queue is used to indicate the interface to be called as indicated by the aggregation request;

[0249] The interface in the aggregation queue is called based on the interface information to obtain the calling result.

[0250] In some embodiments, the processing module is further configured to:

[0251] Obtaining interface evaluation data corresponding to the i-th interface, the interface evaluation data including at least one of the call delay, call failure rate, call timeout rate, and call data volume of the interface;

[0252] When the interface evaluation data of the i-th interface meets the preset interface condition, the i-th interface is written into the aggregation queue.

[0253] In some embodiments, the preset interface condition includes at least one of the following:

[0254] The call delay of the i-th interface does not exceed a delay threshold corresponding to the i-th interface, where the delay threshold is determined based on an average call duration of calls to the i-th interface in a historical time period;

[0255] The call failure rate of the i-th interface is less than a preset failure rate threshold;

[0256] The call timeout rate of the i-th interface is less than a preset timeout rate threshold;

[0257] The call data volume of the i-th interface does not exceed a data volume threshold corresponding to the i-th interface, and the data volume threshold is determined based on an average call data volume of the i-th interface in the historical time period.

[0258] In some embodiments, the processing module 720 is further configured to:

[0259] Evaluating the interface priority of the i-th interface by using a pre-trained interface evaluation model, wherein the interface evaluation model is a machine learning model for evaluating the call priority of an interface based on an interface call scenario;

[0260] When the interface priority of the i-th interface reaches a preset priority range, it is determined that the i-th interface meets the preset interface condition, and the i-th interface is written into the aggregation queue.

[0261] In some embodiments, the processing module 720 is further configured to:

[0262] Get the interface information corresponding to the newly added interface;

[0263] Writing the interface information corresponding to the newly added interface into the global configuration table;

[0264] A full interface identifier is synchronized to the client based on the global configuration table, where the full interface identifier is used to indicate to the client the full interface accessed by the server.

[0265] In some embodiments, the processing module 720 is further configured to:

[0266] In response to a cold start of the client, synchronizing the full interface identifier to the client based on the global configuration table;

[0267] The updated global configuration table is obtained at preset time intervals, and the full interface identifier is synchronized to the client based on the updated global configuration table.

[0268] To sum up, the device provided in the embodiment of the present application dynamically sets differentiated evaluation criteria for each interface through a mechanism that associates preset interface conditions with historical call situations. For example, it dynamically sets differentiated timeout thresholds (such as setting a shorter timeout for high-frequency query interfaces and allowing longer response times for complex calculation interfaces), breaking through the limitation of forcing a unified timeout for all interfaces. It can improve the flexibility of handling response time differences for different interfaces, avoid the overall response to aggregated requests being affected by the fact that some interfaces have a long response time but do not actually time out, and thus improve the response efficiency to aggregated requests.

[0269] It should be noted that the interface aggregation request device provided in the above embodiment is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0270] Figure 8 The following is a block diagram of a terminal 800 according to an exemplary embodiment of the present application. The terminal 800 may be a smartphone, tablet computer, MP3 player, MP4 player, laptop computer, or desktop computer. The terminal 800 may also be referred to as user equipment, portable terminal, laptop terminal, desktop terminal, or other similar names.

[0271] Typically, the terminal 800 includes a processor 801 and a memory 802 .

[0272] The processor 801 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 801 may be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), and programmable logic array (PLA). The processor 801 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a central processing unit (CPU); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 801 may be integrated with a graphics processing unit (GPU), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 801 may also include an artificial intelligence (AI) processor, which is used to process computing operations related to machine learning.

[0273] The memory 802 may include one or more computer-readable storage media, which may be non-transitory. The memory 802 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices and flash memory storage devices. In some embodiments, the non-transitory computer-readable storage medium in the memory 802 is used to store at least one instruction, which is used to be executed by the processor 801 to implement the interface aggregation request method provided in the method embodiment of the present application.

[0274] In some embodiments, the terminal 800 further includes other components 803, which can be understood by those skilled in the art. Figure 8 The structure shown in the figure does not constitute a limitation on the terminal 800, and the terminal 800 may include more or fewer components than shown in the figure, or combine certain components, or adopt a different component arrangement.

[0275] The embodiment of the present application further provides a computer device, which can be implemented as follows: Figure 1 The terminal or server shown. The computer device includes a processor and a memory, wherein the memory stores at least one instruction, at least one program, code set, or instruction set, and the at least one instruction, at least one program, code set, or instruction set is loaded and executed by the processor to implement the interface aggregation request method provided by each of the above method embodiments.

[0276] An embodiment of the present application also provides a computer-readable storage medium, which stores at least one instruction, at least one program, code set or instruction set, and the at least one instruction, at least one program, code set or instruction set is loaded and executed by a processor to implement the interface aggregation request method provided by the above-mentioned method embodiments.

[0277] Embodiments of the present application also provide a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the interface aggregation request method provided in each of the above method embodiments.

[0278] Optionally, the computer-readable storage medium may include: Read Only Memory (ROM), Random Access Memory (RAM), Solid State Drives (SSD), or an optical disk. Among them, the random access memory may include resistance random access memory (ReRAM) and dynamic random access memory (DRAM). The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0279] Those skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware, or by a program to instruct the relevant hardware, and the program may be stored in a computer-readable storage medium, which may be a read-only memory, a disk, or an optical disk, etc.

[0280] The above description is merely an optional embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. An interface aggregation request method, characterized in that: The method comprises: Receive an aggregation request sent by a client, wherein the aggregation request includes at least two interface identifiers selected by the client, and the interface identifiers are used to indicate interfaces that the server needs to call; Obtaining interface information corresponding to the interfaces respectively indicated by the at least two interface identifiers from a global configuration table, wherein the global configuration table is used to store information about the interfaces accessed by the server, the interface information including a calling method of the interface; If an i-th interface among at least two interfaces meets a preset interface condition, calling the i-th interface based on the interface information of the i-th interface to obtain a calling result of the i-th interface, where the preset interface condition is related to a historical calling situation of the i-th interface, and i is a positive integer; Send the call result to the client.

2. The method according to claim 1, characterized in that The step of calling the i-th interface based on the interface information of the i-th interface when the i-th interface among the at least two interfaces meets the preset interface condition, and obtaining a calling result of the i-th interface includes: Obtain a timeout configuration table, where the timeout configuration table is used to indicate delay thresholds corresponding to all interfaces, where the full interface includes an interface accessed by the server; Obtaining the delay threshold corresponding to the i-th interface from the timeout configuration table; In a case where the calling delay of the i-th interface does not exceed the delay threshold, the i-th interface is called based on the interface information of the i-th interface to obtain the calling result of the i-th interface.

3. The method according to claim 2, characterized in that The acquisition timeout configuration table includes: Traversing the full set of interfaces accessed by the server based on the global configuration table; Calculate the weighted average delay of the j-th interface based on the call delay of calling the j-th interface in the full set of interfaces within a historical time period as the delay threshold corresponding to the j-th interface, where j is a positive integer; The delay threshold corresponding to the j-th interface is written into the timeout configuration table.

4. The method according to any one of claims 1 to 3, characterized in that: The step of calling the i-th interface based on the interface information of the i-th interface when the i-th interface among the at least two interfaces meets the preset interface condition, and obtaining a calling result of the i-th interface includes: If the i-th interface meets the preset interface condition, write the i-th interface into an aggregation queue, where the aggregation queue is used to indicate the interface to be called as indicated by the aggregation request; The interface in the aggregation queue is called based on the interface information to obtain the calling result.

5. The method according to claim 4, characterized in that When the i-th interface meets the preset interface condition, writing the i-th interface into the aggregation queue includes: Obtaining interface evaluation data corresponding to the i-th interface, the interface evaluation data including at least one of the call delay, call failure rate, call timeout rate, and call data volume of the interface; When the interface evaluation data of the i-th interface meets the preset interface condition, the i-th interface is written into the aggregation queue.

6. The method according to claim 5, characterized in that The preset interface condition includes at least one of the following: The call delay of the i-th interface does not exceed a delay threshold corresponding to the i-th interface, where the delay threshold is determined based on an average call duration of calls to the i-th interface in a historical time period; The call failure rate of the i-th interface is less than a preset failure rate threshold; The call timeout rate of the i-th interface is less than a preset timeout rate threshold; The call data volume of the i-th interface does not exceed a data volume threshold corresponding to the i-th interface, and the data volume threshold is determined based on an average call data volume of the i-th interface in the historical time period.

7. The method according to claim 4, characterized in that When the i-th interface meets the preset interface condition, writing the i-th interface into the aggregation queue includes: Evaluating the interface priority of the i-th interface by using a pre-trained interface evaluation model, wherein the interface evaluation model is a machine learning model for evaluating the call priority of an interface based on an interface call scenario; When the interface priority of the i-th interface reaches a preset priority range, it is determined that the i-th interface meets the preset interface condition, and the i-th interface is written into the aggregation queue.

8. The method according to any one of claims 1 to 3, characterized in that: Before receiving the aggregation request sent by the client, the method further includes: A full interface identifier is synchronized to the client based on the global configuration table, where the full interface identifier is used to indicate to the client the full interface accessed by the server.

9. The method according to claim 8, characterized in that The synchronizing all interface identifiers to the client based on the global configuration table includes: In response to a cold start of the client, synchronizing the full interface identifier to the client based on the global configuration table; The updated global configuration table is obtained at preset time intervals, and the full interface identifier is synchronized to the client based on the updated global configuration table.

10. The method according to claim 8, characterized in that The synchronizing all interface identifiers to the client based on the global configuration table includes: Obtaining a client identifier of the client, where the client identifier is used to uniquely identify the client; Based on the client identifier, at least one interface that the client has the right to call is screened from the global configuration table, where the right to call is related to at least one of the client type, the client level, and the client's historical call status; Synchronize the interface identifier of the at least one interface to the client.

11. The method according to claim 8, characterized in that The method further comprises: Get the interface information corresponding to the newly added interface; The interface information corresponding to the newly added interface is written into the global configuration table to obtain an updated global configuration table.

12. An interface aggregation request device, characterized in that: The device comprises: A receiving module, configured to receive an aggregation request sent by a client, wherein the aggregation request includes at least two interface identifiers selected by the client, and the interface identifiers are used to indicate interfaces that the server needs to call; a processing module, configured to obtain, from a global configuration table, interface information corresponding to the interfaces respectively indicated by the at least two interface identifiers, wherein the global configuration table is used to store information about the interfaces accessed by the server, the interface information including a calling method of the interface; The processing module is further configured to, when an i-th interface among the at least two interfaces meets a preset interface condition, call the i-th interface based on the interface information of the i-th interface to obtain a call result of the i-th interface, wherein the preset interface condition is related to a historical call status of the i-th interface, and i is a positive integer; A sending module is used to send the call result to the client.

13. A computer device, characterized in that: The computer device includes a processor and a memory, wherein the memory stores at least one computer program, and the at least one computer program is loaded and executed by the processor to implement the interface aggregation request method according to any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that The storage medium stores at least one computer program, and the at least one computer program is loaded and executed by the processor to implement the interface aggregation request method according to any one of claims 1 to 11.

15. A computer program product, characterized in that The method comprises a computer program, which, when executed by a processor, implements the interface aggregation request method according to any one of claims 1 to 11.

Images