AI-Processing API Version Management and Compatibility Handling Method

Abstract

The present invention discloses an AI - based API version management and compatibility processing method, which relates to the fields of software development and API management, and includes: obtaining API definition documents of multiple versions, and parsing the API definition documents of each version into a structured interface field set; constructing an interface field graph based on the structured interface field set; performing inter - version structure alignment on the interface field graph to generate an interface evolution path graph, where the interface evolution path graph is used to describe the change path of interface fields between versions; performing graph matching on the interface evolution path graph based on a preset compatibility request to determine a target compatibility path; generating a data mapping rule for adapting the current version API call to the target version API interface according to the target compatibility path; applying the data mapping rule to the current request data to generate the data structure required by the target version interface, and completing the compatibility processing of the interface call. The present invention solves the compatibility problem brought about by API version upgrade.

Description

Technical Field

[0001] The present invention relates to the fields of software development and API management, and more specifically, to an AI-based method for processing API version management and compatibility handling. Background Art

[0002] In modern software development, APIs (Application Programming Interfaces), as important bridges for inter-system communication, are widely used in software projects of various scales. With the continuous change of business requirements and the continuous evolution of technical architectures, the iterative update of APIs has become the norm, resulting in the coexistence of multiple versions of APIs. Different versions of APIs may have significant differences in function definitions, data structures, and call methods, bringing complexity to the adaptation work of clients. In distributed systems or large-scale applications, developers often need to invest a lot of effort in dealing with inconsistencies between versions, such as data format conversion or interface call adjustment. This manual maintenance method is not only inefficient but also prone to errors due to human negligence. Therefore, how to achieve seamless connection and high-efficiency management between API versions has become a key challenge that urgently needs to be solved in the field of software development. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide an AI-based method for processing API version management and compatibility handling to solve the problems mentioned in the background art.

[0004] To achieve the above object, the present invention adopts the following technical solutions:

[0005] An AI-based method for processing API version management and compatibility handling includes:

[0006] Obtain API definition documents of multiple versions, and parse the API definition documents of each version into a structured interface field set;

[0007] Based on the structured interface field set, construct an interface field graph, where nodes represent interface fields and edges represent the structural dependency relationships between fields;

[0008] Perform inter-version structural alignment on the interface field graph to generate an interface evolution path graph, which is used to describe the change paths of interface fields between versions;

[0009] Based on a preset compatibility request, perform graph matching on the interface evolution path graph to determine a target compatibility path;

[0010] According to the target compatibility path, generate a data mapping rule for adapting the current version API call to the target version API interface;

[0011] Apply the data mapping rule to the current request data to generate the data structure required by the target version interface and complete the interface call compatibility processing.

[0012] In some embodiments, the process of constructing the interface field graph includes:

[0013] Generate nodes for each field in the structured interface field set, and establish the characteristics of the edges between the nodes in the graph according to the field nesting relationship, parent-child hierarchical relationship, and key name similarity.

[0014] In some embodiments, the nodes of the interface evolution path graph correspond to the fields extracted from the interface field graphs of each version, and the edges of the interface evolution path graph connect the fields between different versions.

[0015] In some embodiments, the process of graph matching includes: using the shortest path search algorithm to find the minimum cost path from the current version field structure to the target version field structure in the interface evolution path graph, and the minimum cost path is controlled by the change weight function.

[0016] In some embodiments, the change weight function is:

[0017] ;

[0018] Wherein, represents the path cost between field and field , represents the name semantic distance between field and field , represents the depth change amount experienced from the nesting level of field to the nesting level of field , and are adjustable parameters;

[0019] The total cost of a path is the sum of the path costs of adjacent fields on the path, and the minimum cost path is the path with the smallest sum of path costs.

[0020] In some embodiments, the structure alignment process includes using the field semantic vector embedding method to calculate the matching probability of fields in different versions. The semantic vector is obtained through a pre-trained model, and the matching probability is calculated according to the following formula :

[0021] ;

[0022] Wherein, and are fields respectively and semantic vector of is the activation coefficient, indicating a vector dot product operation.

[0023] In some embodiments, the generated data mapping rules are represented by a JSON mapping template, including field path replacement, field name redirection, data type conversion, and nested structure expansion or compression operations.

[0024] In some embodiments, the result of the interface call compatibility processing includes sending an HTTP request to the interface of the target version and converting the returned data into the original version format according to the inverse mapping rule to achieve a complete compatible call closed loop.

[0025] In some embodiments, the method further includes performing probability modeling on the interface field evolution path based on the interface call history record and optimizing the search for the target compatible path in combination with the call frequency.

[0026] In some embodiments, the method is deployed in a service gateway and serves as an interface proxy middle layer to perform dynamic version identification and compatible adaptation processing on API requests from clients.

[0027] The advantages of the present invention over the prior art are that the present invention solves the compatibility problem brought about by API version upgrade by introducing a unique solution based on graph and path matching. By using the interface field graph and the evolution path graph, the changes in the API structure can be accurately traced and data mapping rules can be generated, enabling the client to adapt to the new version of the API without modifying the code. This method significantly reduces the adaptation burden of developers and improves the stability and maintainability of the system. In addition, through the field semantic vector embedding technology, the accuracy of field alignment is further improved, ensuring compatible accuracy under complex structural changes. The application of the change weight function optimizes the path search efficiency, while the JSON mapping template provides a standardized execution basis for data conversion. These improvements work together to not only improve the automation level of version management but also enhance the flexibility and reliability of the method in practical applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 is the overall flowchart of the present invention;

[0029] Figure 2 is the flowchart for parsing the API definition document of the present invention;

[0030] Figure 3 is the flowchart for constructing the interface field graph of the present invention;

[0031] Figure 4 is the flowchart for generating the evolution path graph and determining the compatible path of the present invention. Detailed Implementation Modes

[0032] The following describes the detailed implementation modes of the present invention with reference to the accompanying drawings.

[0033] The present invention discloses a method for using artificial intelligence technology to handle API version management and compatibility, aiming to solve the compatibility challenges brought about by API version upgrades and ensure that different versions of APIs can be seamlessly connected and maintain service continuity.

[0034] As shown in FIG. 1, in the first step of implementing API version management, it is necessary to start from API definition documents of multiple versions. These documents are usually stored in standard formats such as Swagger and OpenAPI and contain information such as API interface definitions, request parameters, and response data. The goal of parsing these documents is to convert the messy raw data into a set of structured interface fields, laying a foundation for subsequent analysis and processing.

[0035] As shown in FIG. 2, specifically, the parsing process is divided into several sub-steps. First, read the definition documents of different versions from the API management system or repository, such as Swagger files of version 1.0 and version 2.0. Then, extract fields from the request parameters and response data of each interface, recording information such as field names, data types, and nested structures. Finally, organize the extracted information into a structured data format, such as JSON or XML, for programmatic processing.

[0036] For example, assume that an interface definition in version 1.0 contains the request parameter `{ "user": { "name": "string", "age": "integer"}}`, while the same interface in version 2.0 becomes `{ "userInfo": { "fullName": "string", "age": "integer"}}`. After parsing, the structured field set in version 1.0 may be represented as `["user.name", "user.age"]`, while in version 2.0 it is `["userInfo.fullName", "userInfo.age"]`. This structured representation retains the hierarchical relationship of the fields and provides a basis for subsequent graph construction.

[0037] As shown in FIG. 3, based on the parsed structured interface field set, the next step is to construct an interface field graph. This is a graphical structure where each node represents an interface field and the edges represent the structural dependency relationships between the fields, such as nested relationships or parent-child hierarchical relationships.

[0038] The process of constructing the graph can be decomposed into two main parts. First, nodes are generated for the fields in the field set of each version. Each node contains not only the field name but also attributes such as its data type and the version it belongs to. For example, `"user.name"` will generate a node with attributes that may include `{name: "name", type: "string", version: "1.0"}`.

[0039] Then, edges are established based on the relationships between the fields. This connection considers three main dependencies.

[0040] First, the nesting relationship. If field A contains field B, for example, `"user"` contains `"name"`, then an edge is established between `"user"` and `"user.name"` to represent the sub-field relationship.

[0041] Second, the parent-child hierarchical relationship. In multi-level nesting, such as `{ "user": { "info": { "name": "string"}}}`, hierarchical connections are formed between `"user"`, `"info"` and `"name"`.

[0042] Third, the key name similarity. For fields with similar names in different versions, such as `"name"` and `"fullName"`, an associated edge can be established by calculating the edit distance or semantic similarity to help identify possible field evolutions.

[0043] Taking `"user.name"` in version 1.0 and `"userInfo.fullName"` in version 2.0 as an example, the graph may contain a nested edge from `"user"` to `"user.name"` and an associated edge from `"user.name"` to `"userInfo.fullName"` based on key name similarity. Such a graph provides a visual and structured basis for analyzing field changes between versions.

[0044] As shown in Figure 4, in order to trace the change path of interface fields between different versions, it is necessary to align the structures of the interface field graphs of multiple versions to generate an interface evolution path graph. This graph not only shows the evolution of fields but also records the specific change types through edge labels.

[0045] The generation process includes several key steps. First, align the fields of different versions to identify which fields remain unchanged and which have changed. For example, `"user.age"` in version 1.0 and `"userInfo.age"` in version 2.0 may be aligned as the same field, while `"user.name"` and `"userInfo.fullName"` require further analysis.

[0046] Next, identify the types of changes between fields, which mainly include the following situations. First, renaming, such as `"name"` becoming `"fullName"`. Second, deletion, such as a field existing in the old version but disappearing in the new version. Third, addition, such as a new field added in the new version. Fourth, nested structure changes, such as a field changing from a first-level nesting to a second-level nesting. These change types are recorded in the graph as edge labels.

[0047] To achieve precise field alignment, a field semantic vector embedding method can be used. Specifically, convert the field names into high-dimensional semantic vectors through a pre-trained model (such as BERT or Word2Vec), and then calculate the matching probability between fields of different versions. The calculation formula for the matching probability is:

[0048] ;

[0049] where and are the semantic vectors of fields and respectively, is the activation coefficient, represents the vector dot product operation.

[0050] This formula is similar to the sigmoid function, mapping the dot product result to a probability value between 0 and 1, indicating the possibility of semantic similarity between two fields. For example, if the dot product of the semantic vectors of `"name"` and `"fullName"` is high and the matching probability is close to 1, it indicates that they may be in a renaming relationship.

[0051] Regarding the design of the formula, its core lies in using the dot product of semantic vectors to measure similarity, while the sigmoid function provides a smooth probability output. As the activation coefficient, it is used to control the steepness of the probability curve, usually with a value range between 1 and 10, and the specific value can be adjusted through experiments, such as setting it to 5 to balance sensitivity and stability.

[0052] For pre-trained models, in some embodiments, BERT can be used. Its architecture is based on Transformer and includes multiple layers of attention mechanisms. The training process is usually fine-tuned on a general corpus (such as Wikipedia), with the input being field names and the output being 768-dimensional vectors. During training, a contrastive learning objective can be used to optimize the vectors of similar fields to be close and those of dissimilar fields to be far apart.

[0053] For example, after semantic vector calculation, the probability of `"user.name"` in version 1.0 and `"userInfo.fullName"` in version 2.0 may be 0.9, indicating a high degree of match, while that of `"user.age"` and `"userInfo.age"` may be 0.95, indicating almost no change. Finally, the edge labels in the interface evolution path graph may include the "rename" label from `"user.name"` to `"userInfo.fullName"`.

[0054] The interface evolution path graph is a "graph of evolution between versions" constructed after aligning multiple interface field graphs, which describes various changes that fields undergo as the version is updated. In the interface evolution path graph, we do not treat the fields of all versions as isolated points, but place them in the same large graph, making each field instance - such as "user.name in version 1.0" or "userInfo.fullName in version 2.0" - become a node, and draw the connections between these nodes during the version iteration process. Specifically, whenever a new API version appears, we first read its field structure together with the previous version into the system, and then based on name similarity (which can be obtained through methods such as the above-mentioned matching probability calculation), nesting level, and context information, the AI will determine which old fields and which new fields belong to the same concept, and connect an edge with labels such as "rename", "delete", "add", or "nesting change" between them. In this way, along the edge, one can trace from any field instance to its corresponding form in other versions, and clearly see how each step of a field changes from its initial flat structure to subsequent multi-level nesting and then to possible simplification or splitting.

[0055] In the interface evolution path graph, each edge corresponds to a "micro change" operation - such as renaming a field, embedding it from a flat structure into a deeper level, splitting or merging a pair of fields into a new structure - and these operations themselves may be recorded in different orders and across different version increments. To give a more specific example: Suppose in the evolution from 1.0 to 3.0, the field user.name has gone through the process of "renaming first and then nesting", and in some scenarios, it has also been considered to be "directly renamed and nested at once" as userInfo.profile.fullName. When constructing the graph, in order to take into account manually maintained mappings, aggregative mappings automatically discovered by AI, and fine-grained mappings disassembled version by version, the system will add both of these operations to the same graph - one path is "rename→nest", and the other path is "atomic aggregate change". Although the starting and ending points are the same, the intermediate change steps and the marked costs (name change cost, nesting depth cost) are not consistent.

[0056] Therefore, when selecting from "V1:user.name" to "V3:userInfo.profile.fullName" on the graph, there is not just one fixed route, but there are multiple equivalent or approximately equivalent evolution chains, and each chain represents a different way of disassembling or aggregating version differences. By running the shortest path algorithm, it is possible to calculate "which combination of operations has the lowest total cost in the current business scenario" among these optional links, and assemble that set of operations into a specific data mapping script in order. The advantage of doing this is that it not only retains the model's compatibility with diverse evolution patterns, but also can flexibly select the optimal solution according to configuration or historical call situations, rather than simply squeezing all changes into a rigid "comprehensive mapping".

[0057] Specifically, a shortest path search algorithm (such as Dijkstra's algorithm) can be used to find the minimum cost path in the graph. The cost of a path is defined by a change weight function, and the formula is:

[0058] ;

[0059] Among them, represents the path cost (or conversion cost) between fields and , represents the name semantic distance between fields and , which can be calculated by edit distance (for example, the distance from `"name"` to `"fullName"` is 4) or cosine distance of semantic vectors; represents from The nested level conversion to The depth change amount experienced by the nested level of, for example, the change amount from the first-level nesting to the second-level nesting is 1. In a path from the initial field to the target field, the total cost can be obtained by calculating the sum of the path costs of all adjacent fields in the path, and the path with the minimum total cost is selected as the conversion path.

[0060] and are adjustable parameters used to balance the impacts of name changes and structural changes. The purpose of the formula design is to comprehensively consider the changes in both the semantic and structural dimensions. The name semantic distance reflects the similarity of the field meanings, while the nested level change amount captures the complexity of the structural adjustment. and The value ranges of usually between 0 and 1. For example = 0.7, = 0.3, indicating that more importance is attached to name changes. The specific values can be adjusted through grid search or business requirements.

[0061] For example, from `"user.name"` in version 1.0 to `"userInfo.fullName"` in version 2.0, assuming = 4 (edit distance), = 0 (the level remains unchanged), = 0.7, = 0.3, then the cost is . By calculating the costs of all paths, the path with the minimum total cost is finally selected as the target compatible path.

[0062] According to the target compatible path, data mapping rules are generated for adapting the current version of API calls to the target version. These rules are represented in the form of a JSON mapping template and include four main operations.

[0063] First, field path replacement. For example, replace `"user.name"` with `"userInfo.fullName"`. Second, field name redirection. For the renamed fields, the mapping from the old name to the new name is recorded in the rule. Third, data type conversion. If the field type changes from `"integer"` to `"string"`, then type conversion logic is added. Fourth, nested structure expansion or compression. For example, expand `{ "user": { "name": "Alice"}}` to `{ "userInfo": { "fullName": "Alice"}}`.

[0064] An example JSON mapping template might be:

[0065] ```json

[0066] {

[0067] "mappings":

[0068] {

[0069] "source": "user.name",

[0070] "target": "userInfo.fullName",

[0071] "operation": "rename"

[0072] },

[0073] {

[0074] "source": "user.age",

[0075] "target": "userInfo.age",

[0076] "operation": "copy"

[0077] }

[0079] }

[0080] ```

[0081] This template clearly describes the conversion logic of the fields, facilitating automatic execution by the program.

[0082] After generating the mapping rules, apply them to the current request data to complete the compatibility processing. First, convert the request data to the target version format according to the rules. For example, input `{ "user": { "name": "Alice", "age": 25}}` is converted to `{ "userInfo": { "fullName": "Alice", "age": 25}}`.

[0083] ​Then, use the converted data to send an HTTP request to the API of the target version, for example, call the target interface via the POST method. After the interface returns data, convert it back to the original version format according to the inverse mapping rules. For example, if the target version returns `{ "userInfo": { "fullName": "Alice", "id": "123"}}`, after inverse mapping, it becomes `{ "user":{ "name": "Alice", "id": "123"}}`.

[0084] This two-way conversion achieves a complete compatible call loop, ensuring that the caller can adapt to the new version without modifying the code.

[0085] To improve the performance of the method, optimization can be based on the interface call history. First, probabilistically model the field evolution path by analyzing historical data. For example, count the renaming frequency from `"name"` to `"fullName"` and establish a probability distribution. Then, prioritize high-probability paths in graph matching to reduce the search space.

[0086] In addition, this method can be deployed in the service gateway as an interface proxy middle layer. The gateway dynamically identifies the request version, applies compatibility processing, and forwards it to the target interface. For example, when the client sends a version 1.0 request, the gateway converts it to version 2.0 format and forwards it, and then converts the response data back to version 1.0 format for return.

[0087] Consider an embodiment of an online education platform that provides an API for querying students' course information. As the platform's functionality is upgraded, the API evolves from the initial version 1.0 to version 2.0, which also brings changes to the interface structure. If an old version client continues to use the old request format, it may not be able to interact correctly with the new version API. The present invention automatically handles these differences through AI technology, ensuring that the client can work properly without modifying the code.

[0088] Suppose the API request format of version 1.0 is like this: the client sends a simple structure containing student information, including the student's name and course name. By version 2.0, the platform decides to optimize the interface, integrate the student information under a new field, and change the course name to a more specific description. If the client still sends requests in the old format, the data will not meet the requirements of the new interface.

[0089] The present invention starts with the definition documents of the API. These documents are usually stored in a standard format, such as OpenAPI, which details the interface structure of each version. By parsing these documents, the system extracts the field information of version 1.0 and version 2.0. For example, version 1.0 may have a field called "student.name", while in version 2.0 it becomes "studentInfo.fullName". This information is organized into a structured collection for subsequent processing.

[0090] Next, the system converts this field information into a graphical structure, namely the interface field graph. Each field becomes a node in the graph. For example, "student.name" is a node with its name and data type. The nodes are connected by edges to reflect the hierarchical relationship of the fields. For example, there is an edge between "student" and "student.name" indicating nesting. If the field names in different versions are similar, such as "name" and "fullName", an association is also established by calculating the similarity.

[0091] With these graphs, the system aligns the graphs of the two versions to generate an evolution path graph. This graph can clearly show how the fields have changed. For example, it will find that "student.name" has become "studentInfo.fullName", perhaps just the name has changed, while another field may have disappeared completely. The types of changes, such as renaming or deletion, are recorded. To more accurately judge the relationship between fields, the system also uses an AI model to convert the field names into semantic vectors and confirms whether they correspond by calculating the similarity.

[0092] Then, the system needs to find the optimal conversion method from version 1.0 to version 2.0. This is like searching for a path in the graph with the goal of minimizing the conversion cost. The calculation of the cost takes into account the name changes and structural adjustments. For example, the cost of changing a name may be smaller than the cost of adding a hierarchy. After finding the path, the system generates a set of mapping rules to tell the client how to adjust the request data. For example, replace "student.name" with "studentInfo.fullName", and other fields may be directly copied over.

[0093] In practical applications, the old requests sent by the client will be intercepted by the system and converted into a new format according to the mapping rules. For example, the original request is {"student": {"name": "Zhang San", "course": "Mathematics"}}, and after conversion, it becomes {"studentInfo": {"fullName": "Zhang San", "courseTitle": "Mathematics"}}. The converted data is sent to the new version of the API, and after receiving the response, it is adjusted back according to the reverse rules to ensure that the client gets a result it can recognize.

[0094] As can be seen from the above, through constructing a graph, generating an evolution path, matching a compatible path, and applying mapping rules, the method of the present invention realizes automatic compatibility processing between API versions. Combining AI technologies such as semantic vector embedding and probability modeling, this solution performs excellently in terms of both efficiency and accuracy, providing an innovative and practical solution for API management.

[0095] The above is only a preferred specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present invention, according to the technical solution of the present invention and its inventive concept, makes equivalent substitutions or changes, and should be covered by the protection scope of the present invention.

Claims

1. An AI-based processing method for API version management and compatibility handling, characterized in that, including: Obtain API definition documents of multiple versions, and parse the API definition documents of each version into a set of structured interface fields; Based on the set of structured interface fields, construct an interface field graph, where nodes represent interface fields and edges represent the structural dependency relationships between fields; Perform inter-version structural alignment on the interface field graph to generate an interface evolution path graph, which is used to describe the change paths of interface fields between versions; Based on a preset compatibility request, perform graph matching on the interface evolution path graph to determine a target compatibility path; According to the target compatibility path, generate a data mapping rule for adapting the current version API call to the target version API interface; Apply the data mapping rule to the current request data to generate the data structure required by the target version interface and complete the interface call compatibility processing.

2. The AI processing API version management and compatibility processing method according to claim 1, wherein The process of constructing the interface field graph includes: Generate nodes for each field in the set of structured interface fields, and establish the characteristics of the edges between the nodes in the graph according to the field nesting relationship, parent-child hierarchy relationship, and key name similarity.

3. The method for AI processing API version management and compatibility processing according to claim 1, wherein The nodes of the interface evolution path graph correspond to the fields extracted from the interface field graphs of each version, and the edges of the interface evolution path graph connect the fields between different versions.

4. The method for AI processing API version management and compatibility processing according to claim 1, wherein The process of the graph matching includes: Use the shortest path search algorithm to find the minimum cost path from the current version field structure to the target version field structure in the interface evolution path graph, and the minimum cost path is controlled by a change weight function; The total cost of each path is the sum of the path costs of adjacent fields on the path, where the minimum cost path is the path with the smallest sum of total costs.

5. The method for AI processing API version management and compatibility processing according to claim 4, wherein The change weight function is: ; wherein, represents the path cost between fields and field ; represents the name semantic distance between fields and field ; represents the depth change amount experienced when converting the nested level of field to the nested level of field ; and are adjustable parameters.

6. The method for AI processing API version management and compatibility processing according to claim 1, characterized in that The structure alignment process includes calculating the matching probability of fields in different versions using a field semantic vector embedding method. The semantic vector is obtained through a pre-trained model, and the matching probability is calculated according to the following formula :[[]]END]] ; wherein, and are the semantic vectors of fields and respectively, is the activation coefficient, represents the vector dot product operation.

7. The method for AI processing API version management and compatibility processing according to claim 1, wherein The generated data mapping rule is represented by a JSON mapping template, including field path replacement, field name redirection, data type conversion, and nested structure expansion or compression operations.

8. The method for AI processing API version management and compatibility processing according to claim 1, wherein The result of the interface call compatibility processing includes sending an HTTP request to the interface of the target version and converting the returned data into the original version format according to the inverse mapping rule to achieve a complete compatible call closed loop.

9. The method for AI processing API version management and compatibility processing according to claim 1, wherein The method further includes probabilistically modeling the interface field evolution path based on the interface call history record and optimizing the search for the target compatibility path in combination with the call frequency.

10. The method for AI processing API version management and compatibility processing according to claim 1, characterized in that, The method is deployed in a service gateway as an interface proxy middle layer to perform dynamic version identification and compatibility adaptation processing on API requests from clients.

Images