API version management and compatibility processing method based on AI processing

Abstract

The invention discloses an API version management and compatibility processing method based on AI processing, and relates to the field of software development and API management.The API version management and compatibility processing method comprises the steps that API definition documents of multiple versions are obtained, and the API definition documents of all the versions are analyzed into a structured interface field set; constructing an interface field map based on the structured interface field set; performing inter-version structure alignment on the interface field atlas to generate an interface evolution path atlas which is used for describing change paths of interface fields among versions; based on a preset compatible request, performing graph matching on the interface evolution path graph, and determining a target compatible path; according to the target compatible path, generating a data mapping rule used for calling and adapting the current version API to a target version API interface; and applying the data mapping rule to the current request data, generating a data structure required by the target version interface, and completing interface calling compatibility processing. According to the method and the device, the compatibility problem caused by API version upgrading is solved.

Description

Technical Field

[0001] The present invention relates to the fields of software development and API management, and more particularly, 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 to handle 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 efficient 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: An AI-based method for processing API version management and compatibility handling includes: Obtain API definition documents of multiple versions, and parse the API definition documents of each version into a structured interface field set; 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; 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, generate the data structure required by the target version interface, and complete the interface call compatibility handling.

[0005] In some embodiments, the process of constructing the interface field graph includes: Generate nodes for each field in the set of structured interface fields, and establish the edge features between nodes in the graph according to the field nesting relationship, parent-child hierarchical relationship, and key name similarity.

[0006] 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.

[0007] 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.

[0008] In some embodiments, the change weight function is: ; Where 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 nested level of field to the nested level of field , and are adjustable parameters; 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 minimum sum of path costs.

[0009] 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 : ; Where and are the semantic vectors of field and respectively, is the activation coefficient, represents the vector dot product operation.

[0010] 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.

[0011] 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.

[0012] 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.

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

[0014] The advantages of the present invention over the prior art are that the present invention solves the compatibility problem brought about by the 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 tracked and the 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 the compatibility accuracy under complex structural changes. The application of the change weight function optimizes the path search efficiency, and the JSON mapping template provides a standardized execution basis for data conversion. The combined effect of these improvements not only enhances the automation level of version management but also strengthens the flexibility and reliability of the method in practical applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 is the overall flowchart of the present invention; Figure 2 is the flowchart for parsing the API definition document of the present invention; Figure 3 is the flowchart for constructing the interface field graph of the present invention; Figure 4 is the flowchart for generating the evolution path graph and determining the compatible path of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0016] The following describes the specific embodiments of the present invention with reference to the accompanying drawings.

[0017] 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 seamless connection of different versions of APIs and maintain the continuity of services.

[0018] As shown in Figure 1, in the first step of implementing API version management, it is necessary to start with 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 transform the messy raw data into a collection of structured interface fields, laying a foundation for subsequent analysis and processing.

[0019] As shown in Figure 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.

[0020] 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 collection 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 preserves the hierarchical relationship of the fields, providing a basis for subsequent graph construction.

[0021] As shown in Figure 3, based on the parsed structured interface field collection, 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 dependencies between the fields, such as nested relationships or parent-child hierarchical relationships.

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

[0023] Then, establish edge connections based on the relationships between the fields. This connection considers three main types of dependencies.

[0024] 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.

[0025] Second, the parent-child hierarchical relationship. In multi-level nesting, for example, `{ "user": { "info": { "name": "string"}}}`, hierarchical connections are formed among `"user"`, `"info"`, and `"name"`.

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

[0027] Taking `"user.name"` in version 1.0 and `"userInfo.fullName"` in version 2.0 as an example, the graph may contain a nesting edge from `"user"` to `"user.name"` and an association 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.

[0028] As shown in Figure 4, in order to trace the change path of interface fields between different versions, it is necessary to structurally align 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.

[0029] 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.

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

[0031] To achieve precise field alignment, a field semantic vector embedding method can be used. Specifically, the field names are converted into high-dimensional semantic vectors through a pre-trained model (such as BERT or Word2Vec), and then the matching probabilities between different versions of fields are calculated. The formula for calculating the matching probability is: ; where and are the semantic vectors of fields and respectively, is the activation coefficient, represents the vector dot product operation.

[0032] This formula is similar to the sigmoid function, mapping the dot product result to a probability value between 0 and 1, indicating the likelihood 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 renamed relationship.

[0033] 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. The specific value can be adjusted through experiments, such as setting it to 5 to balance sensitivity and stability.

[0034] For the pre-trained model, 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 the 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 the vectors of dissimilar fields to be far apart.

[0035] 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 matching degree, 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 "renamed" label from `"user.name"` to `"userInfo.fullName"`.

[0036] The interface evolution path graph is a "version - to - version evolution" graph 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 view the fields of all versions as isolated points, but rather 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. 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 them with an edge labeled with "rename", "delete", "add", or "nesting change", etc. In this way, along the edge, we can trace any field instance back to its corresponding form in other versions, and clearly see how a field changes step by step from its initial flat structure to subsequent multi - level nesting and then to possible simplification or splitting.

[0037] 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. Take a more specific example: Suppose in the evolution from 1.0 to 3.0, the field user.name has gone through the process of "rename first and then nest", and in some scenarios, it has also been considered to be "directly renamed and nested at once" to userInfo.profile.fullName. When the system constructs the graph, in order to accommodate manually maintained mappings, AI - automatically discovered aggregate mappings, and fine - grained mappings disassembled version by version, it 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 the same.

[0038] Therefore, when selecting from "V1:user.name" to "V3:userInfo.profile.fullName" on the graph, there is not just one fixed route, but multiple equivalent or approximately equivalent evolution chains. Each chain represents a different way of disassembling or aggregating version differences. By running the shortest path algorithm, we can calculate "which combination of operations has the lowest total cost in the current business scenario" among these alternative links, and piece together the set of operations in sequence to form a specific data mapping script. The advantage of this approach is that it not only retains the model's compatibility with diverse evolution patterns but also flexibly selects the optimal solution based on configuration or historical call situations, rather than rigidly squeezing all changes into a single inflexible "comprehensive mapping".

[0039] Specifically, the 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 the change weight function, with the formula: ; where, represents the path cost (or conversion cost) between fields and ; represents the name semantic distance between fields and , which can be calculated by the edit distance (e.g., the distance from `"name"` to `"fullName"` is 4) or the cosine distance of semantic vectors; represents the change in depth experienced when converting from the nested level of to the nested level of , for example, the change in level from one-level nesting to two-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.

[0040] 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 changes in both the semantic and structural dimensions. The name semantic distance reflects the similarity of field meanings, while the change in nested level captures the complexity of structural adjustments. and usually have a value range 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.

[0041] For example, from `"user.name"` in version 1.0 to `"userInfo.fullName"` in version 2.0, assuming = 4 (edit distance), =0 (hierarchy 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 compatibility path.

[0042] Based on the target compatibility path, data mapping rules are generated to adapt 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.

[0043] First, field path replacement. For example, replace `"user.name"` with `"userInfo.fullName"`. Second, field name redirection. For 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"`, type conversion logic is added. Fourth, expansion or compression of nested structures. For example, expand `{ "user": { "name": "Alice"}}` to `{ "userInfo": { "fullName": "Alice"}}`.

[0044] An example JSON mapping template might be: ```json { "mappings": { "source": "user.name", "target": "userInfo.fullName", "operation": "rename" }, { "source": "user.age", "target": "userInfo.age", "operation": "copy" } } ``` This template clearly describes the conversion logic of the fields, facilitating automatic execution by the program.​

[0045] 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, the input `{ "user": { "name": "Alice", "age": 25}}` is converted to `{ "userInfo": { "fullName": "Alice", "age": 25}}`.

[0046] 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"}}`.

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

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

[0049] 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 and returns it.

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

[0051] Suppose the API request format for version 1.0 is like this: the client sends a simple structure containing student information, which includes the student's name and course name. In 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.

[0052] The present invention starts with the API definition documents, which are usually stored in a standard format such as OpenAPI and detail 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 set for subsequent processing.

[0053] 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.

[0054] 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 change. For example, it will find that "student.name" becomes "studentInfo.fullName", perhaps just the name is changed, and another field may disappear 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 confirm their correspondence by calculating the similarity.

[0055] 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 renaming 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.

[0056] 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 getting the response, it is adjusted back according to the reverse rules to ensure that the client gets the result it can recognize.

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

[0058] The above is only the preferred specific implementation manner 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 all should be covered by the protection scope of the present invention.

Claims

1. An AI-based API version management and compatibility handling method, 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 method for AI processing API version management and compatibility processing 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 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: ;in, Representation field With Field The path cost between Representation field With Field The semantic distance between the names, Indicates from field The nested levels are converted to fields The amount of depth change experienced by the nesting level of and It is an adjustable parameter.

6. The method for AI processing API version management and compatibility processing according to claim 1, wherein The structure alignment process includes calculating the matching probability of fields in different versions using a field semantic vector embedding method. The semantic vectors are obtained through a pre-trained model, and the matching probability is calculated according to the following formula : ; wherein, and are respectively the semantic vectors of fields and , 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, characterized in that 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 to 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 AI processing API version management and compatibility processing method according to claim 1, wherein 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