Cross-regional API asset management method and device, equipment and storage medium

Abstract

The invention discloses a cross-regional API asset management method and device, equipment and a storage medium. API activity data collected by region collection agents are obtained, each deployment region is provided with a corresponding region collection agent, the API activity data comprises network boundary traffic, DNS analysis records, service registry data, side vehicle agent logs and probe data during application operation, feature vectors representing API interface feature information are extracted from the API activity data, and the feature vectors are used for representing API interface feature information; the feature vectors are identified, APIs corresponding to the API activity data are identified, the APIs are clustered based on the feature vectors, and the APIs of the same type in the deployment areas are managed in a classified mode. A distributed and decentralized API identification mechanism is adopted, cross-regional deployment is supported, the dependence of a gateway is eliminated, the cost is reduced, an API feature modeling method based on multi-source data fusion is adopted, the API identification accuracy is improved, and cross-regional API identification and classified management are supported.

Description

Technical Field

[0001] This invention relates to API management technology, and more particularly to a method, apparatus, device, and storage medium for cross-regional API asset management. Background Technology

[0002] With the widespread adoption of microservice architecture and cloud-native technologies, modern enterprises have deployed a large number of APIs (Application Programming Interfaces) across multiple cloud platforms, multiple virtual private clouds, and different regions for inter-service communication, system integration, and external access.

[0003] However, these API interfaces are highly heterogeneous in terms of deployment location, operating environment, and management methods, making it difficult for enterprises to manage API assets in a unified manner. Summary of the Invention

[0004] This invention provides a cross-regional API asset management method, apparatus, device, and storage medium to support cross-regional API identification and classification management, eliminate gateway dependence, reduce costs, and improve API identification accuracy by adopting a multi-source data fusion API feature modeling method.

[0005] In a first aspect, the present invention provides a cross-regional API asset management method, comprising:

[0006] Obtain API activity data collected by the regional collection agent. Each deployment region is configured with a corresponding regional collection agent. The API activity data includes network boundary traffic, DNS resolution records, service registry data, sidecar agent logs, and application runtime probe data.

[0007] Extract feature vectors representing the characteristics of the API interface from the API activity data;

[0008] The feature vector is identified to determine the API corresponding to the API activity data;

[0009] Based on the feature vectors, the APIs are clustered, and the APIs of the same type in each deployment region are classified and managed.

[0010] Optionally, a feature vector representing the API interface feature information is extracted from the API activity data, including:

[0011] Text data, structured data, and behavioral data are identified from the API activity data;

[0012] The BERT model is used to extract features from the text data to obtain the semantic feature vector of the text data;

[0013] The structured data is embedded to obtain the embedding vector of the structured data;

[0014] The behavioral data is mapped into a fixed-dimensional mapping vector through a fully connected layer;

[0015] By fusing the semantic feature vector, the embedding vector, and the mapping vector, a feature vector representing the feature information of the API interface is obtained.

[0016] Optionally, after determining the text data, structured data, and behavioral data from the API activity data, the method further includes:

[0017] The documents and API call paths in the text data are standardized to remove redundant descriptions;

[0018] The structured data is parsed to convert it into discrete labels;

[0019] The sliding window method was used to calculate the API call frequency and average execution time in the behavioral data.

[0020] The call frequency and the average time consumption are standardized.

[0021] Optionally, clustering is performed on each of the APIs based on the feature vectors, and APIs of the same type in each deployment region are classified and managed, including:

[0022] Select k objects from all feature vectors as initial cluster centers;

[0023] Calculate the distance of other feature vectors to the cluster centers, and assign the feature vectors to the nearest cluster centers to form k clusters;

[0024] Calculate the average vector of all feature vectors in the cluster as the new cluster center;

[0025] Determine whether the new cluster centers are consistent with the previous cluster centers;

[0026] If so, output the clustering results;

[0027] If not, return to the step of calculating the distance of other feature vectors to the cluster center and assigning the feature vectors to the nearest cluster center to form k clusters, until the new cluster center is consistent with the previous cluster center.

[0028] Optionally, after obtaining the API activity data collected by the regional data collection agent, the following may also be included:

[0029] Upload the API activity data to the consortium blockchain.

[0030] Optionally, after identifying the API corresponding to the API activity data by analyzing the feature vector, the method further includes:

[0031] The API is determined to be a genuine API by rule matching. The rules include whether there is a regular call path, whether there is a standardized authentication method, whether there is response data, and whether the API is repeated in multiple calls.

[0032] If the API is not a genuine API, remove the API from the identification results.

[0033] Optionally, after identifying the API corresponding to the API activity data by analyzing the feature vector, the method further includes:

[0034] The entities involved in the call request are determined based on the API call path in the API activity data;

[0035] Using the entities as nodes and the dependencies between the entities as call edges, an API call topology model is constructed.

[0036] Secondly, the present invention also provides a cross-regional API asset management device, comprising:

[0037] The activity data acquisition module is used to acquire API activity data collected by the regional acquisition agent. Each deployment region is equipped with a corresponding regional acquisition agent. The API activity data includes network boundary traffic, DNS resolution records, service registry data, sidecar agent logs, and application runtime probe data.

[0038] The feature vector extraction module is used to extract feature vectors representing the feature information of the API interface from the API activity data;

[0039] The API identification module is used to identify the feature vector and identify the API corresponding to the API activity data;

[0040] The clustering module is used to cluster each of the APIs based on the feature vectors, and to classify and manage APIs of the same type in each of the deployment regions.

[0041] Thirdly, the present invention also provides an electronic device, comprising:

[0042] One or more processors;

[0043] Storage device for storing one or more programs;

[0044] When the one or more programs are executed by the one or more processors, the one or more processors implement the cross-region API asset management method provided in the first aspect of the present invention.

[0045] Fourthly, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the cross-regional API asset management method as provided in the first aspect of the present invention.

[0046] This invention provides a cross-regional API asset management method that acquires API activity data collected by regional acquisition agents. Each deployment region has a corresponding regional acquisition agent. The API activity data includes network boundary traffic, DNS resolution records, service registry data, sidecar agent logs, and application runtime probe data. Feature vectors characterizing API interface features are extracted from the API activity data. These feature vectors are then used to identify the APIs corresponding to the API activity data. Based on the feature vectors, the APIs are clustered, and APIs of the same type in each deployment region are classified and managed. A distributed, decentralized API identification mechanism is adopted, supporting cross-regional deployment, eliminating gateway dependence, and reducing costs. A multi-source data fusion API feature modeling method is used to improve API identification accuracy and support cross-regional API identification and classification management.

[0047] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0049] Figure 1 A flowchart of a cross-regional API asset management method provided by the present invention;

[0050] Figure 2 This invention provides a cross-regional API asset management device;

[0051] Figure 3 This is a schematic diagram of the structure of an electronic device provided by the present invention.

[0052] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0053] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0054] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0055] Currently, common API asset identification and management technologies on the market include:

[0056] 1. Centralized identification solution based on API gateway

[0057] An API gateway can centrally manage all exposed API interfaces, enabling automatic collection, aggregation, and governance. However, this solution relies on enterprises forcing all services to connect to the gateway, and it cannot identify "shadow APIs" that are not connected to the gateway, nor can it identify APIs in intranet services, edge services, or cross-VPC services.

[0058] 2. Service discovery based on service registries (such as Nacos, Consul)

[0059] The service framework registers service metadata (including interfaces) through the registry center, but this method cannot identify unregistered APIs and lacks real-time capability.

[0060] 3. Microservice API Analysis Based on Traffic Mirroring / Sidecar Proxy

[0061] Solutions such as Envoy and Istio extract API paths through traffic monitoring, but they are only applicable to service mesh environments, have complex deployments, and are limited to a single region.

[0062] 4. API documentation platform based on manual registration

[0063] Manually recording data using Swagger, Postman, or API management platforms can lead to issues such as delayed updates and inaccuracies.

[0064] Existing methods are limited to a single VPC or service mesh and cannot cover API assets across network boundaries, data centers, or cloud platforms.

[0065] To address the above problems, this invention provides a cross-regional API asset management method. Figure 1 This is a flowchart illustrating a cross-regional API asset management method provided by the present invention. This embodiment is applicable to the identification and management of APIs deployed across regions within an enterprise. The method can be executed by the cross-regional API asset management device provided by the present invention. This device can be implemented in software and / or hardware, and is typically configured in an electronic device, such as... Figure 1 As shown, this cross-regional API asset management method includes the following steps:

[0066] S101. Obtain API activity data collected by the regional data collection agent.

[0067] In this embodiment of the invention, each deployment region is equipped with a corresponding regional data collection agent to collect API activity data within that deployment region. Each regional data collection agent is communicatively connected to a central identification system, which is used to execute the cross-regional API asset management method of this invention. The deployment region can represent a geographical area, platform, or private service cloud, such as an East China VPC, a North China private cloud, or an edge computing node; this invention does not limit this. API activity data includes network boundary traffic, DNS resolution records, service registry data, sidecar proxy logs, and application runtime probe data; this invention does not limit this. For example, deploying a listener in VPC A resolves the following DNS records:

[0068] api.order.example.com→10.0.1.25

[0069] Meanwhile, the following HTTP calls were captured from the traffic:

[0070] GET / order / detail? id=123HTTP / 1.1

[0071] Host:api.order.example.com

[0072] Regional data collection agents collect this information and upload it to the central identification system.

[0073] In some embodiments of this invention, after acquiring API activity data collected by a regional acquisition agent, the API activity data is uploaded to a consortium blockchain. Leveraging the immutability of the blockchain, on-chain transactions are generated for each API identification and call chain resolution result, enabling cross-entity, cross-regional asset snapshots and audit evidence storage. This step ensures the transparency and credibility of API calls. Through blockchain technology, each API request, response, and identification result is recorded on the chain, forming an immutable transaction history. When disputes arise or audits are required, the on-chain transaction records can be traced to verify the authenticity and integrity of the API calls. Furthermore, the use of a consortium blockchain allows participants to share a trusted record of API calls while maintaining data privacy, promoting cooperation and trust across organizations.

[0074] S102. Extract feature vectors representing API interface features from API activity data.

[0075] In this embodiment of the invention, key information is extracted from the received API activity data, such as request method (e.g., GET, POST, etc.), call path, path parameters, query parameters, header information, authentication method, API version information, etc., and this information can be structured and converted into the following structure:

[0076] {

[0077] "method":"GET";

[0078] "path":" / order / detail";

[0079] "params":["id"];

[0080] "auth":"Token";

[0081] "host":"api.order.example.com";

[0082] }

[0083] Then, a pre-trained feature extraction model is used to extract features from this information, extracting feature vectors that represent the feature information of the API interface from the API activity data.

[0084] In some embodiments of the present invention, the above data can be divided into text data, structured data, and behavioral data, and then feature extraction can be performed on each type of data. Text data may include API description documents and API call paths. Structured data may include call methods, request parameters, response formats, etc. Behavioral data may include call frequency, call duration, etc.

[0085] For example, document and API call paths in text data can be standardized to remove redundant descriptions, such as special characters (e.g., / , ?) in the call paths. Structured data can be parsed to convert it into discrete tags. For example, HTTP methods (GET / POST, etc.), status codes (200 / 404, etc.), and parameter types (string / int, etc.) can be converted into discrete tags. A sliding window method can be used to calculate the API call frequency and average execution time in the behavioral data, and then the call frequency and average execution time can be standardized.

[0086] After the above data processing, the BERT (Bidirectional Encoder Representations from Transformers) model is used to extract features from the text data, obtaining semantic feature vectors. Structured data is then embedded to obtain embedding vectors. Behavioral data is mapped to fixed-dimensional mapping vectors through a fully connected layer. Finally, the semantic feature vectors, embedding vectors, and mapping vectors are fused to obtain feature vectors representing the API interface characteristics.

[0087] The BERT model uses a bidirectional approach, considering both the left and right contexts of word segmentation within a sentence, rather than analyzing the text sequentially. By examining all word segmentations in the sentence simultaneously, it can extract more accurate semantic features. Specifically, the input layer of the BERT model segments the text data into words and performs token embedding operations on these words, converting them into vector representations. The input layer also performs position embedding operations on the word segmentations, converting their positions within the text data into vector representations. All word embedding vectors and position embedding vectors are concatenated according to the word order in the text data. The two concatenated vectors are then aligned and summed at corresponding positions to obtain a fused vector. This fused vector is then input into the encoding layer of the BERT model for encoding. The encoding layer uses a multi-head self-attention mechanism to encode the fused vector, resulting in a semantic feature vector.

[0088] S103. Identify the feature vectors to identify the APIs corresponding to the API activity data.

[0089] In this embodiment of the invention, the feature vector can be input into a fully connected layer for mapping, mapping the feature vector to a spatial dimension with the same number of APIs, and then further mapping it to the probability value of each API through a classification function. Finally, the API corresponding to the highest probability value is taken as the recognition result.

[0090] In some embodiments of the present invention, each API can be dynamically updated and its lifecycle managed. The system supports two update mechanisms:

[0091] Periodic polling scan: Triggers regional agent updates at regular intervals;

[0092] Event-driven: Sensing asset change processes triggered by DNS, registry centers, traffic mutations, etc.

[0093] For example: if a service is detected to be offline from the registry center, immediately mark the API as "pending clearance".

[0094] In some embodiments of the present invention, the identified API, call path, and region affiliation information will be output in the following manner:

[0095] 1. A REST API interface is provided for platform queries;

[0096] 2. A visual interface is used for auditing, governance, and development;

[0097] 3. Report export (PDF, Excel).

[0098] S104. Cluster each API based on feature vectors and classify and manage APIs of the same type in each deployment area.

[0099] In this embodiment of the invention, after identifying the API corresponding to the API activity data, the APIs can be clustered based on feature vectors to group APIs of the same type in each deployment area into one category and manage them accordingly, such as payment APIs, user authentication APIs, etc.

[0100] For example, the API clustering process is as follows:

[0101] 1. Select k objects from all feature vectors as the initial cluster centers.

[0102] For example, k objects are randomly selected from all feature vectors as initial cluster centers.

[0103] 2. Calculate the distance of other feature vectors to the cluster centers, and assign the feature vectors to the nearest cluster centers to form k clusters.

[0104] For example, the cosine distance from other feature vectors to the cluster centers is calculated, and the feature vectors are assigned to the nearest cluster centers to form k clusters.

[0105] 3. Calculate the average vector of all eigenvectors in the cluster as the new cluster center.

[0106] After clusters are formed, the average vector of all eigenvectors in the cluster is calculated as the new cluster center.

[0107] 4. Determine whether the new cluster centers are consistent with the previous cluster centers.

[0108] Determine whether the new cluster centers are consistent with the previous cluster centers.

[0109] 5. If so, stop clustering and output the clustering results.

[0110] 6. If not, return to the step of calculating the distance of other feature vectors to the cluster center and assigning the feature vectors to the nearest cluster center to form k clusters, until the new cluster center is consistent with the previous cluster center.

[0111] In some embodiments of the present invention, after identifying the feature vector and identifying the API corresponding to the API activity data, rule matching can be used to determine whether the API is a real API. The rules include whether there is a regular call path, whether there is a standardized authentication method, whether there is response data, and whether it appears repeatedly in multiple calls. If any of the rules are not met, the API is determined to be not a real API (shadow API), and the API is removed from the identification results.

[0112] In some embodiments of the present invention, after identifying the API corresponding to the API activity data by recognizing the feature vector, the entities involved in the call request can be determined based on the API call path in the API activity data. The entities are used as nodes and the dependencies between entities are used as call edges to construct an API call topology model.

[0113] For example, analyze the "upstream → downstream" call path in the API call request chain to construct an API topology graph:

[0114] Client→API Gateway→Order Service→Payment Service

[0115] Dependencies can be modeled as call edges using distributed tracing or log analysis:

[0116] / order / submit→ / payment / initiate

[0117] The final directed graph structure is used for subsequent analysis.

[0118] This invention provides a cross-regional API asset management method that acquires API activity data collected by regional acquisition agents. Each deployment region has a corresponding regional acquisition agent. The API activity data includes network boundary traffic, DNS resolution records, service registry data, sidecar agent logs, and application runtime probe data. Feature vectors characterizing API interface features are extracted from the API activity data. These feature vectors are then used to identify the APIs corresponding to the API activity data. Based on the feature vectors, the APIs are clustered, and APIs of the same type in each deployment region are classified and managed. A distributed, decentralized API identification mechanism is adopted, supporting cross-regional deployment, eliminating gateway dependence, and reducing costs. A multi-source data fusion API feature modeling method is used to improve API identification accuracy and support cross-regional API identification and classification management.

[0119] Figure 2 The present invention provides a cross-regional API asset management device, such as... Figure 2 As shown, the cross-regional API asset management device includes:

[0120] The activity data acquisition module 201 is used to acquire API activity data collected by the regional acquisition agent. Each deployment region is equipped with a corresponding regional acquisition agent. The API activity data includes network boundary traffic, DNS resolution records, service registry data, sidecar agent logs, and application runtime probe data.

[0121] Feature vector extraction module 202 is used to extract feature vectors representing the feature information of the API interface from the API activity data;

[0122] API recognition module 203 is used to recognize the feature vector and identify the API corresponding to the API activity data;

[0123] Clustering module 204 is used to cluster each of the APIs based on the feature vectors, and to classify and manage APIs of the same type in each of the deployment regions.

[0124] In some embodiments of the present invention, the feature vector extraction module 202 includes:

[0125] The data type determination submodule is used to determine text data, structured data, and behavioral data from the API activity data;

[0126] The semantic feature vector extraction submodule is used to extract features from the text data using the BERT model to obtain the semantic feature vector of the text data;

[0127] An embedding submodule is used to perform embedding processing on the structured data to obtain an embedding vector for the structured data;

[0128] The mapping submodule is used to map the behavioral data into a fixed-dimensional mapping vector through a fully connected layer;

[0129] The vector fusion submodule is used to fuse the semantic feature vector, the embedding vector, and the mapping vector to obtain a feature vector that represents the feature information of the API interface.

[0130] In some embodiments of the present invention, the cross-regional API asset management device further includes:

[0131] The redundancy processing module is used to standardize the documents and API call paths in the text data and remove redundant descriptions after determining the text data, structured data and behavioral data from the API activity data.

[0132] The structured parsing module is used to perform structured parsing on the structured data and convert the structured data into discrete labels.

[0133] The sliding window module is used to calculate the API call frequency and average time consumption in the behavioral data using the sliding window method;

[0134] The standardization processing module is used to standardize the call frequency and the average time consumption.

[0135] In some embodiments of the present invention, the clustering module 204 includes:

[0136] The cluster center initialization submodule is used to select k objects from all feature vectors as initial cluster centers;

[0137] The distance calculation submodule is used to calculate the distance from other feature vectors to the cluster center, and assign the feature vectors to the nearest cluster center to form k clusters;

[0138] The average vector calculation submodule is used to calculate the average vector of all feature vectors in the cluster as the new cluster center;

[0139] The judgment submodule is used to determine whether the new cluster centers are consistent with the previous cluster centers;

[0140] The clustering result output submodule is used to output the clustering result if the clustering result is true.

[0141] Return to the execution submodule, if not, and return to the step of calculating the distance of other feature vectors to the cluster center and assigning the feature vectors to the nearest cluster center to form k clusters, until the new cluster center is consistent with the previous cluster center.

[0142] In some embodiments of the present invention, the cross-regional API asset management device further includes:

[0143] The on-chain module is used to upload the API activity data collected by the regional collection agent to the consortium blockchain.

[0144] In some embodiments of the present invention, the cross-regional API asset management device further includes:

[0145] The rule judgment module is used to identify the API corresponding to the API activity data after identifying the feature vector, and then use rule matching to determine whether the API is a real API. The rules include whether there is a regular call path, whether there is a standardized authentication method, whether there is response data, and whether the API is repeated in multiple calls.

[0146] The API removal module is used to remove the API from the identification results when the API is not a genuine API.

[0147] In some embodiments of the present invention, the cross-regional API asset management device further includes:

[0148] After identifying the feature vector and recognizing the API corresponding to the API activity data, the entity determination module is used to determine the entity involved in the call request based on the API call path in the API activity data.

[0149] The topology building module is used to construct an API call topology model using the entities as nodes and the dependencies between the entities as call edges.

[0150] The aforementioned cross-regional API asset management device can execute the cross-regional API asset management method provided in the foregoing embodiments of the present invention, and has the corresponding functional modules and beneficial effects for executing the cross-regional API asset management method.

[0151] Figure 3This is a schematic diagram of an electronic device provided for an embodiment of the present invention. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0152] like Figure 3 As shown, the electronic device includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded into the RAM 13 from storage unit 18. The RAM 13 can also store various programs and data required for the operation of the electronic device. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0153] Multiple components in the electronic device are connected to the I / O interface 15, including: an input unit 16, such as a keyboard, mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a disk, optical disk, etc.; and a communication unit 19, such as a network card, modem, wireless transceiver, etc. The communication unit 19 allows the electronic device to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0154] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as cross-region API asset management methods.

[0155] In some embodiments, the cross-region API asset management method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on an electronic device via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the cross-region API asset management method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the cross-region API asset management method by any other suitable means (e.g., by means of firmware).

[0156] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0157] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0158] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0159] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0160] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0161] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0162] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the cross-regional API asset management method provided in any embodiment of this application.

[0163] In implementing the computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0164] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0165] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for cross-regional API asset management, characterized in that, include: Obtain API activity data collected by the regional collection agent. Each deployment region is configured with a corresponding regional collection agent. The API activity data includes network boundary traffic, DNS resolution records, service registry data, sidecar agent logs, and application runtime probe data. Extract feature vectors representing the characteristics of the API interface from the API activity data; The feature vector is identified to determine the API corresponding to the API activity data; Based on the feature vectors, the APIs are clustered, and the APIs of the same type in each deployment region are classified and managed.

2. The cross-regional API asset management method according to claim 1, characterized in that, Extracting feature vectors representing the characteristics of the API interface from the API activity data includes: Text data, structured data, and behavioral data are identified from the API activity data; The BERT model is used to extract features from the text data to obtain the semantic feature vector of the text data; The structured data is embedded to obtain the embedding vector of the structured data; The behavioral data is mapped into a fixed-dimensional mapping vector through a fully connected layer; By fusing the semantic feature vector, the embedding vector, and the mapping vector, a feature vector representing the feature information of the API interface is obtained.

3. The cross-regional API asset management method according to claim 2, characterized in that, After identifying text data, structured data, and behavioral data from the API activity data, the process also includes: The documents and API call paths in the text data are standardized to remove redundant descriptions; The structured data is parsed to convert it into discrete labels; The sliding window method was used to calculate the API call frequency and average execution time in the behavioral data. The call frequency and the average time consumption are standardized.

4. The cross-regional API asset management method according to any one of claims 1-3, characterized in that, Clustering of the APIs based on the feature vectors, and classifying and managing APIs of the same type in each deployment region, including: Select k objects from all feature vectors as initial cluster centers; Calculate the distance of other feature vectors to the cluster centers, and assign the feature vectors to the nearest cluster centers to form k clusters; Calculate the average vector of all feature vectors in the cluster as the new cluster center; Determine whether the new cluster centers are consistent with the previous cluster centers; If so, output the clustering results; If not, return to the step of calculating the distance of other feature vectors to the cluster center and assigning the feature vectors to the nearest cluster center to form k clusters, until the new cluster center is consistent with the previous cluster center.

5. The cross-regional API asset management method according to any one of claims 1-3, characterized in that, After obtaining the API activity data collected by the regional data collection agent, the following is also included: Upload the API activity data to the consortium blockchain.

6. The cross-regional API asset management method according to any one of claims 1-3, characterized in that, After identifying the API corresponding to the API activity data by analyzing the feature vector, the process further includes: The API is determined to be a genuine API by rule matching. The rules include whether there is a regular call path, whether there is a standardized authentication method, whether there is response data, and whether the API is repeated in multiple calls. If the API is not a genuine API, remove the API from the identification results.

7. The cross-regional API asset management method according to any one of claims 1-3, characterized in that, After identifying the API corresponding to the API activity data by analyzing the feature vector, the process further includes: The entities involved in the call request are determined based on the API call path in the API activity data; Using the entities as nodes and the dependencies between the entities as call edges, an API call topology model is constructed.

8. A cross-regional API asset management device, characterized in that, include: The activity data acquisition module is used to acquire API activity data collected by the regional acquisition agent. Each deployment region is equipped with a corresponding regional acquisition agent. The API activity data includes network boundary traffic, DNS resolution records, service registry data, sidecar agent logs, and application runtime probe data. The feature vector extraction module is used to extract feature vectors representing the feature information of the API interface from the API activity data; The API identification module is used to identify the feature vector and identify the API corresponding to the API activity data; The clustering module is used to cluster each of the APIs based on the feature vectors, and to classify and manage APIs of the same type in each of the deployment regions.

9. An electronic device, characterized in that, include: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the cross-region API asset management method as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the cross-region API asset management method as described in any one of claims 1-7.

Images