An API interface processing method and apparatus

Abstract

This application relates to the field of Internet technology and discloses an API interface processing method and apparatus. The method includes: acquiring read / write attributes and traffic metrics data of each API interface in a target system within a first time period, based on a first sampling period; grouping the API interfaces based on the read / write attributes to obtain multiple interface groups; determining the importance of each API interface within each interface group, at least based on the traffic metrics data; determining the target level of each API interface based on the hierarchical ratio of the target system and the importance of each API interface within each interface group; and allocating corresponding interface resources to each API interface based on its target level. This method enables efficient and accurate hierarchical management of API interfaces in a system, improving system resource utilization and service performance.

Description

Technical Field

[0001] This application relates to the field of Internet technology, specifically to an API interface processing method and apparatus. Background Technology

[0002] Distributed systems, microservice architectures, and API (Application Programming Interface) gateways are widely used in e-commerce, multimedia, and other network platforms, where systems provide services externally through API interfaces. To ensure the quality of these services, API interface management is crucial. API interface management primarily involves configuring various information for each interface in the system based on its different levels, such as configuring computing resources (servers, network bandwidth, etc.), testing resources (test coverage, test environment, etc.), and fault response priorities. For example, higher-level API interfaces have more configured computing resources, larger network bandwidth, more robust load balancing strategies, stricter monitoring and alarm conditions, higher test coverage, and higher fault recovery priorities. Proper management of each API interface can improve the reliability of the services provided, optimize overall system resource utilization, and enhance service performance.

[0003] Current interface management solutions mostly employ manual hierarchical management or hierarchical management based on fixed indicator thresholds. However, manual management based on experience is not only inefficient but also prone to problems such as misjudgment of interface levels and omission of interface configurations. On the other hand, the hierarchical management method based on fixed indicator thresholds lacks flexibility, cannot cope with dynamic changes in the system, and suffers from problems such as lagging interface information configuration and unreasonable configuration, resulting in low system resource utilization and service performance. Summary of the Invention

[0004] The purpose of this application is to provide an API interface processing method and apparatus to achieve efficient, flexible and accurate API interface resource allocation, thereby improving system resource utilization and service performance.

[0005] To achieve the above objectives, the technical solution of this application is as follows: In a first aspect, embodiments of this application provide an API interface processing method, the method comprising: Based on the first sampling period, obtain the read / write attributes and traffic metrics of each API interface in the target system within the first time period; Based on the read and write attributes, the API interfaces are grouped to obtain multiple interface groups; wherein all API interfaces within each interface group have the same read and write attributes. For each interface group, the importance of each API interface in the interface group should be determined based on traffic metric data at least. Based on the hierarchical ratio of the target system and the importance of each API interface in each interface group, the target level corresponding to each API interface is determined. Based on the target level corresponding to each API interface, allocate corresponding interface resources to the API interface.

[0006] Secondly, embodiments of this application provide an API interface processing apparatus for implementing the steps of the method provided in the first aspect of this application. The apparatus includes: The data acquisition module is configured to acquire read / write attributes and traffic metrics data of each API interface in the target system within the first time period, based on the first sampling period. The hierarchical module is configured to group each API interface based on the read / write attributes to obtain multiple interface groups; wherein all API interfaces in each interface group have the same read / write attributes; for each interface group, the importance of each API interface in the interface group is determined at least based on traffic metric data; based on the hierarchical ratio of the target system and the importance of each API interface in each interface group, the target level corresponding to each API interface is determined; The interface configuration module is configured to allocate corresponding interface resources to each API interface based on the target level corresponding to each API interface.

[0007] The API interface processing method provided in this application first dynamically acquires the read / write attributes and traffic metrics data of each API interface in the target system within a first time period based on the first sampling period. The API interfaces are then grouped based on their read / write attributes, resulting in multiple interface groups. Each API interface within a group shares the same attributes. Next, the importance of each API interface within each group is determined based on its traffic metrics data. Furthermore, based on the importance of each API interface within each group and the system's hierarchical structure, the target level of each interface within the group is determined, and corresponding level interface resources are allocated to each interface.

[0008] This application dynamically collects read / write attributes and traffic metrics data from API interfaces, combining this two-dimensional information for comprehensive analysis of API interfaces to achieve a complete assessment of their current importance. Furthermore, based on the system's hierarchical ratio and importance, API interfaces are categorized by level to allocate resources accordingly. Compared to traditional interface management methods that rely on manual categorization or fixed threshold metrics, this solution, based on dynamically collected multi-dimensional information (including read / write attributes and traffic metrics data), can more comprehensively and accurately assess the current importance of each API interface. Furthermore, by treating interface groups as a whole, and based on categorization ratios and interface importance, interface categorization and resource allocation are performed within each group. This allows for more flexible adaptation to dynamic system changes, ensuring that resource allocation for each interface matches its real-time status, improving the accuracy and timeliness of resource allocation, and enhancing system resource utilization and service performance. Attached Figure Description

[0009] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a flowchart of an API interface processing method proposed in an embodiment of this application; Figure 2 This is a flowchart illustrating the hierarchical classification of the API interfaces of a target system in one embodiment of this application; Figure 3 This is a schematic diagram of an API interface processing device according to an embodiment of this application. Detailed Implementation

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

[0012] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

[0013] In the various embodiments of this application, it should be understood that the sequence number of each process described below does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0014] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects as detailed in this application.

[0015] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other.

[0016] Traditional API interface classification methods rely heavily on human experience, subjectively judging based on documentation or historical data. This is inefficient and struggles to handle frequently changing interfaces and traffic, easily leading to delays or misjudgments. Related solutions use fixed traffic thresholds for interface classification. For example, interfaces with QPS greater than 1000 are classified as high-level. However, this approach lacks flexibility and doesn't consider interface attributes, easily resulting in misclassification of critical interfaces (e.g., a high-risk write interface might be classified as a low-level interface due to low traffic).

[0017] This embodiment combines the read / write attributes and traffic metrics of the interface for comprehensive analysis to accurately determine the importance of the API interface, and automatically classifies and allocates resources for the system interface based on importance ranking and classification ratio.

[0018] The present application will now be described in detail with reference to the accompanying drawings and embodiments.

[0019] Figure 1 This is a flowchart of an API interface processing method proposed in an embodiment of this application. For example... Figure 1 As shown, the method includes: S1: Based on the first sampling period, obtain the read / write attributes and traffic metrics of each API interface in the target system within the first time period; S2: Group the API interfaces based on the read / write attributes to obtain multiple interface groups; wherein, all API interfaces within each interface group have the same read / write attributes; S3: For each interface group, determine the importance of each API interface in the interface group based at least on traffic metric data; S4: Based on the hierarchical ratio of the target system and the importance of each API interface in each interface group, determine the target level corresponding to each API interface; S5: Allocate corresponding interface resources to each API interface based on the target level corresponding to each API interface.

[0020] In this embodiment, the collection of read / write attributes and traffic metrics data for API interfaces relies on an interface management platform and a monitoring platform deployed within the target system. When performing dynamic API interface hierarchical management, a sliding window mechanism is used. Based on a first sampling period (e.g., 10 seconds), the read / write attributes of each API interface within the most recent first time period are obtained from the target system's interface management platform (e.g., YAPI). Additionally, log data or database information for each interface within the first time period is dynamically retrieved from the target system's monitoring platform (e.g., the Prometheus component) to obtain traffic data, and the corresponding traffic metrics data are calculated.

[0021] The read / write attributes of interfaces in the system describe the data operation types and access permissions of the interfaces. The importance of read interfaces is largely determined by traffic volume; while write interfaces (such as POST / PUT / DELETE) typically involve data changes. Although write interfaces usually have lower traffic, their risks are far greater than read interfaces, significantly impacting system stability. For example, in traditional interface tiering schemes, evaluating solely based on traffic volume can lead to low-traffic but critical payment interfaces (write interfaces) being misclassified as low-priority interfaces. To avoid this problem, this embodiment, after obtaining the read / write attributes and traffic metrics of the interfaces, first divides the API interfaces into multiple interface groups according to their read / write attributes. These groups isolate the subsequent importance assessment of interfaces with different read / write attributes, thus avoiding misjudgments of interface importance due to a single-dimensional assessment based on traffic volume. Furthermore, it ensures that interfaces with the same read / write attributes are reasonably distributed across different levels according to a set tiering ratio, preventing excessive waste or insufficient allocation of system resources. This balances performance and cost while ensuring business performance.

[0022] Optionally, all API interfaces can be grouped into multiple interface groups based on the HTTP methods used for reading and writing attributes. The HTTP methods for these interfaces include: GET, HEAD, OPTIONS, POST, PUT, DELETE, PATCH, MOCK, etc. For example, all interfaces using the GET HTTP method can be grouped into one interface group, all interfaces using the POST HTTP method into another, and all interfaces using the PUT HTTP method into yet another.

[0023] Optionally, all API interfaces can be divided into two groups based on their read and write operation types. Specifically, the HTTP method tags (e.g., POST, PUT, DELETE) of the interfaces are obtained from the interface management platform, and the interface type (read or write) is determined based on these tags. For example, interfaces with the HTTP method tag POST are classified as write-type. Interfaces with read-only HTTP methods are grouped into the read-type interface group, and interfaces with write-only or read-write operation types are grouped into the write-type interface group.

[0024] Then, based at least on the interface traffic metrics data, the importance of API interfaces within each interface group is assessed to determine the importance of each interface within the group. According to the system's hierarchical structure and the importance of each interface within the group, the interfaces within each group are classified into different levels, and corresponding interface resources are allocated to each level.

[0025] In this embodiment, the system's hierarchical ratio includes the proportion of all interface levels corresponding to each interface group in the system. For example, in the hierarchical ratio, arranged in descending order of priority, the proportions corresponding to each level are: P0 level (20%), P1 level (40%), and P2 level (40%). The write interface group contains 30 API interfaces (such as order submission), and the read interface group contains 70 API interfaces (such as product query). Based on the hierarchical ratio, the write interface group and the read interface group are divided separately. The write interface group has 6 P0 level interfaces, 12 P1 level interfaces, and 12 P2 level interfaces; the read interface group has 14 P0 level interfaces, 28 P1 level interfaces, and 28 P2 level interfaces. By dynamically hierarchically classifying the interfaces within each interface group according to the hierarchical ratio, the interfaces of each type of read and write attribute are reasonably distributed across all interface levels. This achieves a balanced allocation of system resources across different types of interfaces, avoiding the concentration of a certain type of interface at a certain level, which could cause performance bottlenecks or resource waste for certain services, and ensuring the system's resource overhead and stable overall service performance.

[0026] In one embodiment, QPS (Query Per Second) data for each interface in the system is collected from the monitoring platform within the most recent first time period (e.g., 7 days), and its peak QPS and / or average QPS are calculated as the corresponding traffic metric data. QPS data reflects the actual load of the interface. In this embodiment, QPS data is used to evaluate the importance of each interface within an interface group. For each interface group, the API interfaces within the group are sorted in descending order according to the traffic metric data (e.g., peak QPS), which serves as the importance ranking result. Interfaces ranked higher are more important. After obtaining the importance ranking result for each interface group, all API interfaces within each interface group are classified into different levels based on the system's hierarchical ratio, realizing dynamic hierarchical operation of system interfaces.

[0027] Compared to the traditional interface classification method that uses a fixed threshold, this embodiment treats each interface group as a whole. By utilizing the classification ratio and the importance of the interface group, the API interfaces within each interface group are classified into different levels. This keeps the distribution of interfaces of different types and levels stable within a reasonable range, dynamically adapting to changes in interface attributes and the number of interfaces in the system (such as old interfaces being taken offline, new interfaces being launched, or interface attribute changes). This avoids missed or false judgments, improving the accuracy and stability of interface classification while balancing the system's business performance and resource costs.

[0028] For example, when the interfaces in the system change dynamically, by dynamically obtaining the read / write attributes and traffic metrics of the API interfaces in the system, and combining them with the hierarchical ratio, this solution can fine-tune the level and resource configuration of some interfaces while maintaining a relatively stable number of interfaces at each level, thereby maintaining the stability and overall performance of the system.

[0029] As one embodiment of this application, the traffic indicator data includes at least one of the following: peak request traffic, average request traffic; and / or The interface resources include: computing resources, testing resources, and operation and maintenance resources.

[0030] In one embodiment, after determining the target level of the interface, corresponding levels of computing resources, testing resources, and operational resources are allocated to the interface based on the amount of allocable resources in the system. Optionally, computing resources include: CPU resources, memory resources, machine / server instances, bandwidth, etc.; testing resources include: test environment resources, test cases and scripts, test content and coverage depth, etc.; operational resources include: monitoring and alarm resources, monitoring frequency, fault response strategies, etc.

[0031] For example, the higher-priority P0 level will be allocated more CPU and memory resources, higher bandwidth, and deeper test coverage compared to the lower-priority P2 level. It has a higher monitoring frequency and higher fault response priority. Compared to the lower-priority P2 level which only performs basic functional tests, the P0 level needs to perform more detailed and in-depth test tasks, such as exploratory testing, stress testing, and security testing.

[0032] In addition, after classifying and allocating interface resources for each API interface for the first time, the current level of the interface will be synchronized to the interface management platform for subsequent dynamic reading.

[0033] Optionally, a timer can be used to continuously execute the interface leveling task of the target system, dynamically monitoring and adjusting the level of all interfaces in the system according to the first sampling period. During this process, if the level of an API interface changes, the updated level will be synchronized to the interface management platform. In practical applications, methods such as batch database updates and REST API calls can be used to synchronize interface level information in batches.

[0034] As one embodiment of this application, step S1 further includes: obtaining a first attribute of the API interface in multiple dimensions; the first attribute of the multiple dimensions includes at least two of the following: data sensitivity, transaction dependency, response error rate, historical traffic peak, interface response latency, and business type; The above step S3 specifically includes: S31-1: Based on the first weight corresponding to each first attribute of each API interface in the interface group and the second weight corresponding to the traffic indicator data of the API interface, the importance score of the API interface is obtained; the higher the importance score, the higher the importance of the API interface.

[0035] In one embodiment, the importance of an interface is determined by further comprehensive analysis based on its multi-dimensional first attributes and traffic metric data within a first time period. Specifically, in addition to acquiring the read / write attributes of the interface, this embodiment also collects other multi-dimensional first attributes of the interface. When evaluating the importance of an interface, a weighted approach is used to calculate the importance score of each API interface in the system based on the read / write attributes, the multi-dimensional first attributes, and the traffic metric data. In this embodiment, corresponding first weights are pre-assigned to different first attributes, and traffic intervals for dividing traffic metric data are pre-set, with corresponding weights assigned to each traffic interval. The higher the traffic metric data corresponding to a traffic interval, the greater the weight of that interval.

[0036] For traffic metric data, after obtaining the traffic metric data for each API interface, this data is mapped to a corresponding traffic interval, and the weight of the corresponding traffic interval is determined as the second weight of the traffic metric data for that interface. For multi-dimensional first attributes, after obtaining the multi-dimensional first attributes for each API interface from the interface management platform, the first weight corresponding to each first attribute is obtained. Further, based on the multi-dimensional first attributes, traffic metric data, and their respective weights for each API interface, a weighted sum is calculated, and a normalization process is performed to obtain the importance score for each API interface. Then, the interfaces are sorted in descending order according to their corresponding importance scores, and the target level and allocated interface resources are determined based on the system's tiering ratio.

[0037] In this embodiment, the first attribute of the multi-dimensional dimension includes at least the following items: (1) Read and write attributes; these refer to the data operation types of the interface. Read attributes include POST, PUT, DELETE, etc., while write attributes include GET, MOCK, etc. Among them, write attributes have a higher weight than read attributes; (2) Data sensitivity: This refers to whether the interface involves users' privacy information or sensitive data. Operations involving privacy information have a higher weight than operations without privacy information. (3) Transaction dependency: This refers to the fact that the interface is in a core transaction chain that requires data consistency during business processing. If the interface fails, the entire transaction will be rolled back or the data will be inconsistent. For example, the payment confirmation interface is a highly transaction-dependent interface. After a user submits an order on an e-commerce platform and enters the payment process, if the payment interface fails to execute the "deduct balance" operation, the entire transaction will be rolled back, causing the payment business to be interrupted. In this embodiment, the weight of interfaces with transaction dependencies (such as payment) is higher than the weight of interfaces without transaction dependencies.

[0038] (4) Response error rate: refers to the proportion of errors that occur during the historical operation of the interface. In this embodiment, the response error rate of the interface is divided into multiple intervals [0,1] according to a fixed threshold, where the higher the error rate, the higher the importance and the greater the weight; (5) Historical peak traffic: refers to the highest peak traffic reached by the interface over a relatively long historical period, used to reflect the long-term load level of the interface. In this embodiment, long-term (e.g., 6 months) QPS peak traffic statistics are used, and multiple weighted intervals [0,1] are divided according to a fixed threshold to reflect the interface load weight; (6) Interface response latency: refers to the time consumed by the interface from receiving a request to returning a response. In this embodiment, multiple intervals are divided according to a fixed threshold, corresponding to the weight interval [0,1]. The higher the interface response latency, the greater the weight. (7) Business Type: Weights are assigned based on whether the business is a core business and the magnitude of its impact on users, representing the importance of the business. The greater the core business and the magnitude of its impact on users, the higher the corresponding weight. For example, core businesses that directly affect the core user experience or data security (e.g., payment business) are assigned higher weights, while auxiliary businesses or internal system functions (e.g., background log queries) are assigned lower weights.

[0039] In one example, the business scenarios include: core transaction scenarios, user identity security scenarios, core content access scenarios, operational activity scenarios, backend management scenarios, and tool assistance scenarios. The weights are assigned according to the importance of each business scenario as follows: Core transaction scenarios such as payment, order placement, top-up, membership activation, and deduction have a weight of 1. User identity security scenarios, such as login, authentication, and account security, have a weight of 0.9. Core content access scenarios such as video playback, homepage recommendations, content details, and search have a weight of 0.8. Operational activities such as major sales events, red envelopes, lucky draws, and limited-time offers have a weight of 0.7. Back-end management scenarios such as data statistics and back-end approval: weight is 0.4; Test scenarios such as event tracking, logging, mocking, and API testing have a weight of 0.1–0.2.

[0040] This embodiment improves the accuracy of overall interface importance assessment by performing weighted comprehensive analysis on multi-dimensional attributes and traffic metrics of the interface, thereby enhancing system resource utilization and service performance.

[0041] As one embodiment of this application, step S1 further includes: obtaining a first attribute of the API interface in multiple dimensions; the first attribute of the multiple dimensions includes at least two of the following: data sensitivity, transaction dependency, response error rate, historical traffic peak, interface response latency, and business type; The above step S3 specifically includes: S31-2: Based on the first attribute and traffic indicator data of each API interface in each interface group, construct the feature vector corresponding to the API interface; S32-2: Input the feature vectors corresponding to each API interface into the first regression model after training to obtain the importance score corresponding to the API interface; the higher the importance score, the higher the importance of the API interface.

[0042] In one embodiment, machine learning methods are used to comprehensively analyze the multi-dimensional primary attributes and traffic metrics data of each interface in the system within the most recent first time period, thereby achieving a comprehensive assessment of the importance of the interfaces in the system.

[0043] Specifically, the system collects multi-dimensional primary attribute and traffic indicator data for each API interface within a first time period, and constructs feature vectors (time-series features) based on the collected data. Specifically, the primary attribute and traffic indicator data for each dimension of the target API interface at the current time are quantized and encoded, and then concatenated in a fixed order to obtain the feature vector corresponding to the interface at the current time.

[0044] For example, the attribute of transaction dependency is quantified and encoded according to type, with non-transactional dependency = 0, low transaction dependency = 1, and high transaction dependency = 2; for business type, an ordered numerical encoding method is adopted according to the priority weight specified by the user, and the weight value of each business type is used as the corresponding code; for traffic indicator data, the traffic indicator data in the current sampling period is normalized to obtain the corresponding code.

[0045] By concatenating the encoding of the first attribute of each dimension with the encoding of the traffic metric data, the feature vector of the target API interface at the current moment is represented as: [data sensitivity, transaction dependency, response error rate, historical traffic peak, interface response latency, business type, traffic metric data].

[0046] The first regression model, which has been pre-trained, processes the feature vectors of each API interface in the system and outputs the corresponding importance scores. Then, in the subsequent interface classification stage, all API interfaces are sorted in descending order of importance scores to obtain the importance ranking results. The importance ranking results are then divided according to the classification ratio of the system to determine the target level of each interface.

[0047] Compared to the weighted analysis method used in the above embodiments, training the first regression model through machine learning enables the model to adaptively learn the implicit relationships between the first attributes in different dimensions and between the first attributes and traffic indicator data, resulting in more accurate importance assessment results and further improving the accuracy of interface classification.

[0048] In addition, in this embodiment, the first regression model that has been trained is used to continuously and dynamically analyze the first attribute and traffic indicator data of the interface, so that the model can adapt to the dynamic changes of each interface through incremental learning and can better cope with complex and dynamic business scenarios.

[0049] As one embodiment of this application, before step S32-2 above, the method further includes: S301-2: Obtain the first attribute, traffic metric data, and importance score of each API interface at multiple times within the second time period; S302-2: For each API interface, based on the first attribute and traffic indicator data of the API interface at each moment in the second time period, construct the first feature data of the API interface at each moment; S303-2: Use the importance scores of each API interface at each time point in the second time period as the first sample label, and associate them with the first feature data at the corresponding time point to obtain training samples; S304-2: Train the initial regression model based on all training samples to obtain the first regression model after training.

[0050] In the above embodiment, historical data from each interface in the system (including multi-dimensional primary attributes, traffic metric data, and importance scores) is used to train a first regression model to dynamically evaluate the importance of each interface. The specific process is as follows: (1) Collect the first attribute and traffic index data of each API interface in the system at all times in the second historical time period (e.g., 1 month) according to the set sampling frequency (e.g., 1 time / minute), and construct multi-dimensional time series feature data (i.e., first feature data) in chronological order. (2) Use the importance scores of each moment in the second time period that have been manually confirmed or manually labeled as the first sample label of the first feature data of the corresponding moment to construct the time sequence of the training samples; (3) A fixed-length sliding window is used to select a fixed length of time-series training samples to train the first regression model, resulting in a trained first regression model for subsequent interface automation hierarchical management. Optionally, in practical applications, the window length can be set according to the system's business cycle as needed. For example, based on the platform's 7-day promotional activity cycle, the sliding window length is set to 7 days. In practical applications, the first regression model can be selected according to actual needs; for example, the GBDT model, XGBoost model, LightGBM model, etc., can be used.

[0051] In one embodiment, after obtaining the importance scores of API interfaces in each interface group, all API interfaces within each interface group are sorted in descending order of importance score to obtain the importance ranking result corresponding to that interface group. Then, the API interfaces in each interface group are classified into different levels based on the system's hierarchical ratio. Specifically, for each interface group, the importance ranking result of that interface group is divided according to the system's hierarchical ratio. Starting from the first interface in the ranking result, interfaces are divided into high-priority P0, medium-priority P1, and low-priority P2, where high-priority interfaces are ranked before medium-priority interfaces, and medium-priority interfaces are ranked before low-priority interfaces.

[0052] For example, if the writing interface group contains 30 API interfaces, according to the system's hierarchical ratio of "P0 level (20%), P1 level (40%), P2 level (40%)", the first 6 interfaces in the sorting results are classified as P0 level, the 7th to 18th interfaces are classified as P1 level, and the 19th to 30th interfaces are classified as P2 level.

[0053] As one embodiment of this application, step S4 specifically includes: S41: Sort all API interfaces in each interface group in descending order of importance score to obtain the importance ranking result of the interface group; S42: Obtain the initial classification ratio and corresponding fluctuation range of the target system; the initial classification ratio is arranged from high to low, including: a first ratio corresponding to the first level, a second ratio corresponding to the second level, and a third ratio corresponding to the third level; the first ratio is less than the second ratio and the third ratio; S43: Obtain the quality indicator data of each API interface in each interface group during the first time period, including: computing resource utilization, fault response latency and request response success rate; S44: Based on the quality indicator data and importance scores of each API interface in each interface group, determine the grading ratio of the interface group within the fluctuation range of the initial grading ratio; S45: Based on the hierarchical ratio of the interface group, divide the importance ranking results of the interface group to determine the target level corresponding to each API interface.

[0054] In one embodiment, an adaptive adjustment of the dynamic hierarchical ratio is adopted. Based on the initial hierarchical ratio of the system, the hierarchical ratio corresponding to each interface group is determined. After obtaining the importance ranking results of each interface group, the preset initial hierarchical ratio of the target system and the floating range of the ratio corresponding to each interface level in the system are obtained.

[0055] Optionally, the target system sets three interface levels and a corresponding fluctuation range for each level. The interface levels are ranked from highest to lowest priority as follows: Level 1 P0, Level 2 P1, and Level 3 P2, with the sum of the proportions of the three levels being 100%. This ensures that the proportion of the first level is always less than the proportions of the second and third levels within the fluctuation range. This improves the reliability of high-priority interfaces while avoiding resource waste in low-priority interfaces, thereby increasing the overall resource utilization of the system. For example, based on the Pareto principle, the initial proportion of each level is set as follows: the initial proportion of the highest priority level 1 is set to 20%, with a fluctuation range of 10%-30%; the initial proportion of the second highest priority level 2 P1 is set to 35%, with a fluctuation range of 30%-40%; and the initial proportion of the lowest priority level 3 P2 is set to 45%, with a fluctuation range of 40%-50%.

[0056] The system obtains quality indicator data for each interface within the most recent first time period from the target system's monitoring platform. This includes: interface computational resource utilization, fault response latency, and request response success rate. Based on the quality indicator data and importance scores of all interfaces in the system within the first time period, the corresponding grading ratio for each interface group is determined within the initial grading ratio fluctuation range to dynamically adapt to the system's service requirements. Optionally, based on user-specified optimization goals (such as improving overall resource utilization or reducing fault response latency for a certain type of business), the grading ratio for each level is fine-tuned within the fluctuation range at a fixed step size (e.g., 1%). For example, if the average fault response latency of the write interfaces related to orders and payments in the system exceeds a set threshold, the proportion of the first level (i.e., higher level) in the write interface group is increased accordingly within the fluctuation range, while the proportion of the second and / or third levels is decreased.

[0057] Then, using the hierarchical ratios of each interface group, the importance ranking results of the interface group are divided to determine the current target level of each API interface. In this embodiment, by acquiring the quality indicator data and importance scores of interfaces in the system over a recent period, dynamic changes in the system's operating status can be captured in a timely manner. By setting the fluctuation range of each hierarchical ratio, the number of different types of API interfaces in the system can be fine-tuned within a reasonable range based on the dynamic changes in the recent system operating status, achieving dynamic adaptation between interface resource allocation and system operating status. Furthermore, by setting the fluctuation range of each level of interface, excessive changes in the hierarchical ratio caused by short-term data fluctuations or local anomalies can be avoided, which could lead to drastic oscillations in resource allocation strategies, thereby ensuring the stability and reliability of system operation.

[0058] In one embodiment, a reinforcement learning method is used to train a first prediction model to predict the current grading ratio of the interface group based on the quality indicator data and importance scores of each interface within the interface group in the most recent first time period. Specifically, from the historical log data of the interface management platform, the quality indicator data of all interfaces in each interface group and the corresponding grading ratio of the interface group are obtained within multiple sampling periods based on the length of the first sampling period in the past third time period (e.g., the past month).

[0059] For each sampling period T, the constructed state s_t includes: statistical characteristics of the quality index data of all API interfaces within that sampling period (e.g., the average value of the interface's computational resource utilization), the importance score of each interface, and the grading ratio of the interface group, thus constructing training samples. Additionally, actions a_t are defined based on the change records of the grading ratio, including: the adjustment amounts of the interface group to the system's initial grading ratio within the sampling period: ΔP0_t, ΔP1_t, and ΔP2_t.

[0060] The reward function r_t is constructed based on the optimization objectives of the interface quality index data (such as improving overall resource utilization, reducing fault response latency of high-level interfaces, and improving the response success rate of high-level interfaces). Training samples (s_t, a_t, r_t, s_{t+1}) are constructed based on sample data from each sampling period within the third time period. The first prediction model is iteratively trained using reinforcement learning algorithms (such as DDPG, PPO, etc.) with the optimization objective of maximizing the cumulative reward of historical sampling periods. Gradient descent is used to update the policy network parameters, resulting in the trained first prediction model.

[0061] As one embodiment of this application, after step S31-1 or step S32-2 described above, the method further includes: S241: Obtain the first attribute and traffic indicator data of the API interface in the current first sampling period, and construct the corresponding time-series features; S242: Input the time-series features into a pre-trained second prediction model, and use the second prediction model to generate the importance fluctuation trend of the API interface in the next sampling period; the importance fluctuation trend is: rising, stable, or falling; S243: Determine the corresponding fluctuation weight based on the importance fluctuation trend of each API interface in the next sampling period; S244: Update the importance score of each API interface based on the fluctuation weight of each API interface; Step S4 above specifically includes: determining the target level corresponding to each API interface based on the updated importance score of each API interface and the grading ratio of the target system.

[0062] In practical applications, the importance of API interfaces can fluctuate due to sudden trending events, platform promotions, or changes in interface attributes. To address the dynamic changes in the importance of system interfaces and further improve the accuracy and stability of interface management, in one embodiment, after obtaining the importance score of an interface by analyzing its multi-dimensional first attribute and traffic indicator data, a pre-trained second prediction model is used to predict the future fluctuation trend of the importance of API interfaces in each interface group, thereby providing forward-looking reference information for interface classification.

[0063] The second prediction model, based on the API's primary attribute and traffic metrics data from the current sampling period and several previous sampling periods, predicts the importance fluctuation trend of the API in the next sampling period after the current moment, including whether it is rising, stable, or falling. The importance score of each API is weighted and adjusted according to the fluctuation weight corresponding to its importance fluctuation trend in the next sampling period. Specifically, the fluctuation weight of an upward trend is greater than that of a stable trend, and the fluctuation weight of a stable trend is greater than that of a downward trend. By predicting the importance fluctuation trend of the API in the next sampling period, the target level determined for the API in the current sampling period can be matched with the current business needs and potential future business trends of the API.

[0064] Optionally, the first attribute, traffic metric data, and corresponding importance scores of each interface are collected within the fourth historical time period. Data is selected based on the length of the first sampling period to construct corresponding time-series features as training samples. Within adjacent sampling periods, the change in the importance score of each interface is compared with the corresponding first threshold to determine the importance fluctuation trend of the interface within that period.

[0065] For example, within two consecutive periods, the importance score of the interface increased by 15 points, exceeding the first threshold by 8 points. Therefore, the importance fluctuation trend of the interface within this sampling period is determined to be upward.

[0066] The importance fluctuation trends corresponding to each sampling period are used as sample labels. A time-series-based second prediction model is trained using these training samples through machine learning. During the dynamic grading phase of the system interface, corresponding time-series features are constructed based on the first attribute and traffic indicator data within the first sampling period. The trained second prediction model processes these time-series features to predict the importance fluctuation trend for the next sampling period. For example, the second prediction model predicts the importance fluctuation trend for the next 7 days based on the first attribute and traffic indicator data from the past 7 days.

[0067] Figure 2 This is a flowchart illustrating the hierarchical classification of the API interfaces of a target system in one embodiment of this application. For example... Figure 2As shown, based on the first sampling period, the read / write attributes and multi-dimensional primary attributes of each interface within the most recent first time period are obtained from the target system's interface management platform; and the traffic data of each interface within the first time period is obtained from the target system's monitoring platform, and the corresponding traffic metric data is calculated. API interfaces are divided into multiple interface groups based on read / write attributes. For each interface group, the importance score of each interface within the group is evaluated based on the traffic metric data and primary attributes within the current sampling period. The primary attributes and traffic metric data within the current sampling period are processed using a second prediction model to predict the importance fluctuation trend of each interface in the next sampling period. The importance score of the interface is corrected based on the importance fluctuation trend, and all interfaces are sorted in descending order of importance score to obtain the importance ranking result. Then, the quality metric data of each interface is obtained from the monitoring platform, and the quality metric data and importance score of each API interface are processed using the first prediction model. Based on the initial grading ratio of the target system, the grading ratio of each interface group is determined to maximize the overall resource utilization of the system. Finally, based on the grading ratio and importance ranking result of each interface group, the target level of each API interface within the group is determined.

[0068] As one embodiment of this application, before step S5 above, the method further includes: S501: Obtain the level identifier of the API interface, and compare the level corresponding to the level identifier with the target level; S502: If the target level is different from the level corresponding to the level identifier, generate a level adjustment instruction corresponding to the API interface; S503: Based on the level adjustment instruction, update the level identifier of the API interface to the level identifier corresponding to the target level; Step S5 specifically includes: S51: Based on the updated level identifier of the API interface, allocate interface resources to the API interface that match the target level.

[0069] In one embodiment, after initially classifying API interfaces and allocating corresponding interface resources, a level identifier is generated based on the current level of the interface and synchronized to the interface management platform of the target system. During subsequent periodic dynamic classification monitoring, if the API interface level changes, after adjusting the interface level and interface resources, the new level identifier must also be synchronized to the interface management platform for update.

[0070] In this embodiment, after determining the target level of a target API interface based on its importance and tiering ratio, the level identifier of the target API interface is obtained from the target system's interface management platform before adjusting its level. Based on the level identifier, the current level of the target API interface can be determined. The level corresponding to the level identifier is compared with the currently determined target level to determine whether the current interface level of the target API interface needs to be adjusted.

[0071] This embodiment introduces an interface level adjustment prompt and manual confirmation mechanism. If the level corresponding to the level identifier differs from the currently determined target level, it is determined that the level of the target API interface needs to be adjusted. Based on the target level and the current level of the interface, a corresponding level adjustment instruction is generated to change the interface level and resource allocation. After adjusting the interface level, the level identifier of the target API interface is updated based on the adjusted level (i.e., the target level) and synchronized to the target system's interface management platform. After the API interface level identifier is updated, matching interface resources are allocated to the interface based on the new level identifier.

[0072] Optionally, if it is determined that the level of a target API interface needs to be adjusted, a level adjustment request is first generated based on the target level and the current level of the interface, and displayed on the user interface for the user to view and confirm. After user confirmation, a corresponding level adjustment instruction is generated based on the user confirmation information to perform the interface level adjustment operation and subsequent interface resource allocation. By displaying interface adjustment prompts on the user interface, users can be informed of the level changes of each interface in the system in a timely manner. Furthermore, a manual confirmation mechanism ensures that the level changes of each API interface in the system meet user needs. If the automatic interface leveling is unreasonable, operations and maintenance personnel can stop the interface level adjustment operation through the user interface to maintain the current level and resource configuration of the interface.

[0073] As one embodiment of this application, step S502 specifically includes: S3021: If the target level is higher than the level corresponding to the current level identifier of the API interface, generate a level upgrade instruction for the API interface. S3022: If the target level is lower than the level corresponding to the current level identifier of the API interface, perform the following steps: S30221: Obtain the duration of the state corresponding to the level that the target level is lower than the current level identifier of the API interface, and compare it with the buffer threshold. S30222: If the duration is greater than or equal to the buffer threshold, generate a level downgrade instruction corresponding to the API interface.

[0074] In the above embodiments, if the target level is different from the level corresponding to the current level identifier of the target API interface, it is determined that the current interface level of the target API interface needs to be adjusted. Based on this, a corresponding level adjustment instruction is generated according to the adjustment direction of the interface level, specifically as follows: if the target level is higher than the level corresponding to the current level identifier, it is determined that the target API interface needs to be upgraded, and a level upgrade instruction is generated accordingly; conversely, if the target level is lower than the level corresponding to the current level identifier, it is determined that the target API interface needs to be downgraded, and a level downgrade instruction is generated accordingly.

[0075] To prevent system instability caused by frequent adjustments to interface levels due to short-term traffic fluctuations, this embodiment employs a buffering mechanism. A buffer period is set for level downgrade scenarios, during which the interface importance is continuously monitored to ensure that the downgrade is executed only when the interface importance steadily decreases, avoiding erroneous adjustments due to temporary fluctuations. Specifically, if the target level of the target API interface is higher than the level corresponding to its level identifier, a level up instruction is directly generated. If the target level of the target API interface is lower than the level corresponding to its level identifier, a buffering mechanism is used. If the duration for which the interface is continuously determined to require a level downgrade is greater than or equal to a preset buffer threshold, a level downgrade instruction is generated.

[0076] As one embodiment of this application, after step S5 above, the method further includes: S41: Determine the target sampling frequency of each API interface based on its target level and read / write attributes; Step S1 includes: S11: In the next first sampling period, according to the target sampling frequency of each API interface, obtain the read / write attributes and traffic metrics data of the API interface.

[0077] In one embodiment, target sampling frequencies are pre-set for interfaces with different read / write attributes and different levels. Specifically, for interfaces with the same attribute but different levels, the higher the interface level (priority), the higher the corresponding target sampling frequency. For example, if the interface levels are divided into three levels from high to low: "P0, P1, P2", target sampling frequencies for each of the three levels are pre-set for the read interface group, and target sampling frequencies for each of the three levels are pre-set for the write interface group. After adjusting the API interface level within the current sampling period, the target sampling frequency for the interface in the next sampling period is determined based on the interface's read / write attributes and target level within the current sampling period, thus achieving differentiated sampling for different interfaces.

[0078] It is worth noting that a larger sampling frequency should be used for high-level interfaces (such as P0) to ensure the timeliness and accuracy of interface resource configuration, while a relatively smaller sampling frequency should be used for low-level interfaces (such as P2) to save computing resources and improve the overall resource utilization of the system.

[0079] Based on the same inventive concept, one embodiment of this application provides an API interface processing device. Figure 3 This is a schematic diagram of an API interface processing device 100 according to an embodiment of this application. Figure 3 As shown, the device includes: The data acquisition module 101 is configured to acquire the read / write attributes and traffic metrics of each API interface in the target system within the first time period, based on the first sampling period. The hierarchical module 102 is configured to group each API interface based on the read / write attributes to obtain multiple interface groups; wherein all API interfaces in each interface group have the same read / write attributes; for each interface group, the importance of each API interface in the interface group is determined at least based on traffic indicator data; and the target level corresponding to each API interface is determined based on the hierarchical ratio of the target system and the importance of each API interface in each interface group. The interface configuration module 103 is configured to allocate corresponding interface resources to each API interface based on the target level corresponding to each API interface.

[0080] As one embodiment of this application, the data acquisition module 101 is further configured to acquire a first attribute of the API interface in multiple dimensions; the first attribute of the multiple dimensions includes at least two of the following: data sensitivity, transaction dependency, response error rate, historical traffic peak, interface response latency, and business type; The grading module 102 is configured to determine the importance of each API interface in the interface group based at least on traffic metric data for each interface group, including: obtaining an importance score for the API interface based on the first weight corresponding to each first attribute of each API interface in the interface group and the second weight corresponding to the traffic metric data of the API interface; the higher the importance score, the higher the importance of the API interface.

[0081] As one embodiment of this application, the data acquisition module 101 is further configured to acquire a first attribute of the API interface in multiple dimensions; the first attribute of the multiple dimensions includes at least two of the following: data sensitivity, transaction dependency, response error rate, historical traffic peak, interface response latency, and business type; The hierarchical module 102 is configured to determine the importance of each API interface in each interface group based at least on traffic metric data, including: Based on the first attribute and traffic metric data of each API interface in each interface group, construct the feature vector corresponding to the API interface. The feature vectors corresponding to each API interface are input into the first regression model after training to obtain the importance score of the API interface; the higher the importance score, the higher the importance of the API interface.

[0082] In one embodiment of this application, the apparatus further includes a training module configured to perform the following steps: Obtain the first attribute, traffic metric data, and importance score for each API interface at multiple times within the second time period; For each API interface, based on the first attribute and traffic indicator data of the API interface at each moment in the second time period, the first feature data of the API interface at each moment is constructed. The importance scores of each API interface at each time point in the second time period are used as the first sample labels, and associated with the first feature data at the corresponding time point to obtain training samples. The initial regression model is trained based on all training samples to obtain the first regression model after training.

[0083] As one embodiment of this application, the hierarchical module 102 is configured to determine the target level corresponding to each API interface based on the hierarchical ratio of the target system and the importance of each API interface in each interface group, including: Sort all API interfaces in each interface group in descending order of importance score to obtain the importance ranking result for the interface group; Obtain the initial classification ratio and corresponding fluctuation range of the target system; the initial classification ratio is arranged from high to low, including: a first ratio corresponding to the first level, a second ratio corresponding to the second level, and a third ratio corresponding to the third level; the first ratio is less than the second ratio and the third ratio; Obtain the quality indicator data of each API interface in each interface group within the first time period, including: computing resource utilization, fault response latency, and request response success rate; Based on the quality index data and importance scores of each API interface in each interface group, the grading ratio of the interface group is determined within the fluctuation range of the initial grading ratio. Based on the hierarchical ratio of the interface groups, the importance ranking results of the interface groups are divided to determine the target level corresponding to each API interface.

[0084] In one embodiment of this application, after obtaining the importance score corresponding to the API interface, the grading module 102 is further configured to perform the following steps: Obtain the first attribute and traffic indicator data of the API interface in the current first sampling period, and construct the corresponding time-series features; The time-series features are input into a pre-trained second prediction model, which then generates a rolling trend of the importance fluctuation of the API interface in the next sampling period. The importance fluctuation trend can be: rising, stable, or falling. Based on the fluctuation trend of the importance of each API interface in the next sampling period, determine the corresponding fluctuation weight; The importance score of each API interface is updated based on the fluctuation weight of each API interface. The interface configuration module 103 is configured to determine the target level of each API interface based on the hierarchical ratio of the target system and the importance of each API interface in each interface group, including: determining the target level of each API interface based on the updated importance score of each API interface and the hierarchical ratio of the target system.

[0085] As one embodiment of this application, before allocating corresponding interface resources to the API interface based on the target level corresponding to each API interface, the interface configuration module 103 is further configured to perform the following steps: Obtain the level identifier of the API interface, and compare the level corresponding to the level identifier with the target level; If the target level is different from the level corresponding to the level identifier, a level adjustment instruction corresponding to the API interface is generated. Based on the level adjustment instruction, the level identifier of the API interface is updated to the level identifier corresponding to the target level; The interface configuration module 103 is configured to allocate corresponding interface resources to the API interface based on the target level corresponding to each API interface, including: allocating matching interface resources to the API interface based on the updated level identifier of the API interface.

[0086] As one embodiment of this application, the interface configuration module 103 is configured to generate a level adjustment instruction corresponding to the API interface when the target level is different from the level corresponding to the level identifier, specifically including: If the target level is higher than the level corresponding to the current level identifier of the API interface, generate an upgrade instruction for the corresponding API interface. If the target level is lower than the level corresponding to the current level identifier of the API interface, perform the following steps: Obtain the duration of the state corresponding to the level that the target level is lower than the current level identifier of the API interface, and compare it with the buffer threshold. If the duration is greater than or equal to the buffer threshold, a level downgrade instruction corresponding to the API interface is generated.

[0087] As one embodiment of this application, after allocating corresponding interface resources to the API interface based on the target level corresponding to each API interface, the interface configuration module 103 is further configured to determine the target sampling frequency of the API interface based on the target level and read / write attributes of each API interface. The data acquisition module 101 is also configured to acquire the read / write attributes and traffic metrics data of each API interface according to the target sampling frequency of each API interface in the next first sampling period.

[0088] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here. The above descriptions are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

[0089] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and components involved are not necessarily essential to this application.

[0090] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0091] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0092] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0093] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0094] Although preferred embodiments of the embodiments of this application have been described, those skilled in the art, once they understand the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, this application is to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of this application.

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

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

Claims

1. An API interface processing method, characterized by, include: Based on the first sampling period, obtain the read / write attributes and traffic metrics of each API interface in the target system within the first time period; Based on the read and write attributes, the API interfaces are grouped to obtain multiple interface groups; wherein all API interfaces within each interface group have the same read and write attributes. For each interface group, the importance of each API interface in the interface group should be determined based on traffic metric data at least. Based on the hierarchical ratio of the target system and the importance of each API interface in each interface group, the target level corresponding to each API interface is determined. Based on the target level corresponding to each API interface, allocate corresponding interface resources to the API interface.

2. The API interface processing method according to claim 1, characterized in that, Also includes: Obtain the first attribute of the API interface from multiple dimensions; the first attribute of the multiple dimensions includes at least two of the following: data sensitivity, transaction dependency, response error rate, historical traffic peak, interface response latency, and business type; For each interface group, the importance of each API interface in the interface group is determined based on traffic metric data, including: obtaining an importance score for the API interface based on the first weight corresponding to each first attribute of each API interface in the interface group and the second weight corresponding to the traffic metric data of the API interface; the higher the importance score, the higher the importance of the API interface.

3. The API interface processing method according to claim 1, characterized in that, Also includes: Obtain the first attribute of the API interface from multiple dimensions; the first attribute of the multiple dimensions includes at least two of the following: data sensitivity, transaction dependency, response error rate, historical traffic peak, interface response latency, and business type; For each interface group, the importance of each API interface within that group should be determined based on traffic metric data, including: Based on the first attribute and traffic metric data of each API interface in each interface group, construct the feature vector corresponding to the API interface. The feature vectors corresponding to each API interface are input into the first regression model after training to obtain the importance score of the API interface; the higher the importance score, the higher the importance of the API interface.

4. The API interface processing method according to claim 3, characterized in that, Before inputting the multi-dimensional feature vectors corresponding to each API interface into the first regression model that has been trained, the following is also included: Obtain the first attribute, traffic metric data, and importance score for each API interface at multiple times within the second time period; For each API interface, based on the first attribute and traffic indicator data of the API interface at each moment in the second time period, the first feature data of the API interface at each moment is constructed. The importance scores of each API interface at each time point in the second time period are used as the first sample labels, and associated with the first feature data at the corresponding time point to obtain training samples. The initial regression model is trained based on all training samples to obtain the first regression model after training.

5. The API interface processing method according to claim 2 or 3, characterized in that, Based on the hierarchical ratio of the target system and the importance of each API interface in each interface group, the target level corresponding to each API interface is determined, including: Sort all API interfaces in each interface group in descending order of importance score to obtain the importance ranking result for the interface group; Obtain the initial classification ratio and corresponding fluctuation range of the target system; the initial classification ratio is arranged from high to low, including: a first ratio corresponding to the first level, a second ratio corresponding to the second level, and a third ratio corresponding to the third level; the first ratio is less than the second ratio and the third ratio; Obtain the quality indicator data of each API interface in each interface group within the first time period, including: computing resource utilization, fault response latency, and request response success rate; Based on the quality index data and importance scores of each API interface in each interface group, the grading ratio of the interface group is determined within the fluctuation range of the initial grading ratio. Based on the hierarchical ratio of the interface groups, the importance ranking results of the interface groups are divided to determine the target level corresponding to each API interface.

6. The API interface processing method according to claim 2 or 3, characterized in that, After obtaining the importance score corresponding to the API interface, the following is also included: Obtain the first attribute and traffic indicator data of the API interface in the current first sampling period, and construct the corresponding time-series features; The time-series features are input into a pre-trained second prediction model, which then generates a rolling trend of the importance fluctuation of the API interface in the next sampling period. The importance fluctuation trend is either increasing, stable, or decreasing. Based on the fluctuation trend of the importance of each API interface in the next sampling period, determine the corresponding fluctuation weight; The importance score of each API interface is updated based on the fluctuation weight of each API interface. Based on the grading ratio of the target system and the importance of each API interface in each interface group, the target level corresponding to each API interface is determined, including: determining the target level corresponding to each API interface based on the updated importance score of each API interface and the grading ratio of the target system.

7. The API interface processing method according to claim 1, characterized in that, Before allocating corresponding interface resources to the API interface based on the target level corresponding to each API interface, the process also includes: Obtain the level identifier of the API interface, and compare the level corresponding to the level identifier with the target level; If the target level is different from the level corresponding to the level identifier, a level adjustment instruction corresponding to the API interface is generated. Based on the level adjustment instruction, the level identifier of the API interface is updated to the level identifier corresponding to the target level; Based on the target level corresponding to each API interface, allocate corresponding interface resources to the API interface, including: based on the updated level identifier of the API interface, allocate interface resources to the API interface that match the target level.

8. The API interface processing method according to claim 7, characterized in that, If the target level is different from the level corresponding to the level identifier, generate a level adjustment instruction corresponding to the API interface, including: If the target level is higher than the level corresponding to the current level identifier of the API interface, generate an upgrade instruction for the corresponding API interface. If the target level is lower than the level corresponding to the current level identifier of the API interface, perform the following steps: Obtain the duration of the state corresponding to the level that the target level is lower than the current level identifier of the API interface, and compare it with the buffer threshold. If the duration is greater than or equal to the buffer threshold, a level downgrade instruction corresponding to the API interface is generated.

9. The API interface processing method according to claim 1, characterized in that, After allocating corresponding interface resources to the API interfaces based on the target level for each API interface, the process also includes: The target sampling frequency of each API interface is determined based on its target level and read / write attributes. Based on the first sampling period, the read / write attributes and traffic metrics data of each API interface in the target system within the first time period are obtained, including: in the next first sampling period, the read / write attributes and traffic metrics data of the API interface are obtained according to the target sampling frequency of each API interface.

10. The API interface processing method according to any one of claims 1-3, characterized in that, The traffic metrics data include at least one of the following: peak request traffic, average request traffic; and / or The interface resources include: computing resources, testing resources, and operation and maintenance resources.

11. An API interface processing device, characterized in that, For performing the method as described in any one of claims 1-10, comprising: The data acquisition module is configured to acquire read / write attributes and traffic metrics data of each API interface in the target system within the first time period, based on the first sampling period. The hierarchical module is configured to group each API interface based on the read / write attributes to obtain multiple interface groups; wherein all API interfaces in each interface group have the same read / write attributes; for each interface group, the importance of each API interface in the interface group is determined at least based on traffic metric data; based on the hierarchical ratio of the target system and the importance of each API interface in each interface group, the target level corresponding to each API interface is determined; The interface configuration module is configured to allocate corresponding interface resources to each API interface based on the target level corresponding to each API interface.

Images