Application programming interface (API) governance method, apparatus, device, and program product

Abstract

The present disclosure provides an application programming interface (API) governance method, device, equipment and program product, and relates to the technical field of software development. The API governance method comprises: generating a target API based on a data configuration request, the target API being used to provide a data query service corresponding to the data configuration request; generating a permission identifier corresponding to an application request of the target API in response to the application request; the application request at least comprising a first request party identifier and a target API identifier corresponding to the target API, the permission identifier being used to mark the calling permission of the target API of a first request party with the first request party identifier; verifying based on the permission identifier in response to a calling request of the target API, the calling request at least comprising the target API identifier and the permission identifier, and providing the data query service based on the target API after the verification is passed. The whole process management of the API from generation, permission application to calling can be realized.

Description

Technical Field

[0001] This specification relates to the field of software development technology, and in particular to an application programming interface (API) management method, apparatus, computer device, computer-readable storage medium, and computer program product. Background Technology

[0002] An API (Application Programming Interface) is a set of predefined functions provided by a computer operating system or library for applications to call and use. It provides applications and developers with the ability to access a set of routines based on software or hardware. In the era of big data-driven business, APIs serve as the carriers of data value output, and their governance efficiency and stability determine the speed of business iteration. Because APIs are scattered across different teams, records are generally fragmented, and different teams may repeatedly develop APIs with the same functionality, resulting in wasted resources and low efficiency in providing data query services via APIs. Furthermore, API access permissions are usually implemented using IP (Internet Protocol) whitelists, making fine-grained management of API calls impossible and potentially leading to excessive data scraping or malicious attacks.

[0003] In view of this, some embodiments of this specification provide an application programming interface (API) management method, apparatus, computer device, computer-readable storage medium, and computer program product, with the aim of realizing full-process management of APIs from generation and permission application to invocation. Summary of the Invention

[0004] This specification provides one or more embodiments of an application programming interface (API) governance method, the method comprising: generating a target API based on a data configuration request, the target API being used to provide a data query service corresponding to the data configuration request; generating a permission identifier corresponding to the request in response to a request for the target API; the request for the request including at least a first requester identifier and a target API identifier corresponding to the target API, the permission identifier being used to mark the first requester with the first requester identifier's permission to call the target API; and, in response to a call request for the target API, the call request including at least the target API identifier and the permission identifier, performing verification based on the permission identifier, and providing a data query service based on the target API after successful verification.

[0005] According to one or more embodiments of this specification, the method automatically converts first data into second data based on a data configuration request; the second data is obtained by processing the first data; verification is performed based on an authorization identifier, and a data query service is provided based on a target API after successful verification, including: obtaining a second requester identifier corresponding to the call request; if the first requester identifier corresponding to the authorization identifier is consistent with the second requester identifier, then querying the corresponding second data through the target API; the first data is stored in a first data table, and the second data is stored in a second data table; the data configuration request includes at least one of a data scenario and a data model definition; the data model definition includes at least one of a data source, a query indicator, and a query dimension; automatically converting the first data into second data based on the data configuration request includes: determining a target database based on the data scenario, creating a second data table in the target database, querying data using a target query engine in the target database, and the data query speed of the target database being faster than that of the database storing the first data table; automatically obtaining the first data from the first data table for processing based on the data model definition, and writing the processed second data into the second data table.

[0006] According to one or more embodiments of this specification, the data configuration request further includes an interface definition, which includes at least one of request parameters, return parameters, and pagination logic. The request parameters correspond to query dimensions, the return parameters correspond to query dimensions and query metrics, and the pagination logic is used to indicate the data return rules. Based on the data configuration request, a target API is generated, including: generating the target API based on the data scenario and the interface definition, and configuring the call request of the target API to be routed to the target query engine to perform data query in the target database.

[0007] According to the method provided in one or more embodiments of this specification, the data configuration request is automatically generated through an API generation model, and / or the data configuration request is generated based on configuration parameters automatically recommended by the API generation model.

[0008] According to one or more embodiments of this specification, the data scenario includes at least one of an online scenario and an analysis scenario. The method further includes: configuring an online service gateway and an analysis service gateway according to the data scenario; registering a target API corresponding to the online scenario to the online service gateway; and registering a target API corresponding to the analysis scenario to the analysis service gateway.

[0009] According to one or more embodiments of this specification, in response to a request for a target API, a permission identifier corresponding to the request is generated, including: generating an authorization identifier based on a first requester identifier; generating an API call identifier based on the first requester's single call permission to the target API; and generating a permission identifier based on the authorization identifier and the API call identifier.

[0010] According to one or more embodiments of this specification, the application request further includes a unit time query rate limit; the method further includes: obtaining the unit time query rate limit in the application request, storing the mapping relationship between the unit time query rate limit and the API call identifier; providing data query services based on the target API, including: determining whether the unit time query rate during the query exceeds the unit time query rate limit, and limiting the rate of the portion exceeding the unit time query rate limit.

[0011] According to one or more embodiments of this specification, the method further includes: performing first monitoring on the amount of data transposed from first data to second data; performing second monitoring on the query rate per unit time of the target API; and pushing alarm information when the first monitoring and / or the second monitoring detects an anomaly.

[0012] According to one or more embodiments of this specification, the method for automatically converting first data into second data includes: partitioning the first data according to the data acquisition time based on a preset period, so that the data acquisition time of the first data in each partition is within the same preset period; converting the first data in each partition into second data based on the order of data acquisition time, and recording the data conversion status corresponding to the partition, the data conversion status including ready and not ready; the call request also includes a first data deadline, and querying the corresponding second data through the target API, including: when the data conversion status of the first target partition where the first data deadline is located is not ready, obtaining the second target partition with a data conversion status of ready and corresponding to the latest data acquisition time; updating the first data deadline in the call request to the second data deadline corresponding to the second target partition; and querying the second data corresponding to the second data deadline through the target API based on the updated call request.

[0013] According to one or more embodiments of this specification, the method further includes: updating the target API, identifying the latest version of the target API as the online target API, and identifying the non-latest version of the target API as the historical target API; responding to application requests through the online target API; and continuing to provide services for existing call requests through the historical target API.

[0014] According to one or more embodiments of this specification, the method further includes: deleting historical target APIs that meet preset conditions; the preset conditions include that the query task calling the historical target API has no traffic within a preset time period and / or receiving confirmation deletion feedback from the requester calling the historical target API; and deleting the second data that has been transcribed corresponding to the historical target API.

[0015] According to one or more embodiments of this specification, the method further includes: in response to a call request from at least two target APIs, combining the at least two target APIs into a composite API according to a preset logic; the composite API has a composite API identifier, and the composite API is used to provide data query services corresponding to the at least two target APIs according to the preset logic; the preset logic includes at least one of serial, parallel, and aggregation.

[0016] One or more embodiments of this specification also provide an application programming interface (API) management device, the device comprising: an API generation module, configured to generate a target API based on a data configuration request, the target API being used to provide a data query service corresponding to the data configuration request; an API application module, configured to generate a permission identifier corresponding to the application request in response to the application request for the target API; the application request includes at least a first requester identifier and a target API identifier corresponding to the target API, the permission identifier being used to mark the first requester with the first requester identifier's calling permission to the target API; and an API calling module, configured to respond to a calling request for the target API, the calling request including at least the target API identifier and the permission identifier, verify based on the permission identifier, and provide a data query service based on the target API after successful verification.

[0017] One or more embodiments of this specification also provide a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it is able to implement the application programming interface (API) management method described in some embodiments of this specification.

[0018] One or more embodiments of this specification also provide a computer-readable storage medium storing computer instructions that, when executed by a processor, can implement the application programming interface (API) management method described in some embodiments of this specification.

[0019] One or more embodiments of this specification also provide a computer program product, including a computer program that, when at least a portion of the computer program is executed by a processor, can implement the application programming interface (API) management method described in some embodiments of this specification.

[0020] The effective effects that the embodiments in this specification may bring include, but are not limited to: automatically generating target APIs based on data configuration requests, eliminating the need for manual coding by users and improving the efficiency of API generation; generating permission identifiers corresponding to the first requester's identifier in response to the application request of the target API; providing data query services through the target API after verification based on the permission identifier in response to the call request of the target API; and securely reusing target APIs already generated by one party for multiple parties, avoiding redundant development of target APIs and isolating the call process of each target API, thereby clarifying the upstream and downstream relationships of the target APIs. It is possible to understand the data source and caller of the target API through data lineage analysis, which is conducive to troubleshooting and collaboratively completing the governance of the target API, and realizing the whole process governance from API generation, permission application to call.

[0021] By automatically rewriting the first data into the second data based on the data configuration request, and calling the target API to query the corresponding second data after the verification is passed, the second data can be effectively queried by directly querying the second data since the second data is processed from the first data. Furthermore, the target database for rewriting can be selected based on the data scenario, and different types of data sources can be supported during data configuration, which can flexibly meet the query needs of different data scenarios.

[0022] By generating target APIs based on data scenarios and interface definitions, the development and delivery time of APIs is shortened. Since the request parameters and return parameters in the interface definition correspond to the query dimensions and query metrics in the data model definition, the generated target APIs can be encapsulated according to the data model configuration, quickly query the target database corresponding to the data scenario, and return the query results according to the pagination logic in the interface definition.

[0023] By automatically generating data configuration requests through API generation models and / or automatically recommending parameters in data configuration requests to generate data configuration requests, the threshold for API generation can be further lowered by leveraging the capabilities of artificial intelligence.

[0024] By registering the target API corresponding to the online scenario to the online service gateway and the target API corresponding to the analysis service to the analysis service gateway, physical isolation between the online service and the analysis service can be achieved, avoiding the situation where the complex queries of the analysis service consume too many resources and cause delays in the current service.

[0025] By generating an authorization identifier based on the first requester's identifier, an API call identifier based on the first requester's single call to the target API, and an access permission identifier based on the authorization identifier and the API call identifier, the generated access permission identifier can not only be used for data access authentication to avoid the risk of data unauthorization, but also distinguish multiple calls to the same target API by the same first requester. This allows for quick identification of the target API and queried data corresponding to the fault through data lineage analysis when an anomaly occurs, reducing the difficulty of fault location.

[0026] By establishing a mapping relationship between the maximum query rate per unit time in the application request and the API call identifier, when the query rate per unit time exceeds the maximum query rate per unit time, the excess portion is rate-limited. This ensures that the requester receives the resource allocation within its authority, guarantees the stability of the entire API service chain, and isolates the traffic and resources required by different requesters when calling the same target API. This allows limiting the traffic or resources of one requester when it exceeds its limit, without affecting other requesters.

[0027] By first monitoring the amount of data rewritten from the first data to the second data, and second monitoring the query rate of the target API per unit time, and by pushing alarm information when anomalies occur, it is possible to achieve monitoring of multiple aspects, including data source monitoring, traffic monitoring during API calls, and timely alarms, to ensure that various anomalies corresponding to the API can be detected in a timely manner.

[0028] By partitioning the first data according to the data collection time based on a preset period, and transcribing the data within each partition according to the order of the data collection time, and recording the data transcribing status of the corresponding partition, when the data transcribing status of the partition corresponding to the first data deadline that the target API call request needs to query is not ready, the system returns the data of the partition whose data transcribing status is ready up to the latest data collection time, and queries are performed based on the data after partition degradation, which can avoid query failures and return the query results of the degraded data.

[0029] By responding to request requests through the online target API, new permission requests and calls to the target API can be executed based on the supported online version. By continuing to provide services for existing call requests through the historical target API, it is possible to support the parallel operation of multiple versions of the target API and ensure that existing call instances can be queried normally.

[0030] By cleaning up historical target APIs that meet preset conditions, we can avoid the accumulation of invalid versions of target APIs, reducing management chaos and resource waste; reducing the number of historical versions of target APIs that require maintenance and monitoring can reduce security vulnerability risks and compatibility issues; by triggering the cleanup of historical target APIs when receiving confirmation of deletion feedback from the party requesting the historical target API, we can leverage the upstream and downstream relationships of historical target APIs to coordinate with the callers to complete the cleanup of idle versions of target APIs, ensuring that the deletion or decommissioning of historical target APIs does not affect the normal use by the callers.

[0031] By combining multiple target APIs into a composite API according to a preset logic, and by implementing the same management method for the composite API as for the target APIs, we can not only handle the complex situation of multiple API combined calls, ensure data consistency and reduce data ambiguity, but also obtain integrated data results from a single call to the composite API, thus lowering the threshold for multiple API combined calls.

[0032] It should be noted that different embodiments may produce different beneficial effects. In different embodiments, the beneficial effects may be any one or a combination of the above, or any other possible beneficial effects. Attached Figure Description

[0033] This specification will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. The same numbers in the drawings denote the same structures or steps.

[0034] Figure 1 This is a schematic diagram illustrating an application scenario of API governance based on some embodiments of this specification.

[0035] Figure 2 This is an exemplary flowchart illustrating an API governance method according to some embodiments of this specification.

[0036] Figure 3 This is an exemplary flowchart of data transcribing according to some embodiments of this specification.

[0037] Figure 4 This is an exemplary flowchart of a scenario-based registration API, as shown in some embodiments of this specification.

[0038] Figure 5 This is an exemplary flowchart of an authorization identifier generated according to some embodiments of this specification.

[0039] Figure 6 This is an exemplary block diagram illustrating an API authentication method according to some embodiments of this specification.

[0040] Figure 7 This is an exemplary flowchart of anomaly monitoring according to some embodiments of this specification.

[0041] Figure 8 This is an exemplary flowchart illustrating a data transcribing method based on data partitioning, according to some embodiments of this specification.

[0042] Figure 9 This is an exemplary flowchart illustrating a data query based on data partitioning, according to some embodiments of this specification.

[0043] Figure 10 This is an exemplary architecture diagram of a data partitioning query according to some embodiments of this specification.

[0044] Figure 11 This is a timing call diagram of a data partition query according to some embodiments of this specification.

[0045] Figure 12 This is an exemplary flowchart illustrating API version management according to some embodiments of this specification.

[0046] Figure 13 This is an exemplary flowchart illustrating another API version management method according to some embodiments of this specification.

[0047] Figure 14 This is an exemplary block diagram illustrating a complete API governance process according to some embodiments of this specification.

[0048] Figure 15 This is an exemplary architecture diagram of data storage according to some embodiments of this specification.

[0049] Figure 16 This is a schematic diagram illustrating a data query based on multi-level storage, according to some embodiments of this specification.

[0050] Figure 17 This is an exemplary block diagram illustrating an API orchestration according to some embodiments of this specification.

[0051] Figure 18 This is an exemplary block diagram of an API management device according to some embodiments of this specification. Detailed Implementation

[0052] To more clearly illustrate the technical solutions of the embodiments in this specification, the embodiments will be described in detail below with reference to the accompanying drawings. Obviously, the content described below are some examples or embodiments of this specification. For those skilled in the art, without creative effort, the technical solutions or means disclosed in this specification can be applied to other scenarios based on this technical content.

[0053] It should be understood that the terms "system," "device," "unit," and / or "module" used in this specification are a method of distinguishing different components, elements, parts, sections, or assemblies at different levels. However, if other terms can achieve the same purpose, they may be replaced by other expressions.

[0054] Unless otherwise specified, the technical terms used to describe components, elements, etc. in this specification are not singular but may include plural. Generally speaking, terms such as "comprising" or "including" only indicate that explicitly identified steps, elements, or components are included, and these steps, elements, and components do not constitute an exclusive list, as the described method or apparatus may also include other steps or components.

[0055] This specification uses flowcharts to illustrate the operational steps performed by the apparatus or system of related embodiments. However, unless otherwise specified, the order in which these steps are described should not be construed as a limitation on the order of execution. Those skilled in the art can adjust the order of these steps based on the knowledge and information conveyed by the embodiments in this specification. Such adjustments include, but are not limited to, reversing the order of steps, merging multiple steps, and splitting a step.

[0056] An API (Application Programming Interface) is a set of predefined functions provided by a computer operating system or library for applications to call and use. It provides applications and developers with the ability to access a set of routines based on software or hardware. In the era of big data-driven business, APIs serve as the carriers of data value output, and their governance efficiency and stability determine the speed of business iteration. Because APIs are scattered across different teams, records are generally fragmented, and different teams may repeatedly develop APIs with the same functionality, resulting in wasted resources and low efficiency in providing data query services via APIs. Furthermore, API access permissions are usually implemented using IP (Internet Protocol) whitelists, making fine-grained management of API calls impossible and potentially leading to excessive data scraping or malicious attacks.

[0057] Therefore, some embodiments of this specification propose an API governance method, apparatus, computer device, computer-readable storage medium, and computer program product, with the aim of realizing full-process management of APIs from generation and permission application to invocation.

[0058] Figure 1 This is a schematic diagram illustrating an application scenario of API governance based on some embodiments of this specification. For example... Figure 1As shown, API governance application scenario 100 may include client 110, server 120, and network 130. Client 110 and server 120 can transmit data through network 130. Client 110 can receive data configuration requests, API application requests, and API call requests generated based on user input. Server 120 can generate APIs in response to client 110's data configuration requests, generate permission identifiers in response to client 110's API application requests, and verify API calls based on permission identifiers in response to client 110, providing data query services based on the API after successful verification.

[0059] In some embodiments, client 110 may include, but is not limited to, terminal devices such as desktop computers, smartphones, laptops, VR devices, tablets, smart TVs, and in-vehicle terminals. Client 110 may include a display screen and a processor. The display screen can be used to present a graphical user interface (GUI), such as a data configuration interface, an API permission request interface, or an API call request interface. In some embodiments, the display screen may be separate from the human-machine interface device (HMI). Users can operate on the GUI through the HMI, and the processor of client 110 can receive operation instructions generated by operations on the GUI through the HMI. For example, the processor can generate data configuration requests, API request requests, and API call requests based on user input. The display screen of client 110 can be used to present response results generated by operation instructions input through the GUI. For example, the display screen can be used to present a data query monitoring interface for API calls or an alarm interface for monitoring anomalies. In some embodiments, the display screen may be a touchscreen, which can receive operation instructions input by the user based on the GUI.

[0060] In some embodiments, server 120 may be a high-performance computer device used to generate APIs in response to data configuration requests from client 110, generate permission identifiers in response to API request requests from client 110, and verify API calls from client 110 based on the permission identifiers, providing data query services based on the APIs after successful verification. In some embodiments, server 120 may include a local server or a cloud server. Depending on different service requirements, local servers or cloud servers corresponding to a given region may be deployed in one or more regions. In some embodiments, server 120 may include a backend processing server. The backend processing server can generate APIs based on data configuration requests, generate permission identifiers based on API request requests, perform permission verification based on API call requests, and provide data query services based on the APIs after successful verification. In some embodiments, server 120 may be a single computer device or a computing cluster composed of multiple computer devices, thereby providing more powerful computing power and more efficient data processing, such as permission verification and data querying. It is understood that in the specific implementation of this specification, the collection, use or processing of data (such as first data, second data) is involved. When one or more embodiments of this specification are applied to the implementation of specific products or technologies, the permission or consent of the data subject is required. The collection, use or processing of related data must strictly comply with the relevant laws, regulations and standards of the relevant countries and regions, such as the data source and implementation location. The de-identification technology ensures that the final data used is the de-identified data that has been securely processed, thereby protecting the rights and interests of the data subject and data security.

[0061] Network 130 can be any type of wired or wireless network, or any combination thereof. As an example, network 130 can be one or more combinations of wired networks, fiber optic networks, telecommunications networks, internal networks, the Internet, local area networks (LANs), wide area networks (WANs), wireless local area networks (WLANs), metropolitan area networks (MANs), public switched telephone networks (PSTNs), Bluetooth networks, etc. Network 130 can have multiple access points, through which client 110 and server 120 can access network 130.

[0062] It should be noted that, Figure 1 The illustrated application scenario diagram of API governance is merely an example. The application scenarios of API governance described in the embodiments of this specification are intended to more clearly illustrate the technical solutions of the embodiments of this specification and do not constitute a limitation on the technical solutions provided in the embodiments of this specification. For example, Figure 1The number of client 110 and server 120 is merely illustrative and is not intended to limit the scope of patent protection of this application. Depending on the actual situation, there can be any number of client 110 and server 120. As will be apparent to those skilled in the art, with the development of data processing technology and the emergence of new business scenarios, the technical solutions provided in the embodiments of this specification are also applicable to similar technical problems.

[0063] To govern APIs, this specification provides an API governance method. Figure 2 This is an exemplary flowchart illustrating an API governance method according to some embodiments of this specification. Figure 2 The process 200 shown can be executed by a processing device, for example, by... Figure 1 The server 120 shown executes the process. In some embodiments, process 200 may be implemented by an API governance device 1800 deployed on a processing device. The API governance device 1800 may include an API generation module 1810, an API request module 1820, and an API invocation module 1830. Figure 2 As shown, in some embodiments, process 200 may include the following steps.

[0064] Step 210: Based on the data configuration request, generate a target API. The target API is used to provide data query services corresponding to the data configuration request. In some embodiments, step 210 can be implemented by the API generation module 1810.

[0065] In some embodiments, a data configuration request may include at least one of a data scenario, a data model definition, and an interface definition. In some embodiments, a data scenario is used to distinguish the scenario in which the data is generated or applied. In some embodiments, a data model definition may include at least one of a data source, a query metric, and a query dimension. The data source can indicate the location of data storage, typically represented by the physical table name or storage location; the query dimension can refer to the angle from which data is observed or analyzed, typically a textual or discrete field, such as region, time, or channel; the query metric can refer to the business metric that needs to be calculated, typically a numerical field, which can be obtained through some statistical method or aggregation function, such as daily active users or number of orders. In some embodiments, an interface definition may include at least one of request parameters, return parameters, and pagination logic. Request parameters correspond to query dimensions, return parameters correspond to query dimensions and query metrics, and pagination logic indicates the rules for returning data; for example, the returned data may be sorted forward or backward based on an identifier or a field.

[0066] In some embodiments, during the API generation phase, the target API generated based on the data configuration request can obtain data from the data source based on a specific query dimension, calculate the metric corresponding to the query indicator, and return the query results according to a preset pagination logic. In some embodiments, the client 110 can provide a visual data configuration interface for users requesting API generation (e.g., API producers) to configure data. For example, it can provide fields that users can fill in and define, such as data source, query indicator, query dimension, return parameters, and pagination logic. The client 110 generates a data configuration request based on the user's input, and the server 120 can automatically generate the target API according to the data configuration request without requiring manual coding by the user. Through explicit data configuration requests and automatically generated target APIs, the data source corresponding to the data query service provided by the target API can be recorded, the data lineage can be clarified, the efficiency of API generation can be improved, data consistency can be ensured, and data ambiguity in business decisions can be avoided.

[0067] Step 220: In response to the request for the target API, generate a permission identifier corresponding to the request. The request includes at least a first requester identifier and a target API identifier corresponding to the target API. The permission identifier is used to mark the first requester's access permission to call the target API. In some embodiments, step 220 can be implemented by the API request module 1820.

[0068] In some embodiments, during the API usage phase, secure reuse and isolation of the API can be achieved through a tenant model. For a produced API, a tenant (the first requester wanting to use the target API, such as the API user) can apply for usage rights to the target API through client 110. In some embodiments, the target API has a unique target API identifier after generation, which is used to distinguish different APIs. In some embodiments, client 110 can provide the tenant with a target API application interface in a visual manner. For example, the application interface may include fields such as the name of the target API, a functional description, the target API identifier, and the first requester identifier, where the target API identifier corresponds to the name and functional description of the target API. Client 110 can generate a target API application request based on the target API identifier and the first requester identifier. Server 120 can determine the target API that the tenant wants to use based on the target API identifier, generate a unique permission identifier based on the first requester identifier, and bind it to the target API identifier. In some embodiments, server 120 can return the permission identifier as a response result of the target API application request to the visual interface of client 110.

[0069] By requesting permissions for existing target APIs, users can directly request to use the target API based on the same data requirements. This not only avoids redundant API code development and simplifies the interface development process of the data warehouse, but also unifies the data standards for the same data requirements. By assigning permission identifiers to the first requester requesting to use the target API, the data acquisition permission can be bound to the first requester, preventing unauthorized parties from accessing data outside their permissions, thereby achieving secure reuse of the target API.

[0070] Step 230: In response to a call request from the target API, which includes at least a target API identifier and a permission identifier, verification is performed based on the permission identifier, and a data query service is provided based on the target API after successful verification. In some embodiments, step 230 can be implemented by the API call module 1830.

[0071] In some embodiments, when a tenant wants to call a target API to perform a data query, the tenant client can initiate a call request to the target API based on the obtained permission identifier. In some embodiments, the client 110 can provide a visual API call interface, for example, the API call interface may include fields for the target API identifier and the permission identifier. After receiving the target API identifier and the permission identifier filled in by the tenant, the client 110 initiates a call request to the target API based on the target API identifier and the permission identifier. After receiving the call request, the server 120 can verify whether the caller has the right to call the target API based on the permission identifier. If the verification is successful, the server can provide a data query service based on the target API and use the data query result as the response result of the call request to the target API. In some embodiments, the tenant client can record the obtained permission identifier. When the tenant client needs to call the target API, it can obtain the recorded permission identifier and automatically fill in the fields for the permission identifier, or it can automatically obtain the recorded permission identifier and directly initiate a call request to the target API.

[0072] In some embodiments, the request for and the call request for the target API can be initiated consecutively. For example, client 110 can automatically redirect to the API call interface after receiving the permission identifier from server 120, based on user settings, and initiate a call request for the target API based on the permission identifier. In some embodiments, the request for and the call request for the target API can be initiated separately. For example, the tenant client records the feedback permission identifier, and when the target API needs to be called, the tenant client initiates a call request for the target API in client 110 based on the recorded permission identifier. By issuing and verifying permission identifiers, the caller of the target API can be identified, which is beneficial for identifying the caller of the target API through data lineage analysis, clarifying the upstream and downstream relationships of each target API, and facilitating collaboration and feedback in the subsequent API governance process.

[0073] In one or more embodiments of this specification, target APIs are automatically generated based on data configuration requests, eliminating the need for manual coding by users and improving API generation efficiency. By generating a permission identifier corresponding to the first requester's identifier in response to the target API's request, and by providing data query services through the target API after successful verification based on the permission identifier in response to the target API's call request, target APIs that have already been generated by one party can be securely reused by multiple parties, avoiding redundant development of the target API. Furthermore, the call processes of each target API are isolated, thereby clarifying the upstream and downstream relationships of the target APIs. Data lineage analysis can be used to understand the data source and caller of the target API, facilitating problem identification and collaborative governance of the target API, and achieving end-to-end governance from API generation and permission application to call.

[0074] In some embodiments, the API governance method may further include: automatically transcribing first data into second data based on a data configuration request, wherein the second data is obtained by processing the first data.

[0075] In some embodiments, the first data can be massive amounts of raw data, such as data in Hive or Iceberg tables. Hive and Iceberg are used for storing and managing massive amounts of data. Hive is a data warehouse analysis system built on a distributed system infrastructure, providing rich SQL (Structured Query Language) query methods to analyze data stored in the distributed system. It can map structured data files to database tables and provide complete SQL query functionality. Iceberg is an open-source table format designed for large-scale data analysis, providing efficient data management capabilities. Querying the first data requires a query engine (such as Spark) to directly read massive files from the storage layer, resulting in low query efficiency, especially unsuitable for online queries requiring low latency and high concurrency. Therefore, it is necessary to process the first data to obtain second data to improve data query speed.

[0076] In some embodiments, to improve data query speed, the data source can be configured during the target API generation stage to perform calculations or processing on the original data (first data) to obtain transcribed aggregated data (second data). The target API can query the transcribed second data to adapt to different data scenarios and reduce query response time. In some embodiments, the server 120 can automatically generate data cleaning SQL statements based on the transcription requirements. The data cleaning SQL statements correspond to the data model, and a data synchronization task (DataPipeline) is automatically created simultaneously.

[0077] In some embodiments, the second data can be pre-processed and calculated from the original and detailed data in the first data according to business requirements (such as query metrics and query dimensions in the data model definition), and stored in a dedicated database suitable for different data scenarios. For example, for online service scenarios with high-concurrency point queries, the dedicated database can be a database that supports low-latency random read and write (such as relational database management systems like MySQL). For complex aggregation OLAP (Online Analytical Processing) analysis scenarios, the dedicated database can be a database with a distributed architecture design that supports real-time analysis and efficient querying of massive amounts of data (such as open-source database management systems like ClickHouse). In some embodiments, Iceberg can also be used as a target for transcribing and storing the second data. For example, the first data in the Hive table can be transcribed into the second data in the Iceberg table, which can improve data access efficiency; or, for example, the first data in Iceberg table 1 can be transcribed into the second data in Iceberg table 2, which can cluster and integrate the original scattered data, thereby improving data query efficiency.

[0078] In some embodiments, step 230 may further include: obtaining a second requester identifier corresponding to the call request; if the first requester identifier corresponding to the permission identifier is consistent with the second requester identifier, then querying the corresponding second data through the target API. In some embodiments, the second requester identifier is a unique identifier that cannot be forged and is used to identify the API caller. In some embodiments, the second requester identifier can be automatically obtained through an RPC (Remote Procedure Call) framework to obtain the value of the caller corresponding to the requester in the call request. In some embodiments, the client 110 can automatically add the obtained second requester identifier to the call request of the target API. In some embodiments, the server 120 can determine the first requester identifier corresponding to the permission request based on the permission identifier, verify whether the first requester identifier and the second requester identifier are consistent, and determine whether the second requester with the second requester identifier has the permission to call the target API. In some embodiments, if the first requester identifier and the second requester identifier are consistent, it can be confirmed that the verification has passed, and data query services can be provided through the target API corresponding to the target API identifier in the call request. In some embodiments, since a transcribing task of first data into second data is established based on a data configuration request, the server 120 can configure the query object of the target API generated based on the data configuration request as the second data to improve the data query speed.

[0079] In some embodiments, the first data is stored in a first data table, and the second data is stored in a second data table. Figure 3 This is an exemplary flowchart of data transcribing according to some embodiments of this specification. Figure 3 The process 300 shown can be executed by a processing device, for example, by... Figure 1 The server 120 shown is executed. In some embodiments, process 300 may be a further description of "automatically transcribing first data into second data based on a data configuration request." Figure 3 As shown, in some embodiments, process 300 may include the following steps.

[0080] Step 310: Determine the target database based on the data scenario, create a second data table in the target database, and use the target query engine to query data in the target database. The data query speed of the target database is faster than that of the database storing the first data table.

[0081] In some embodiments, the data scenario may include at least one of an online scenario and an analytical scenario. Different data scenarios have different data query requirements. For example, online scenarios require low-latency responses, while analytical scenarios require complex aggregation computational capabilities. Therefore, determining different target databases for different data scenarios can enable the second data to further meet the corresponding data query requirements. In some embodiments, the target database may be the aforementioned dedicated database, for example, a database that supports low-latency random read / write operations (e.g., relational database management systems such as MySQL) corresponding to online service scenarios, or a database with a distributed architecture design that supports real-time analysis and efficient querying of massive amounts of data (e.g., open-source database management systems such as ClickHouse) corresponding to analytical service scenarios.

[0082] In some embodiments, for different target databases, corresponding target query engines are used to query data. For example, the query engine of a database that supports low-latency random read and write (such as relational database management systems like MySQL) can achieve low-latency random read and write, which matches the characteristics of simple query patterns and high response requirements in online service scenarios. As another example, the query engine of a database with a distributed architecture design that supports real-time analysis and efficient querying of massive amounts of data (such as open-source database management systems like ClickHouse) can achieve high-throughput sequential reading and complex calculations, which matches the characteristics of large data volume and complex queries in analysis service scenarios.

[0083] In some embodiments, since the target database stores second data based on the first data, querying the second data in the target database through the target API is significantly faster than querying and calculating from massive amounts of first data.

[0084] Step 320: Based on the data model definition, automatically retrieve the first data from the first data table, process it, and write the processed second data into the second data table.

[0085] In some embodiments, the data configuration request includes a data model definition, which is used to formally describe the semantics, structure, and statistical rules of the data, and may include at least one of data source, query dimension, and query metric. Based on the data model definition, the first data in the first data table can be processed and integrated according to the requirements of the data model, and the processed second data can be written into a second data table created in the target database. In some embodiments, the call request to the target API can be configured to query the second data table in the target database.

[0086] In one or more embodiments of this specification, first data is automatically converted into second data based on a data configuration request, and the corresponding second data is queried by calling the target API after verification. Since the second data is obtained by processing the first data, directly querying the second data can effectively improve the speed of data query; and by selecting the target database for conversion based on the data scenario, different types of data sources can be supported during data configuration, which can flexibly meet the query needs of different data scenarios.

[0087] In some embodiments, step 210 may further include: generating a target API based on the data scenario and interface definition, wherein the call request of the target API is configured to be routed to the target query engine to perform data query in the target database.

[0088] In some embodiments, the storage location of the transcribed second data differs depending on the data scenario. Therefore, when generating the target API, it is necessary to determine which target database the target API's query object is based on the data scenario.

[0089] In some embodiments, the request parameters and return parameters in the interface definition correspond to the query dimensions and query metrics in the data model definition. Based on the configuration of the data model, a target API with clear request parameters, return parameters, and pagination logic can be encapsulated. The target API generated based on the interface definition can directly return the query metrics corresponding to the query dimension.

[0090] In one or more embodiments of this specification, the development and delivery time of the API is shortened by generating the target API based on the data scenario and interface definition. Since the request parameters and return parameters in the interface definition correspond to the query dimensions and query metrics in the data model definition, the generated target API can be encapsulated according to the configuration of the data model, quickly query the target database corresponding to the data scenario, and return the query results according to the pagination logic in the interface definition.

[0091] In some embodiments, data configuration requests can be automatically generated by an API generation model, and / or, data configuration requests can be generated based on configuration parameters automatically recommended by the API generation model.

[0092] In some embodiments, the API generation model may include an NL2SQL (Natural Language to SQL) model. For example, for a data configuration request automatically generated through the API generation model, relevant personnel can describe their needs in natural language: "To analyze the usage data of business application A, I need an API to query the daily active users (DAU) of mobile users in the past month, in region B, with results grouped by day." The API generation module can identify the data scenario in this statement as the analysis scenario, and the corresponding data source (usage data of business application A), query metric (DAU), query dimensions (time, city, device type), and filtering conditions (time = the past month, city = B, device type = mobile) in the data model definition. The request parameters in the interface definition correspond to the query dimensions, and the return parameters correspond to the query dimensions and query metrics. Based on the identified data scenario, data model definition, and interface definition, a data configuration request can be automatically generated.

[0093] In some embodiments, the API generation model may include a generative model based on a Transformer model or a GNN (Graph Neural Network) model. For example, to automatically recommend configuration parameters in a data configuration request to generate a data configuration request using an API generation model, the corresponding query metrics and query dimensions can be determined based on the request and return parameters of historical APIs. This allows training an API generation model that takes the query metrics as input and the query dimensions as output. For instance, a user might describe the changes in DAU using natural language. The API generation model can identify the query metric (DAU) and then automatically recommend query dimensions (e.g., time, region, device type) for the user to choose from. The user can then select parameters based on the recommended query dimensions, and the API generation model can generate a data configuration request based on the parameters selected by the user.

[0094] In one or more embodiments of this specification, data configuration requests are automatically generated through an API generation model and / or parameters in the data configuration request are automatically recommended through an API generation model to generate the data configuration request. With the help of artificial intelligence, the threshold for API generation can be further reduced.

[0095] In some embodiments, target APIs generated based on different data scenarios can be registered to different gateways. Figure 4 This is an exemplary flowchart of a scenario-based registration API, as shown in some embodiments of this specification. Figure 4 The process 400 shown can be executed by a processing device, for example, by... Figure 1 The server 120 shown is executed. In some embodiments, process 400 may be a further illustration of the API governance approach. Figure 4 As shown, in some embodiments, process 400 may include the following steps.

[0096] Step 410: Configure the online service gateway and the analysis service gateway according to the data scenario.

[0097] In some embodiments, the data scenario may include at least one of an online scenario and an analysis scenario. An online service gateway may be configured for the online scenario, and an analysis service gateway may be configured for the analysis scenario.

[0098] In some embodiments, the online service gateway and the analytics service gateway may be a single gateway. In some embodiments, the online service gateway and the analytics service gateway may be a gateway cluster consisting of multiple gateways to improve the processing capacity for large-scale requests.

[0099] Step 420: Register the target API corresponding to the online scenario to the online service gateway.

[0100] In some embodiments, since the target API is generated based on the data scenario and interface definition, the target API also corresponds to the data scenario. The target API corresponding to the online scenario can be registered to the online service gateway, and the call request for the target API of the online scenario can be automatically routed to the online service gateway.

[0101] Step 430: Register the target API corresponding to the analysis scenario to the analysis service gateway.

[0102] In some embodiments, after registering the target API corresponding to the analysis scenario to the analysis service gateway, the call request for the target API of the analysis scenario can be automatically routed to the analysis service gateway.

[0103] In some embodiments, each target API may include multiple target APIs corresponding to a data scenario. For example, the target APIs may include a first API and a second API, where the first API corresponds to an online scenario and the second API corresponds to an analysis scenario. The first API can be registered to an online service gateway, and the second API can be registered to an analysis service gateway. When initiating an application request and / or a call request, the requester can select a data scenario according to its own needs. Based on the selected data scenario, the server 120 can choose to call either the first API or the second API, routing the call request of the target API to the gateway corresponding to the data scenario, and querying the target database corresponding to the data scenario, thereby ensuring that the generated target API meets the query requirements of different data scenarios.

[0104] In some embodiments, registering the target API corresponding to the online scenario and the target API corresponding to the analysis scenario to different gateways can achieve physical isolation between online services and analysis services, preventing resource contention between them.

[0105] In some embodiments, the server 120 may prioritize scheduling the resources required by the online service, configure higher priority for scheduling the target API corresponding to the online service, limit the concurrency and resource quota of the analysis service, and avoid the complex queries of the analysis service from causing delays to the online service.

[0106] In one or more embodiments of this specification, by registering the target API corresponding to the online scenario to the online service gateway and the target API corresponding to the analysis service to the analysis service gateway, physical isolation between the online service and the analysis service can be achieved, avoiding the situation where the complex queries of the analysis service consume too many resources and cause delays in the current service.

[0107] In some embodiments, the permission identifier can be used to identify a single-use permission. Figure 5 This is an exemplary flowchart of an authorization identifier generated according to some embodiments of this specification. Figure 5 The process 500 shown can be executed by a processing device, for example, by... Figure 1 The server 120 shown is executed. In some embodiments, process 500 may be a further description of step 220. In some embodiments, process 500 may be implemented by API request module 1820 in API governance device 1800 deployed on processing equipment. Figure 5 As shown, in some embodiments, process 500 may include the following steps.

[0108] Step 510: Generate an authorization identifier based on the first requester identifier.

[0109] In some embodiments, the first requester may include a business service, each business service having a unique service identifier, such as an APP-id (Application Identity), which can serve as the first requester identifier. In some embodiments, the first requester identifier may be manually entered by the tenant when submitting the application request for the target API. In some embodiments, the first requester identifier may be automatically obtained by the client 110 when the tenant submits the application request for the target API.

[0110] In some embodiments, based on the application requests of each target API, an authorization identifier corresponding to the target API identifier can be generated based on the first requester identifier. In some embodiments, the authorization identifier is a long-term authorization credential issued by the target API to the first requester with the first requester identifier, indicating that the first requester has data access rights corresponding to the target API. For example, based on the first requester identifier APP-id-A, an authorization identifier token-A can be generated, where token represents a credential and can be used as a credential for authentication or access control in the form of a random string or encrypted data block.

[0111] Step 520: Generate an API call identifier based on the first requester's single call permission to the target API.

[0112] In some embodiments, the API call identifier can be used to identify a single call instance of the first requester to the target API. In some embodiments, the first requester requests the target API once, and the server 120 generates an API call identifier, such as api-id, based on the first requester's single call permission to the target API. In some embodiments, the first requester may call the same target API multiple times according to different business needs. For each call, the first requester needs to request the use permission of the target API, and the API call identifier corresponding to each call can be unique. Multiple calls of the first requester to the same target API can generate multiple API call identifiers respectively. In some embodiments, for multiple calls of the first requester to the same target API, the authorization identifier remains unchanged, and the API call identifier can be marked in the form of a sequence number to mark a single call. For example, if the first requester with the first requester identifier APP-id-A requests to call the target API for the first time, the authorization identifier is token-A, and the API call identifier is api-A1. If the first requester with the first requester identifier APP-id-A requests to call the target API for the second time, the authorization identifier is token-A, and the API call identifier is api-A2, and so on.

[0113] Step 530: Generate a permission identifier based on the authorization identifier and the API call identifier.

[0114] In some embodiments, the authorization identifier of the same first requester for the same target API remains unchanged, and the API call identifier corresponds to the first requester's single call permission to the target API. An permission identifier is generated based on the authorization identifier and the API call identifier. This not only determines whether the first requester has access permission to the data corresponding to the target API, but also distinguishes multiple calls to the target API by the same first requester, thereby avoiding the risk of data unauthorization. Furthermore, the target API and data corresponding to this call can be quickly located based on the API call identifier, so that the fault location can be quickly located through data lineage analysis when an anomaly occurs.

[0115] In one or more embodiments of this specification, an authorization identifier is generated based on the first requester identifier, an API call identifier is generated based on the first requester's single call to the target API, and an access identifier is generated based on the authorization identifier and the API call identifier. This allows the generated access identifier to not only be used for data access authentication to avoid the risk of data unauthorization, but also to distinguish multiple calls to the same target API by the same first requester. This enables data lineage analysis to quickly determine the target API and queried data corresponding to the fault in the event of an anomaly, reducing the difficulty of fault location.

[0116] In some embodiments, the request may also include a maximum query rate per unit time. In some embodiments, the API governance method may further include: obtaining the maximum query rate per unit time from the request and storing the mapping relationship between the maximum query rate per unit time and the API call identifier. In some embodiments, step 230 may further include: determining whether the query rate per unit time exceeds the maximum query rate per unit time, and rate limiting the portion exceeding the maximum query rate per unit time.

[0117] In some embodiments, the query rate per unit time may include QPS (Queries Per Second), which is a metric used to measure the maximum number of requests an interface can handle within a unit of time (e.g., 1 second), primarily for traffic control. In some embodiments, the target API typically has a total QPS service metric, which corresponds to the maximum throughput limit that the entire service link from the gateway to the database can bear. Setting a total QPS for the target API can prevent unlimited traffic from causing the service link to crash. In some embodiments, since a target API may be called by multiple requesters, the total QPS of the target API corresponds to global resources. For multiple requesters, global resources can be allocated to each requester in the form of quotas. Each requester can apply for a query rate per unit time (QPS cap) limit when making a call. The query rate per unit time limit limit corresponds to the maximum resource quota that the requester can obtain. The sum of the query rate per unit time limits (QPS caps) of all requesters calling the same target API does not exceed the total QPS of the target API, in order to ensure the stability and performance of the service link.

[0118] In some embodiments, when a requester applies for access to a target API, the client 110 can display the field for the maximum query rate per unit time through a visual interface. The client 110 receives the maximum query rate per unit time filled in by the tenant and generates an application request for the target API based on the maximum query rate per unit time, the target API identifier, and the first requester identifier. After generating the API call identifier, the server 120 can bind the maximum query rate per unit time to the API call identifier (or bind it to a permission identifier generated based on the authorization identifier and the API call identifier). This allows the server 120 to query the corresponding maximum query rate per unit time when verifying authorization based on the permission identifier or the API call identifier in the permission identifier. When the actual query rate per unit time corresponding to the requester's call to the target API exceeds the maximum query rate per unit time, the server limits the rate of the excess portion to ensure the orderly allocation of resources and the stability of the service link. In some embodiments, the server 120 can automatically allocate the corresponding maximum query rate per unit time during the permission application stage according to the actual needs of each caller applying for the same target API, and bind the allocated maximum query rate per unit time to the API call identifier (or bind it to a permission identifier generated based on the authorization identifier and the API call identifier). In some embodiments, not only rate limiting parameters can be configured based on each API call identifier, but also personalized parameters such as caching strategies and timeout periods can be configured. When the same target API is called by different requesters, the corresponding traffic and resources can be different, and the traffic and resources between them can be isolated. When the traffic or resources of a requester exceed the limit, only that requester will be restricted, and it will not affect other requesters.

[0119] Figure 6 This is an exemplary block diagram illustrating an API authentication method according to some embodiments of this specification. Figure 6 As shown, in the authentication process 600, the target API (corresponding to...) Figure 6The total QPS of the business API is 100. Business applications A (with identifier APP-id-A), B (with identifier APP-id-B), and C (with identifier APP-id-C) have applied for access to the business API. For example, the business API assigns a permission identifier (including authorization identifier token-A and API call identifier api-A1) to business application A, binding a predetermined QPS (corresponding to a maximum query rate per unit time): 40. When business application A requests a call from the gateway cluster corresponding to the business API using token-A and api-A1, the gateway determines that business application A has the permission to call the business API based on token-A, and determines that the QPS corresponding to this call is 40 based on api-A1. When business application A requests to call the business API with a QPS of 40, the gateway cluster allows the business API to provide data query services to business application A with a QPS of 40. The business API assigns permission identifiers (including authorization identifier token-B and API call identifier api-B1) to business application B, binding a predetermined QPS (corresponding to the maximum query rate per unit time): 30. When business application B requests a call from the gateway cluster corresponding to the business API through token-B and api-B1, the gateway determines that business application B has the permission to call the business API based on token-B, and determines that the QPS corresponding to this call is 30 based on api-B1. When business application B requests to call the business API with a traffic of QPS: 30, the gateway cluster allows the business API to provide data query services to business application B with a traffic of QPS: 30. The business API assigns permission identifiers (including authorization identifier token-C and API call identifier api-C1) to business application C, binding a predetermined QPS (corresponding to a maximum query rate per unit time): 30. When business application C requests a call from the gateway cluster corresponding to the business API using token-C and api-C1, the gateway determines that business application C has the permission to call the business API based on token-C, and determines the QPS corresponding to this call to be 30 based on api-C1. When business application C requests to call the business API with a QPS of 40, the gateway cluster only allows the business API to provide data query services to business application C with a QPS of 30, and rate-limits the portion exceeding 30 QPS. Business application D has not requested permission to use the business API. When business application D requests to call the business API with a QPS of 40 using token-B from the gateway cluster corresponding to the business API, the gateway cluster determines that business application D does not have the permission to call the business API based on token-B and denies business application D's access.

[0120] In some embodiments, target APIs corresponding to online scenarios can be authenticated and rate-limited through an online service gateway, while target APIs corresponding to analytical scenarios can be authenticated and rate-limited through an analytical service gateway.

[0121] In one or more embodiments of this specification, by establishing a mapping relationship between the upper limit of the query rate per unit time in the application request and the API call identifier, when the query rate per unit time exceeds the upper limit of the query rate per unit time, the excess portion is rate-limited. This can ensure that the requester obtains the resource allocation within its authority, guarantee the stability of the entire API service link, and isolate the traffic and resources required by different requesters when calling the same target API. This ensures that when the traffic or resources of one requester exceed the limit, the requester is restricted, without affecting other requesters.

[0122] In some embodiments, data transcribing and API calls can also be monitored, and alerts can be issued when monitoring anomalies occur. Figure 7 This is an exemplary flowchart of anomaly monitoring according to some embodiments of this specification. Figure 7 The process 700 shown can be executed by a processing device, for example, by... Figure 1 The server 120 shown is executed. In some embodiments, process 700 may be a further illustration of the API governance approach. Figure 7 As shown, in some embodiments, process 700 may include the following steps.

[0123] Step 710: Perform the first monitoring on the amount of data transposed from the first data to the second data.

[0124] In some embodiments, the first monitoring is a pre-monitoring mechanism before API calls. By monitoring the amount of data transposed from the first data to the second data, abnormalities in the data source can be detected in a timely manner. For example, the daily data transposition volume is usually around 100. If the data transposition volume decreases significantly on a certain day, or even becomes 0, the server will confirm that the second data transposition is abnormal or the first monitoring has detected an anomaly.

[0125] Step 720: Perform a second monitoring of the query rate per unit time for the target API.

[0126] In some embodiments, the second monitoring is a real-time monitoring mechanism for the target API call. By monitoring the query rate per unit time during the target API call, the traffic changes corresponding to the target API can be detected in a timely manner. When the monitoring detects excessive traffic (e.g., exceeding the predetermined QPS), excessive traffic fluctuations (e.g., QPS suddenly dropping from 40 to 0), abnormal data quality returned (e.g., excessively high null value rate of returned data), excessive return delay (network failure), etc., the server 120 can confirm that the second monitoring has detected the abnormality.

[0127] Step 730: When the first monitoring and / or the second monitoring detects an anomaly, an alarm message is pushed.

[0128] In some embodiments, pushing alarm information is for post-event monitoring after an API call anomaly occurs. When the first monitoring and / or the second monitoring detects any of the aforementioned anomalies, the server 120 can push alarm information to the client 110. In some embodiments, the API can be associated with the contact information of the API producer or caller when it is generated or called, so that alarm information can be pushed through the contact information to provide timely notification when an anomaly occurs.

[0129] In one or more embodiments of this specification, by first monitoring the amount of data transposed from first data to second data, and second monitoring the query rate of the target API per unit time, and by pushing alarm information when abnormal situations occur, it is possible to achieve monitoring in multiple aspects, including data source monitoring, traffic monitoring during API calls, and timely alarms, to ensure that various abnormal situations corresponding to the API can be detected in a timely manner.

[0130] In some embodiments, to avoid situations where no query results are returned when API calls are made, the data can be partitioned and a partitioned degraded query strategy can be adopted. When the data for the required time point cannot be found, the data for the previous time point that can be found will be returned. Figure 8 This is an exemplary flowchart illustrating a data transcribing method based on data partitioning, according to some embodiments of this specification. Figure 8 The process 800 shown can be executed by a processing device, for example, by... Figure 1 The server 120 shown is executed. In some embodiments, process 800 may be a further explanation of "automatically transcribing the first data into the second data." Figure 8 As shown, in some embodiments, process 800 may include the following steps.

[0131] Step 810: Based on a preset period, the first data is partitioned according to the data acquisition time so that the data acquisition time of the first data in each partition is within the same preset period.

[0132] In some embodiments, the first data, as raw data, is typically stored according to the data acquisition time (or the corresponding trigger event occurrence time). By partitioning the first data according to the data acquisition time based on a preset period, massive amounts of raw data can be divided. In some embodiments, the preset period can be set according to actual needs, such as daily, half-day, every two hours, hourly, minutely, etc.

[0133] Step 820: Based on the order of data acquisition time, the first data in each partition is converted into the second data, and the data conversion status corresponding to the partition is recorded. The data conversion status includes ready and not ready.

[0134] In some embodiments, the data of each partition is transcribed based on the order of data acquisition time. After the data in the partition with the earlier data acquisition time has been transcribed, the data in the partition with the later data acquisition time can continue to be transcribed.

[0135] In some embodiments, priorities can be set based on the amount of data in a partition (e.g., there is a large amount of data during periods of high user activity), and the data in each partition can be transcribed based on the priority order.

[0136] Figure 9 This is an exemplary flowchart illustrating a data query based on data partitioning, according to some embodiments of this specification. Figure 9 The process 900 shown can be executed by a processing device, for example, by... Figure 1 The server 120 shown executes this. In some embodiments, process 900 may be a further explanation of step 230. In some embodiments, process 900 may be a further explanation of "querying the corresponding second data through the target API". In some embodiments, process 900 may be implemented by API call module 1830 in API management device 1800 deployed on processing equipment. Figure 9 As shown, in some embodiments, the call request also includes a first data deadline, and process 900 may include the following steps.

[0137] Step 910: When the data rewriting status of the first target partition where the first data deadline is located is not ready, obtain the second target partition whose data rewriting status is ready and which corresponds to the latest data acquisition time.

[0138] In some embodiments, taking a preset period corresponding to each day as an example, the first data deadline in the target API call request is the 20th, the data transfer status of the partition corresponding to the 20th is not ready (not completed), and the data transfer status of the partition corresponding to the 19th is ready (completed). The server 120 can determine that the second target partition with a transfer status of ready and corresponding to the latest data collection time is the partition corresponding to the 19th.

[0139] Step 920: Update the first data deadline in the call request to the second data deadline corresponding to the second target partition.

[0140] In some embodiments, to avoid the target API query failing, a fallback query can be performed on the call request, updating the first data deadline to the second data deadline corresponding to the second target partition. For example, the first data deadline of the 20th in the call request can be replaced with the second data deadline of the 19th.

[0141] Step 930: Based on the updated call request, query the second data corresponding to the second data deadline through the target API.

[0142] In some embodiments, the updated call request can query data up to the ready second target partition, thereby returning a downgraded query result and avoiding a direct query failure. In some embodiments, for the query results of the downgraded query, a partition downgrade flag can be added and fed back along with the returned query results, for example, informing the second data cutoff time corresponding to the downgraded query.

[0143] Figure 10 This is an exemplary architecture diagram of a data partitioning query according to some embodiments of this specification. For example, Figure 10 As shown, in process 1000, the API caller initiates an API call request to the API gateway to query the data corresponding to the API. The partition degradation interceptor intercepts the API call request and checks the parameters in the call request. If the API does not have a degradation policy configured, the query continues normally. If the API has a degradation policy configured, the partition status check component and task scheduling monitoring component in the degradation component determine whether the partition status corresponding to the call request is ready. If it is ready, the query continues normally. If the partition status is not ready, the maximum partition query component determines the maximum ready partition (the partition that is ready and corresponds to the latest data collection time). Based on the maximum partition, the parameters in the call request are replaced, a degradation query is executed, and finally the query results are assembled and returned.

[0144] Figure 11 This is a timing call diagram for a data partition query, as shown in some embodiments of this specification. For example... Figure 11As shown, for example, the preset period for partitions is one hour. In call sequence 1100, the API call request initiated by the caller includes the first data deadline (log_date=20250730, log_hour=10). The API gateway checks the partition (20250730, 10). The status monitoring requests the scheduling system to query the task status (data write status of the partition). The scheduling system returns a status code to the status monitoring: Incomplete (data write status of the partition is not ready). The status monitoring requests the metadata storage to query the maximum partition (the partition that is ready and corresponds to the latest data collection time). The metadata storage returns the maximum partition max (20250730, 09). The status monitoring suggests the API gateway to downgrade the partition (20250730, 09). The API gateway replaces the parameters of the call request based on log_hour=09 and adds a downgrade flag. The API gateway executes the call through the backend service based on the call request after parameter replacement. The backend service returns the data corresponding to the call request. The API gateway returns the query results and downgrade metadata.

[0145] In one or more embodiments of this specification, the first data is partitioned according to the data acquisition time based on a preset period, and the data within the partition is transposed according to the order of the data acquisition time. The data transposition status corresponding to the partition is recorded. When the data transposition status of the partition corresponding to the first data deadline that the target API call request needs to query is not ready, the data of the partition whose data transposition status is ready up to the latest data acquisition time is returned. The query is performed based on the data after partition downgrading, which can avoid query failure and return the query result of the downgraded data.

[0146] In some embodiments, server 120 can also manage API versions. Figure 12 This is an exemplary flowchart illustrating API version management according to some embodiments of this specification. Figure 12 The process 1200 shown can be executed by a processing device, for example, by... Figure 1 The server 120 shown is executed. In some embodiments, process 1200 may be a further illustration of the API governance method. For example... Figure 12 As shown, in some embodiments, process 1200 may include the following steps.

[0147] Step 1210: Update the target API version, designate the latest version of the target API as the online target API, and designate the non-latest version of the target API as the historical target API.

[0148] In some embodiments, for changes in the data model (e.g., changes in dimensions, addition of device types: from the original mobile app to both mobile and tablet), changes in interface compatibility, etc., the target API needs to be updated. The latest version of the target API after the update is the online target API. In some embodiments, for a target API with multiple versions, there is usually only one online version, while historical versions of the target API may have running call instances. To avoid affecting the normal business operations of callers (e.g., business services) that call historical versions, server 120 can support the parallel operation of multiple versions of the target API. In some embodiments, the version of the target API may also be rolled back according to actual needs, and the online target API can be set to the corresponding rolled-back version. Due to the parallel operation of multiple versions, the version upgrade or rollback of the target API does not affect existing call instances.

[0149] Step 1220: Respond to the application request via the online target API.

[0150] In some embodiments, in order to encourage downstream callers to use the supported online version, for newly initiated request requests for the target API, the online target API can respond to the request request and generate a permission identifier corresponding to the online target API.

[0151] Step 1230: Continue to provide services for existing call requests through the historical target API.

[0152] In some embodiments, for call instances based on historical target APIs (corresponding to calls that have already occurred), the historical version of the target API continues to provide services to ensure that the services corresponding to the call instances can function normally.

[0153] In one or more embodiments of this specification, responding to request requests via the online target API can drive new permission requests and calls to the target API to be executed based on the supported online version, continue to provide services for existing call requests via the historical target API, support the parallel operation of multiple versions of the target API, and ensure that existing call instances can be queried normally.

[0154] In some embodiments, server 120 can clean up APIs that have been idle for a long time. Figure 13 This is an exemplary flowchart illustrating another API version management method according to some embodiments of this specification. Figure 13 The process 1300 shown can be executed by a processing device, for example, by... Figure 1 The server 120 shown is executed. In some embodiments, process 1300 may be a further illustration of the API governance approach. Figure 13 As shown, in some embodiments, process 1300 may include the following steps.

[0155] Step 1310: Delete historical target APIs that meet preset conditions; preset conditions include that the query task calling the historical target API has no traffic within a preset time period and / or receives confirmation of deletion feedback from the party that called the historical target API.

[0156] In some embodiments, server 120 can clean up idle historical versions of target APIs. When a historical target API meets preset conditions, the corresponding historical target API can be deleted, reducing the number of versions that need to be maintained, reducing security vulnerability risks and compatibility issues, and freeing up resources.

[0157] In some embodiments, if there is no traffic to the query task of a historical target API within a preset time period, it indicates that the historical target API is idle within the preset time period, which can trigger the server 120 to delete or take the target API offline.

[0158] In some embodiments, callers of certain historical target APIs may set a long return cycle when requesting to call the historical target API (e.g., calling the target API to query once every three months). If the preset duration in the preset conditions is one month, the return cycle set by the caller is longer than the preset duration. Triggering cleanup based on the condition of no traffic within the preset duration may result in misjudgment. Therefore, for call instances with no traffic within the preset duration, it can be confirmed with the corresponding caller whether the target API can be deleted or taken offline. After receiving confirmation of deletion feedback from the caller of the historical target API, the cleanup of the historical target API is triggered. In some embodiments, the server 120 can first clean up each call instance corresponding to the historical target API, and then clean up the historical target API. In some embodiments, the identity of the caller (e.g., APP-id) can be determined based on the call instance of the historical target API, and the caller can be contacted to coordinate the deletion or offline of the historical target API. For call instances that still need to be used, the call instances of the historical target API can be migrated to the online target API, thereby deleting the corresponding call instances on the historical target API.

[0159] Step 1320: Delete the second data that has been transcribed to the historical target API.

[0160] In some embodiments, since some tasks to accelerate queries (such as a transcribing task to convert the first data into the second data) are configured based on the data configuration request at the same time as the target API is generated, the transcribing data and transcribing tasks corresponding to the historical target API are also deleted when the historical target API is deleted, which can further free up resources and storage space.

[0161] In one or more embodiments of this specification, by cleaning up historical target APIs that meet preset conditions, the accumulation of invalid versions of target APIs can be avoided, reducing management chaos and resource waste; reducing the number of historical versions of target APIs that need to be maintained and monitored can reduce security vulnerability risks and compatibility issues; by triggering the cleanup of historical target APIs when receiving confirmation of deletion feedback from the party requesting the historical target API, the upstream and downstream relationships of historical target APIs can be utilized to contact the caller to collaboratively complete the cleanup of idle versions of target APIs, ensuring that the deletion or decommissioning of historical target APIs does not affect the normal business of the caller.

[0162] Figure 14 This is an exemplary block diagram illustrating a complete API governance process according to some embodiments of this specification. Figure 14As shown, the API governance framework 1400 encompasses the entire lifecycle of API governance, including creation / updates, version management, data empowerment, governance advancement, and decommissioning / deletion. During the creation / update phase, API production is achieved by configuring basic information, data scenarios, data sources, and request / return fields, combined with an acceleration engine. In the version management phase, parallel operation of multiple versions is supported. For example, a target API identified as API-X may have four versions: v1 to v4, where v4 is the online version, v1 and v3 are historical versions, and v2 is the decommissioned version. For version management and the acceleration engine (data transcribing), API production logic monitoring and maintenance are configured. During the data empowerment phase, business services apply for API-X usage permissions based on the service identifier APP-id (corresponding to the first requester identifier). For example, business service APP-id-A has applied for usage permissions for API-X version 1. API-X version 1 assigns permission identifiers token-A and api-A1 to business service APP-id-A. Business service APP-id-A applies to call API-X version 1 based on the permission identifiers (token-A and api-A1). Permission identifiers token-A and api-A1 can be used to identify a single call instance of business service APP-id-A to API-X version 1. Business service APP-id-B has also applied for usage permissions for API-X version 1. API-X version 1 assigns permission identifiers token-B and api-B1 to business service APP-id-B. Business service APP-id-B applies to call API-X version 1 based on the permission identifiers (token-A and api-A1). Business service APP-id-B and api-B1 request to call API-X version v1. The permission identifiers token-B and api-B1 can be used to identify a single call instance of business service APP-id-B to API-X version v1. If business service APP-id-A requests permission again after API-X version upgrade, its request is automatically routed to the latest v4 version of API-X. API-X version v4 assigns permission identifiers token-A and api-A2 to business service APP-id-A. Since it is still business service APP-id-A requesting to use API-X, the assigned authorization identifier token-A remains unchanged. However, because business service APP-id-A calls API-X a second time, the API call identifier changes. If multiple calls to API-X by business service APP-id-A are distinguished by sequence number, the API call identifier for the second call could be api-A2. API instance monitoring and maintenance are configured for the target API call phase.During the governance implementation phase, for historical version v3 API-X without downstream applications, when it is detected that the calling instance corresponding to version v3 API-X has no traffic (or no traffic within a predetermined period), the caller can confirm whether the version can be taken offline. After receiving confirmation from the caller, the caller can be notified of the offline time (e.g., officially offline one week later) to allow the caller sufficient time to clean up or migrate related data. During the offline / deletion phase, if API-X needs to be deleted / taken offline, the API instances running on each version of API-X (e.g., corresponding to api-A1, api-B1, api-A2) need to be taken offline / deleted first. Then, the API-X of each version (v1~v4) needs to be taken offline / deleted, and the corresponding task and acceleration table (the corresponding second data table storing the second data) should also be taken offline / deleted. By governing the entire API lifecycle, a complete chain relationship can be built, consisting of an acceleration table (secondary data table), the API (target API), the calling instance (corresponding API call identifier), and the caller (corresponding requester identifier or service identifier, such as APP-id). Based on the upstream and downstream relationships of the API, data lineage analysis can be quickly achieved, faults can be quickly traced and located, the impact of API changes or version upgrades can be significantly reduced, historical versions of APIs can continue to serve existing calling instances, and new application requests can be directed to the latest online version of the API, enabling secure and smooth API upgrades.

[0163] In some embodiments, the target database may include a primary database and a backup database. In some embodiments, the API governance method may further include: storing a second data table simultaneously in both the primary and backup databases; setting the target query engine to query the primary database by default; and setting the target query engine to switch to querying the backup database when the primary database fails. For certain critical APIs, a primary / backup scheme can be configured for the target database and query chain corresponding to the API. For example, the primary link corresponding to the primary database and the backup link corresponding to the backup database can be distributed in different data centers. When the primary link fails, the API can automatically or manually switch to the backup link, thereby improving its ability to handle failures.

[0164] In some embodiments, the second data is configured with a multi-level storage structure including a local cache, a distributed cache, and a target database. In some embodiments, "querying the corresponding second data via the target API" may further include: querying the local cache and the distributed cache sequentially via the target API to see if the corresponding second data is stored; if the corresponding second data is not found in either the local cache or the distributed cache, the call request to the target API is routed to the target query engine; the target query engine queries the target database for the corresponding second data, and the queried second data is written to the local cache and / or the distributed cache.

[0165] Figure 15 This is an exemplary architecture diagram of data storage according to some embodiments of this specification. Figure 15 As shown, in Architecture 1500, the API for online scenarios uses an online service gateway, while the API for analytics scenarios uses an analytics service gateway. By physically isolating the online and analytics services through the gateway, resources are not preempted during queries. Concurrency and resource quotas can be limited for analytics services, while online services can be prioritized for scheduling, preventing a large number of complex queries from impacting online service queries and thus reducing latency. The online or analytics service gateway provides authentication, rate limiting, multi-level caching, and primary / standby fallback functions through modular functional modules. For the multi-level caching module, a multi-level caching mechanism is provided for metadata, including local caching, distributed caching, and database caching. For rate-limited data, database or distributed caching is used for storage.

[0166] Figure 16 This is a schematic diagram illustrating a data query based on multi-level storage, according to some embodiments of this specification. For example... Figure 16 As shown, in the data query framework structure 1600, because the API version and data are cached at multiple levels—local cache, distributed cache, and database—when based on the API (corresponding to... Figure 16 When providing data query services through the API (service interface), the API can first query the local cache. If the data is successfully retrieved, the query result can be returned quickly, achieving nanosecond-level response and adapting to application scenarios with instantaneous traffic spikes. If the data is not found in the local cache, it can query the distributed cache. If the data is successfully retrieved in the distributed cache, the query result can be returned quickly, achieving millisecond-level data hit rate and reducing database load. If the data is also not found in the distributed cache, the API can directly query the database storing metadata (corresponding to...). Figure 16 The query layer (in the database) populates the local cache and / or distributed cache with the query results, ensuring a fast response for subsequent identical query requests. The API versions in the local cache, distributed cache, and database are consistent with the API versions in the version management module. In some embodiments, due to limited storage space in the local cache, an eviction policy can be employed, such as deleting data that has not been queried within a preset time period or data whose query count is less than a threshold within a preset time period. This allows the local cache to store more frequently queried data to meet the demands of fast queries.

[0167] In some embodiments, server 120 can provide flexible API orchestration capabilities for multi-API combined calls. The API governance method may further include: in response to a call request for at least two target APIs, combining the at least two target APIs into a composite API according to preset logic. The composite API has a composite API identifier and is used to provide data query services corresponding to the at least two target APIs according to preset logic.

[0168] In some embodiments, each target API is a pre-generated, independently executable API. Client 110 can use a visual configuration method to request the combination of multiple target APIs into a new, more complex composite API according to preset logic. The composite API has an independent composite API identifier and can be subject to independent permission requests, rate limiting, monitoring, and version management, just like the target APIs. The composite API is integrated by server 120 based on existing target APIs, ensuring that requesters receive consistent data and reducing data ambiguity. Callers can query data through the composite API without needing to concern themselves with the underlying scheduling; a single call yields the integrated result, lowering the barrier to entry for callers using the API.

[0169] In some embodiments, the preset logic includes at least one of serial, parallel, and aggregation logic. For example, based on API1 and API2 combined into a composite API, if API1 and API2 are combined using serial logic, when calling the composite API, the first data corresponding to API1 is queried first, then the second data corresponding to API2 is queried, and then the first and second data are combined as the returned result. For example, data integration in serial logic can be achieved through the union operation, concatenating first and second data with the same or similar structures into a dataset, such as merging real-time data and offline data into a single dataset. If API1 and API2 are combined using parallel logic, when calling the composite API, the first data corresponding to API1 and the second data corresponding to API2 can be queried simultaneously, and then the first data can be combined as the returned result. The first and second data are integrated as the return result. For example, the data in the parallel logic can be joined together using the join operation based on the corresponding fields. For example, push data and click data can be joined together using the user identifier field to obtain the user's push and click data. If API1 and API2 are combined using aggregation logic, when calling the composite API, data statistics can be performed based on the integrated data obtained from the query and according to certain query dimensions through calculation logic. For example, the sum operation can be used to sum the values ​​of a specified field. For example, based on the push and click data connected by the aforementioned join, the data for each day can be grouped by date to calculate the daily push volume and click volume.

[0170] Figure 17 This is an exemplary block diagram illustrating an API orchestration according to some embodiments of this specification. Figure 17 As shown, the API orchestration process 1700 includes three stages: defining basic orchestration information, binding APIs that need to be combined, and configuring the calculation logic between APIs. In the stage of defining basic orchestration information, the request parameters and return parameters of the composite API can be defined. Based on the calling requirements of the composite API, the server 120 maps the fields of the corresponding versions of the APIs that need to be combined, and obtains the composite API required by the composite caller by configuring calculation logic such as serialization, parallelization, and aggregation.

[0171] In one or more embodiments of this specification, by combining multiple target APIs into a composite API according to a preset logic, and by implementing a management method consistent with that of the target APIs for the composite API, it is possible not only to cope with the complex situation of multiple API combined calls, ensure data consistency, and reduce data ambiguity, but also to obtain integrated data results from a single call to the composite API, thereby lowering the threshold for multiple API combined calls.

[0172] This specification also provides an API management device. Figure 18 This is an exemplary block diagram of an API governance apparatus according to some embodiments of this specification. In some embodiments, the API governance apparatus 1800 may be deployed on server 120. Figure 18 As shown, in some embodiments, the API management device 1800 may include an API generation module 1810, an API application module 1820, and an API calling module 1830.

[0173] In some embodiments, the API generation module 1810 is used to generate an API. In some embodiments, the API generation module 1810 is used to generate a target API based on a data configuration request, the target API being used to provide a data query service corresponding to the data configuration request.

[0174] In some optional embodiments, the data configuration request may include at least one of a data scenario, a data model definition, and an interface definition; the data model definition may include at least one of a data source, a query metric, and a query dimension; the interface definition may include at least one of request parameters, return parameters, and pagination logic, where the request parameters correspond to the query dimension, the return parameters correspond to the query dimension and the query metric, and the pagination logic is used to indicate the data return rules. The API generation module 1810 can also be used to generate a target API based on the data scenario and the interface definition, wherein the call request of the target API is configured to be routed to the target query engine for data querying in the target database.

[0175] In some optional embodiments, the API generation module 1810 may also be used to automatically generate a data configuration request through an API generation model, and / or to automatically recommend parameters in the data configuration request through an API generation model to generate a data configuration request; and to generate a target API based on the data configuration request.

[0176] In some embodiments, the API request module 1820 is used to generate a permission identifier. In some embodiments, the API request module 1820 is used to generate a permission identifier corresponding to the request in response to a request for a target API; the request includes at least a first requester identifier and a target API identifier corresponding to the target API, and the permission identifier is used to mark the first requester with the first requester identifier as having the permission to call the target API.

[0177] In some optional embodiments, the API request module 1820 may also be used to generate an authorization identifier based on the first requester identifier; generate an API call identifier based on the first requester's single call permission to the target API; and generate a permission identifier based on the authorization identifier and the API call identifier.

[0178] In some embodiments, the API calling module 1830 is used to call an API to provide a data query service. In some embodiments, the API calling module 1830 is used to respond to a call request for a target API, the call request including at least a target API identifier and a permission identifier, to perform verification based on the permission identifier, and to provide a data query service based on the target API after successful verification.

[0179] In some optional embodiments, the API call module 1830 can also be used to obtain a second requester identifier corresponding to the call request, and if the first requester identifier corresponding to the permission identifier is consistent with the second requester identifier, then query the corresponding second data through the target API.

[0180] In some optional embodiments, the API request may also include a maximum query rate per unit time. The API call module 1830 may also be used to determine whether the query rate per unit time exceeds the maximum query rate per unit time, and if so, to rate-limit the portion exceeding the maximum query rate per unit time.

[0181] For more information on each module, please refer to [link / reference]. Figures 2 to 17 The relevant explanations will not be repeated here. It should be understood that... Figure 18The systems and modules shown can be implemented in various ways. For example, in some embodiments, the systems and modules can be implemented by hardware, software, or a combination of both. The hardware portion can be implemented using dedicated logic; the software portion can be stored in memory and executed by an appropriate instruction execution system, such as a microprocessor or dedicated-design hardware. Those skilled in the art will understand that the methods and systems described above can be implemented using computer-executable instructions and / or included in the control code of a processor, such as on a media such as a disk, CD, or DVD-ROM, or in the memory of a programmable device. The systems and modules of this specification can be implemented not only by hardware circuits such as very large-scale integrated circuits or gate arrays, semiconductors such as logic chips and transistors, or programmable hardware devices such as field-programmable gate arrays and programmable logic devices, but also by software, for example, executed by various types of processors, or by a combination of the aforementioned hardware circuits and software (e.g., firmware).

[0182] It should be noted that the above description of the system and its modules is for convenience only and should not be construed as limiting this specification to the embodiments described. It is understood that those skilled in the art, after understanding the principles of this system, may arbitrarily combine the various modules without departing from these principles to form subsystems connected to other modules. Alternatively, some modules may be split to obtain more modules or multiple units under a single module. Such modifications are all within the scope of this specification.

[0183] Some embodiments of this specification also provide a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it can implement this specification. Figures 2 to 17 The API governance method shown.

[0184] Some embodiments of this specification also provide a computer-readable storage medium storing computer instructions that, when executed by a processor, can implement this specification. Figures 2 to 17 The API governance method shown.

[0185] Some embodiments of this specification also provide a computer program product, including a computer program that, when at least a portion of the computer program is executed by a processor, can implement this specification. Figures 2 to 17The API governance method is illustrated. In some embodiments, the computer program product may refer only to a computer program, which may be carried on a storage medium or a processing device. In other embodiments, the computer program product may also be a storage medium or a processing device containing the aforementioned computer program. The processing device may include one or more processors, and the storage medium.

[0186] In some embodiments, the processor may be a combination of one or more of the following processors: central processing unit (CPU), application-specific integrated circuit (ASIC), application-specific instruction set processor (ASIP), graphics processing unit (GPU), physical processing unit (PPU), digital signal processor (DSP), field-programmable gate array (FPGA), programmable logic device (PLD), programmable logic controller (PLC), reduced instruction set computer (RISC), and microprocessor.

[0187] In some embodiments, the storage medium may include one or more combinations of the following: mass storage, removable storage, volatile read-write memory, and read-only memory (ROM). Exemplary mass storage may include disks, optical disks, solid-state drives, etc. Exemplary removable storage may include flash drives, floppy disks, optical disks, memory cards, compressed hard disks, magnetic tapes, etc. Exemplary volatile read-write memory may include random access memory (RAM). Exemplary RAM may include dynamic random access memory (DRAM), dual data rate synchronous dynamic random access memory (DDRSDRAM), static random access memory (SRAM), silicon controlled retrieval memory (T-RAM), and zero-capacitance memory (Z-RAM), etc. Exemplary read-only memory may include masked read-only memory (MROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), compressed hard disk read-only memory (CD-ROM), and digital multifunction hard disk read-only memory, etc.

[0188] The basic concepts have been described above. It is obvious that the detailed disclosure above is merely illustrative and does not constitute a limitation of this specification. Although not explicitly stated herein, various modifications, improvements, and corrections may be made to this specification by those skilled in the art. Such modifications, improvements, and corrections are taught in this specification and therefore remain within the spirit and scope of the exemplary embodiments described herein.

Claims

1. A method for managing application programming interfaces (APIs), characterized in that, The method includes: Based on the data configuration request, a target API is generated, which is used to provide data query services corresponding to the data configuration request; In response to the request for the target API, a permission identifier corresponding to the request is generated; the request includes at least a first requester identifier and a target API identifier corresponding to the target API, and the permission identifier is used to mark the first requester with the first requester identifier as having the permission to call the target API; In response to a call request to the target API, the call request includes at least the target API identifier and the permission identifier. Verification is performed based on the permission identifier, and the data query service is provided based on the target API after successful verification.

2. The method according to claim 1, characterized in that, The method further includes: automatically transcribing the first data into the second data based on the data configuration request; the second data is obtained by processing the first data; The step of verifying based on the permission identifier and providing the data query service based on the target API after successful verification includes: obtaining a second requester identifier corresponding to the call request; if the first requester identifier corresponding to the permission identifier is consistent with the second requester identifier, then querying the corresponding second data through the target API. The first data is stored in a first data table, and the second data is stored in a second data table; the data configuration request includes at least one of a data scenario and a data model definition; the data model definition includes at least one of a data source, a query metric, and a query dimension; the automatic conversion of the first data into the second data based on the data configuration request includes: Based on the data scenario, a target database is determined, and a second data table is created in the target database. The target database uses a target query engine to query data, and the data query speed of the target database is faster than that of the database storing the first data table. Based on the data model definition, the first data is automatically retrieved from the first data table, processed, and the processed second data is written into the second data table.

3. The method according to claim 2, characterized in that, The data configuration request also includes an interface definition, which includes at least one of request parameters, return parameters, and pagination logic. The request parameters correspond to the query dimension, the return parameters correspond to the query dimension and the query metric, and the pagination logic is used to indicate the data return rules. The process of generating the target API based on the data configuration request includes: The target API is generated based on the data scenario and the interface definition. The call request of the target API is configured to be routed to the target query engine to perform data query in the target database.

4. The method according to claim 3, characterized in that, The data configuration request is automatically generated through the API generation model, and / or the data configuration request is generated based on the configuration parameters automatically recommended by the API generation model.

5. The method according to any one of claims 2 to 4, characterized in that, The data scenario includes at least one of an online scenario and an analysis scenario, and the method further includes: Configure the online service gateway and the analysis service gateway respectively according to the data scenario; Register the target API corresponding to the online scenario to the online service gateway; Register the target API corresponding to the analysis scenario to the analysis service gateway.

6. The method according to any one of claims 2 to 5, characterized in that, The step of generating a permission identifier corresponding to the request in response to the request from the target API includes: Generate an authorization identifier based on the first requester's identifier; An API call identifier is generated based on the first requester's single call permission to the target API; The permission identifier is generated based on the authorization identifier and the API call identifier.

7. The method according to claim 6, characterized in that, The application request also includes a maximum query rate per unit time. The method further includes: Obtain the upper limit of the query rate per unit time in the application request, and store the mapping relationship between the upper limit of the query rate per unit time and the API call identifier; The provision of the data query service based on the target API includes: Determine whether the query rate per unit time exceeds the upper limit of the query rate per unit time, and limit the rate of the portion exceeding the upper limit of the query rate per unit time.

8. The method according to claim 7, characterized in that, The method further includes: The amount of data transposed from the first data to the second data is monitored first. The query rate per unit time of the target API is monitored in a second way; When the first monitoring and / or the second monitoring detects an anomaly, an alarm message is pushed.

9. The method according to any one of claims 2 to 8, characterized in that, The automatic conversion of the first data into the second data includes: Based on a preset period, the first data is partitioned according to the data collection time, so that the data collection time of the first data in each partition is within the same preset period. Based on the chronological order of the data acquisition time, the first data in each partition is transcribed into the second data, and the data transcribing status corresponding to the partition is recorded, including ready and not ready. The call request also includes a first data deadline, and the step of querying the corresponding second data through the target API includes: When the data rewriting status corresponding to the first target partition where the first data deadline is located is not ready, the second target partition whose data rewriting status is ready and which corresponds to the latest data collection time is obtained. Update the first data deadline in the call request to the second data deadline corresponding to the second target partition; Based on the updated call request, the second data corresponding to the second data deadline is queried through the target API.

10. The method according to any one of claims 2 to 9, characterized in that, The method further includes: The target API is updated, and the latest version of the target API is identified as the online target API, while the non-latest version of the target API is identified as the historical target API. The application request is responded to via the online target API; The existing call requests can continue to be served through the historical target API.

11. The method according to claim 10, characterized in that, The method further includes: Delete the historical target API that meets preset conditions; the preset conditions include that the query task calling the historical target API has no traffic within a preset time period and / or receives confirmation of deletion feedback from the requester calling the historical target API; Delete the second data that has been transcribed and corresponds to the historical target API.

12. The method according to any one of claims 1 to 11, characterized in that, The method further includes: In response to a call request from at least two of the target APIs, the at least two target APIs are combined into a composite API according to a preset logic; The composite API has a composite API identifier, and the composite API is used to provide data query services corresponding to the at least two target APIs according to the preset logic; The preset logic includes at least one of series, parallel, and aggregation.

13. An application programming interface (API) management device, characterized in that, The device includes: The API generation module is used to generate a target API based on a data configuration request. The target API is used to provide a data query service corresponding to the data configuration request. The API application module is used to generate a permission identifier corresponding to the application request in response to the application request of the target API; the application request includes at least a first requester identifier and a target API identifier corresponding to the target API, and the permission identifier is used to mark the first requester with the first requester identifier as having the right to call the target API; The API call module is used to respond to the call request of the target API. The call request includes at least the target API identifier and the permission identifier. The module performs verification based on the permission identifier and provides the data query service based on the target API after successful verification.

14. A computer device, characterized in that, The computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it is able to implement the application programming interface (API) governance method as described in any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions, which, when executed by a processor, enable the application programming interface (API) management method as described in any one of claims 1 to 12.

16. A computer program product, characterized in that, The computer program, when at least a portion thereof is executed by a processor, is capable of implementing the application programming interface (API) governance method as described in any one of claims 1 to 12.

Images