Api information processing method and electronic device

Abstract

The application provides an API information processing method and an electronic device, wherein the method comprises: fusing abstract syntax tree analysis, large language model and retrieval enhancement generation technology, obtaining code fragments and a vector library by analyzing target application source code, extracting a route group and constructing a route mounting tree representing hierarchical relationships by using a large language model, determining complete target API information in combination with the route mounting tree and the extracted initial API information, and finally generating a function description through semantic retrieval of the vector library to associate related code fragments. The API information extraction and description generation full process are automated, the API information integrity and the accuracy and richness of the function description are improved, the manual maintenance burden is effectively reduced, and the application scenarios and business change scenarios lacking API document maintenance are adapted.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to an API information processing method and an electronic device. Background Technology

[0002] With the rapid development of web applications and microservice architectures, Application Programming Interfaces (APIs) have become the core of system interaction. Efficiently and accurately obtaining API information and generating functional documentation is crucial for development, testing, and maintenance. Traditional manual coding methods are inefficient and prone to delays; currently, most API information extraction is achieved automatically through intelligent extraction technologies.

[0003] Existing methods mainly fall into three categories: first, static analysis by parsing code annotations; second, obtaining route lists through runtime interfaces; and third, reading specification documents such as OpenAPI. These techniques can extract basic information such as API paths and methods, and are suitable for some standardized projects.

[0004] However, existing technologies struggle to generate high-quality functional descriptions, relying on manual writing, which leads to them becoming outdated easily. They lack semantic understanding capabilities, merely mechanically matching rules. They cannot connect to business logic scattered throughout the code, resulting in low automation. Faced with complex architectures or frequent changes, maintenance costs are high, accuracy is poor, and they fail to meet the needs of intelligent document generation. Summary of the Invention

[0005] The purpose of this application is to provide an API information processing method and electronic device to address the shortcomings of the prior art, thereby solving the problems of inaccurate API information extraction and low automation in the prior art.

[0006] To achieve the above objectives, the technical solution adopted in this application is as follows: In a first aspect, this application provides an API information processing method, the method comprising: The source code of the target application is parsed to obtain multiple code fragments and a code vector library, wherein the code vector library includes the code vectors corresponding to each code fragment; Based on the large language model, route groups are extracted from the code fragments, and a route mounting tree is constructed according to the route groups. The route mounting tree includes multiple nodes, each node is used to represent a route group, and the route mounting tree is used to describe the hierarchical relationship between route groups. Extract API information from the multiple code shards to obtain initial API information for at least one API. The initial API information includes: request method, API path, processing function, and route mount point. Based on the routing tree and the initial API information, determine the target API information for each API; The target API information for each API is retrieved from the code vector library to obtain multiple target code fragments corresponding to each API. Based on the large language model, functional description information of each API is generated according to the multiple target code fragments corresponding to each API, the target API information of each API, and a preset vocabulary definition table.

[0007] Secondly, embodiments of this application also provide an electronic device, including: a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of an API information processing method as described in any one of the first aspects.

[0008] The beneficial effects of this application are as follows: By implementing source code analysis, route mounting tree construction, API information extraction, and semantic retrieval to generate functional descriptions, the processing of API information is automated and intelligent. Through abstract syntax tree parsing and vectorized storage, the association of unstructured information is achieved. A large language model extracts route groups and basic API information, and the route mounting tree completes the full path, ensuring the integrity and accuracy of API information, especially in scenarios where API interface addresses are stored across files. Based on the retrieval-enhanced generation mechanism, functional descriptions are generated by associating relevant code snippets, enabling a deep understanding of the code's business intent. This significantly improves the richness and semantic depth of the descriptions, effectively reducing the burden of manual maintenance and thus meeting the software development needs for automated and intelligent documentation.

[0009] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A flowchart of an API information processing method provided in an embodiment of this application is shown; Figure 2 This document illustrates a flowchart of constructing a route mounting tree according to an embodiment of this application. Figure 3 This paper illustrates a flowchart of yet another method for mounting a route mounting tree provided in an embodiment of this application. Figure 4 This paper illustrates a flowchart of yet another method for mounting a route mounting tree provided in an embodiment of this application. Figure 5 This document illustrates a flowchart of a method for determining a parent node, as provided in an embodiment of this application. Figure 6 This document illustrates a flowchart of a method for determining target API information according to an embodiment of this application. Figure 7 This document illustrates a flowchart of a method for determining complete API path information according to an embodiment of this application. Figure 8 This document illustrates a flowchart of a method for determining target code segments according to an embodiment of this application. Figure 9 This paper shows a schematic diagram of the structure of an API information processing device provided in an embodiment of this application; Figure 10 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0013] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0014] Currently, the technical approaches for extracting APIs and their functional descriptions from web applications mainly fall into three categories. The first is static analysis based on configuration or annotations, which extracts basic API information by parsing specific annotations in configuration files or source code and using regular expression pattern matching. The second is runtime analysis, which obtains the list of registered APIs by accessing the framework's built-in routing table or reflection mechanisms after the application starts. The third is parsing API specification documents, which directly reads specification files such as OpenAPI to obtain structured API definitions.

[0015] However, although the above methods can obtain basic information such as the API path, there are still obvious shortcomings.

[0016] First, existing technologies lack high-quality functional descriptions. In most cases, only basic API information is available, but its specific function remains unclear. For example, one might know there's a ` / user / login` interface, but not its authentication method, parameter validation rules, or business logic. Furthermore, existing application interface documentation is scarce, and API descriptions often rely on manual writing, making them prone to omissions, obsolescence, or inaccuracies.

[0017] Secondly, existing technologies lack semantic understanding capabilities. They cannot fully comprehend the business intent behind the code, making them prone to omissions or misjudgments when faced with different coding styles or complex nested structures. Furthermore, existing technologies suffer from low automation. When the number of APIs is large or changes frequently, manual documentation is costly, inefficient, and makes it difficult to ensure that documentation is synchronized with the code.

[0018] Furthermore, in current API writing scenarios, API functionality may be scattered across multiple code files, comments, and even constant definitions. Existing technologies struggle to link this fragmented information across files, which can easily lead to incomplete API information retrieval.

[0019] In summary, existing methods for extracting APIs and their functional descriptions only scratch the surface, lacking the ability to understand and integrate the deep business semantics of APIs. This results in low-quality and difficult-to-maintain documents, failing to meet the demands of modern software development for automated and intelligent documentation.

[0020] Based on this, this application proposes an API information processing method that integrates abstract syntax tree parsing, large language models, and retrieval enhancement generation techniques. It obtains code fragments and a vector library by parsing the target application's source code, extracts route groups using the large language model, and constructs a route mounting tree representing the global hierarchical relationships within the application. This tree, combined with the extracted initial API information, determines the complete target API information. Finally, semantic retrieval from the vector library is used to associate relevant code fragments, generating a functional description. This method automates the entire process of API information extraction and description generation, improving the completeness of API information and the accuracy and richness of functional descriptions, effectively reducing the burden of manual maintenance, and adapting to large-scale applications and business change scenarios.

[0021] Next, combine Figure 1 The API information processing method described in this application can be executed by an electronic device, such as... Figure 1 As shown, the method includes: S101. Analyze the source code of the target application to obtain multiple code fragments and a code vector library.

[0022] The code vector library contains code vectors corresponding to each code slice. A code slice refers to an independent code unit obtained by parsing and splitting the source code of a target application. Code slices include function declarations, method declarations, type declarations, etc. The code vector library is a database that stores the vector data corresponding to code slices. Code vectors are generated by vectorizing and embedding code slices for subsequent semantic retrieval.

[0023] It is worth noting that a preset length threshold can be set for the code segment length. If the length of a code segment exceeds the threshold, the code segment can be further split into multiple sub-segments, and these sub-segments can be associated with and stored with the original code segment. The length threshold can be determined based on the context length limit of the large language model to ensure that the code segments can be input into and processed by the large language model.

[0024] The target application refers to the web application that requires API extraction and API function description information generation. The source code of the target application includes API-related route definitions, processing logic, and other code.

[0025] In one possible implementation, an abstract syntax tree parsing library can be used to perform deep parsing of the target application's source code, extracting core code fragments such as functions, methods, and type declarations. For extremely long code fragments, they can be marked and intelligently fragmented, then MapReduce mapping and merging can be performed to obtain multiple sub-fragments. The sub-fragments are then associated with and stored with the original code fragments. All code fragments are then vectorized and embedded, and the generated code vectors are stored in a vector database to form a code vector library.

[0026] S102. Extract route groups from code fragments based on the large language model, and construct a route mounting tree based on the route groups.

[0027] A route mounting tree consists of multiple nodes, each representing a route group. The route mounting tree describes the hierarchical relationship between route groups. A route group is a logical unit representing the hierarchical relationship of API routes. Multiple route groups are hierarchically associated to form the basis of a complete routing path. The route mounting tree is a tree-structured data structure that stores the hierarchical relationship between route groups. Each node corresponds to a route group, and the hierarchical mounting relationship between route groups is reflected through node associations.

[0028] For example, suppose the complete interface address of an API is api / v1 / check, where / check is the specific address of the API. api and v1 may be separate and not necessarily in the same file. api and v1 are a route group. The route group of an API may be scattered across multiple files, while the specific API is only mounted at one level. Therefore, in this scenario, existing technologies can only obtain the specific address of the API, and it is difficult to directly extract the complete interface address. By constructing a route mounting tree, the hierarchical relationship of the route group can be clearly understood. Even if the route groups are distributed in different files, the complete path of the API can be obtained through the route mounting tree.

[0029] Large language models are artificial intelligence models with deep semantic understanding and information extraction capabilities. They can parse code intent based on prompt words, extract structured information, and generate natural language descriptions.

[0030] In one possible implementation, all code shards can be traversed, and a large language model can be used to determine whether a shard contains routing information. Routing-related code can be filtered out, and for the filtered code shards, the mounting information of each routing group can be extracted using the large language model. Based on the parent-child relationship in the mounting information, a routing mounting tree can be dynamically constructed, with each node corresponding to a routing group and the relationship between nodes reflecting a hierarchical relationship.

[0031] S103. Extract API information from multiple code segments to obtain initial API information for at least one API.

[0032] The initial API information is basic API information extracted directly from the code shards. The initial API information includes: request method, API path, processing function, and route mount point.

[0033] Here, "request method" refers to the HTTP request methods supported by the API. "Processing function" refers to the function used to respond to API requests and implement business logic. "API path" refers to a partial path segment of the API, such as the specific address / check in the S102 example above. "Route mount point" refers to the mount object variable name corresponding to the route group or API in the code, and is a key identifier linking the route group and the API.

[0034] In one possible implementation, all code fragments containing route groups can be traversed, and the code content can be analyzed using a large language model to extract the HTTP request method, path fragment, processing function name, and route mount point corresponding to each API. This information can then be integrated into the initial API information.

[0035] S104. Based on the routing mount tree and initial API information, determine the target API information for each API.

[0036] Target API information refers to the complete API information formed by integrating the initial API information with the routing mount tree hierarchy, including the complete path that can be directly accessed and the basic information of the API.

[0037] Optionally, for the initial API information of each API, all ancestor nodes are recursively searched in the routing tree based on its route mount point; the mount path of each ancestor node is extracted and concatenated with the path fragment of the API itself to obtain the complete access path of the API; finally, the request method, complete path, processing function, and route mount point are combined into a structured routing record to obtain the target API information.

[0038] S105. Retrieve the target API information of each API from the code vector library to obtain multiple target code segments corresponding to each API. Based on the large language model, generate functional description information of each API according to the multiple target code segments corresponding to each API, the target API information of each API, and the preset vocabulary definition table.

[0039] The target code fragment refers to the code fragment retrieved from the code vector library that is highly relevant to the target API function. Functional description information refers to API function descriptions rich in business semantics, including basic operations, business rules, constraints, and other information. The lexical definition table predefines the meanings of business-related terms, enabling the large language model to understand the meanings of custom terms based on the lexical definition table.

[0040] Optionally, a query vector can be constructed based on the target API information, and a semantic similarity search can be performed in the code vector library to recall multiple code fragments related to the target API information. After reordering the recall results, they can be filtered according to a preset similarity threshold to obtain the target code fragments. Finally, the target API information and the target code fragments are filled into a preset prompt word template and input into a large language model. The large language model uses the target code fragments as context information of the target API information to generate functional description information containing deep semantics such as business logic and constraints.

[0041] Optionally, multiple target code fragments corresponding to the API and the target API information can be filled into a preset prompt word template to obtain prompt statements. The prompt statements can then be input into a large language model to obtain the API's functional description information.

[0042] In this embodiment, the steps of source code parsing, route mounting tree construction, API information extraction, and semantic retrieval to generate functional descriptions achieve automation and intelligence in API information processing. Through abstract syntax tree parsing and vectorized storage, the association of unstructured information is achieved. A large language model extracts route groups and basic API information, and the route mounting tree completes the full path, ensuring the integrity and accuracy of API information, especially in scenarios where API interface addresses are stored across files. Based on the retrieval-enhanced generation mechanism, functional descriptions are generated by associating relevant code snippets, enabling a deep understanding of the code's business intent. This significantly improves the richness and semantic depth of the description, effectively reducing the burden of manual maintenance and thus meeting the software development needs for automated and intelligent documentation.

[0043] The following is a further explanation of the above method for extracting route groups from code fragments based on a large language model and constructing a route mount tree based on the route groups, such as... Figure 2 As shown, step S102 above includes: S201. Based on the large language model, each code segment is judged. If the code segment contains routing information, a preset label is added to the code segment to obtain the code segment to be extracted.

[0044] Each code slice includes contextual information representing the code structure, such as the file it belongs to, the class it belongs to, the structure it belongs to, the scope of variables, and the calling relationships. The large language model can analyze the code and contextual information in the code slice to determine whether the code slice contains the definition or registration logic of API routes. If it does, the code slice is considered to contain routing information; if it does not, the code slice does not contain routing information.

[0045] Optionally, all code segments obtained in step S101 can be iterated. For each code segment, if it is a normal-length segment less than a preset length threshold, the content of the code segment is directly input into the large language model, and the model is driven by a general prompt word to determine whether it contains routing information. If it is an extremely long code segment greater than the preset length threshold, all its sub-segments can be read, input into the large language model respectively, and the judgment results can be aggregated. Since each sub-segment has the same context structure (code structure), the large language model can fuse the results of sub-segments with the same context structure to obtain the judgment result of the same code segment corresponding to each sub-segment. If the judgment result indicates that routing information is contained, a preset label is added to the code segment, ultimately forming a set of code segments to be extracted.

[0046] S202. Based on the large language model, perform route group extraction on each code fragment to be extracted, obtain the route mounting information of at least one route group in each code fragment to be extracted, and construct a route mounting tree based on the route mounting information of at least one route group.

[0047] Optionally, all code fragments to be extracted can be traversed, and the content of each fragment can be input into a large language model. The model can be guided by prompt words to extract the route group and the corresponding route mounting information. Then, the route mounting information of all route groups can be collected, and each route group can be added as a node to the route mounting tree according to the association between the parent route mounting point and the current route mounting point, so as to dynamically build a complete route mounting tree and solve the problem of route hierarchy association across files and modules.

[0048] The code shard includes at least one routing group. Each routing group has corresponding and unique route mounting information. A route mounting tree can be dynamically created based on the route mounting information of the routing group. Each node in the route mounting tree corresponds to a routing group, and the attribute information of the node is the route mounting information of the routing group.

[0049] This application's embodiments achieve intelligent judgment of routing information and accurate extraction of route groups through a large language model. It quickly filters code fragments to be processed using preset tags, and constructs a route mounting tree based on the extracted route mounting information. This breaks through the dependence of traditional methods on specific framework syntax, achieving cross-programming language route identification and hierarchical relationship reconstruction. It improves the accuracy and efficiency of route group extraction, ensures that the construction of the route mounting tree is based on accurate routing-related data, provides a reliable hierarchical structure basis for subsequent API complete path parsing, and reduces interference from invalid code in subsequent processes.

[0050] The following is a further explanation of the above-mentioned extraction of route groups from each code fragment to be extracted based on a large language model, obtaining route mounting information for at least one route group in each code fragment to be extracted, and constructing a route mounting tree based on the route mounting information of at least one route group. Figure 3 As shown, the above step S202 includes: S301. Traverse each code segment to be extracted. For the current code segment to be extracted, fill the current code segment to be extracted into the preset prompt word template to obtain the prompt statement. Input the prompt statement into the large language model. The large language model extracts information from the current code segment to be extracted to obtain at least one routing group in the current code segment to be extracted and the routing mounting information of each routing group.

[0051] Route mounting information includes: the current route mount point, the mount path, the parent route mount point, and the child route mount points. The current route mount point can be the variable name of the currently mounted route object, the mount path is the base path prefix bound to the route object, the parent route mount point refers to the variable name of the parent route object, and the child route mount point refers to the variable name of the child route object.

[0052] The prompt word template can be a pre-designed text template used to guide a large language model to extract routing mount information, containing information extraction instructions and output format requirements.

[0053] For example, the prompt message after filling in the information is: "You are a Web framework expert. Please analyze the following code snippet and extract the route mount information. Please output strictly in JSON format, and the fields must be: mount_var, mount_path, parent_var. If there is no parent, then parent_var is an empty string. [Programming Language]: Go; [Framework Type]: Gin; [AST Context]: The variable 'v1' is created by api.Group(...); Call expression: v1 := api.Group(" / v1"); [Code Content]: v1 := api.Group(" / v1"); v1.GET(" / ping", pingHandler); [Task Description]: mount_var: Current route mount point (here, "v1"); mount_path: Bound path prefix (here, " / v1"); parent_var: The parent route mount point (here, "api"); please determine whether there is an implicit mount or middleware wrapper based on semantic understanding. After inputting the prompt into the large language model, the large language model can analyze the route group in the code snippet and output the route mount information of the route group.

[0054] For example, suppose the complete access path of an API is / api / v1 / user / check, where api, v1, and user are three-level routing groups, and / check is a specific API path fragment. The relevant route definitions are scattered across two files. File 1 defines the root routing group api and the routing group v1 mounted under the root routing group. File 2 defines the routing group user and the specific API path fragment / check, and the routing group user in file 2 is mounted under the routing group v1. Therefore, the API contains three-level routing groups, and the route mounting information for these three-level routing groups can be represented as Table 1 below. Based on Table 1, the hierarchical mounting logic of the routing groups can be understood, thus resolving the problem of scattered routing group definitions across files.

[0055] Table 1. Example of route mounting information

[0056] S302. Based on the routing mount information of each routing group in the current code fragment to be extracted, generate the current node corresponding to each routing group in the current code fragment to be extracted, and add the current node to the routing mount tree.

[0057] Optionally, for each routing group in the code fragment to be extracted, a corresponding current node is generated. The node's attribute information includes the current routing mount point, mount path, and parent routing mount point of the routing group. Then, based on the association between the parent routing mount point and nodes in the existing routing mount tree, the position of the current node in the tree is determined, and it is added to the routing mount tree to realize the dynamic expansion and improvement of the routing mount tree, ensuring that the nodes in the tree can fully represent the hierarchical association of all routing groups.

[0058] In this embodiment, a standardized prompt word template guides a large language model to accurately extract route mounting information. Based on this information, nodes are generated and a route mounting tree is constructed, ensuring the structured and accurate extraction of route group information and resolving the challenge of associating scattered route group definitions across files. This achieves the orderly construction of the route mounting tree, providing reliable hierarchical structure support for the accurate derivation of complete API paths, while also improving the standardization and efficiency of route information extraction and adapting to complex route definition scenarios.

[0059] The following is a further explanation of how, based on the route mounting information of each route group in the current code fragment to be extracted, the current node corresponding to each route group in the current code fragment to be extracted is generated, and the current node is added to the route mounting tree. Figure 4 As shown, step S302 above includes: S401. If the parent route mount point in the route mount information is empty, then generate the current node corresponding to the route group according to the route mount information of the route group, and use the current node as the root node of the route mount tree.

[0060] When processing the route group from which code fragments are to be extracted, if the parent route mount point in its route mount information is None or empty, it indicates that the route group is the top-level route group (such as the "api" route group in the previous example). Based on the current route mount point, mount path, and other information of the route group, the current node is generated, and this node is set as the root node of the route mount tree, thereby completing the initial construction of the tree.

[0061] S402. If the parent route mount point in the route mount information is not empty, generate the current node corresponding to the route group according to the route mount information of the route group, determine the parent node of the current node in the route mount tree according to the parent route mount point, and add the current node as a leaf node of the parent node to the route mount tree.

[0062] When the parent route mount point of a route group is not empty, the current node can be generated first based on the route mount information of the route group; then, the node corresponding to the parent route mount point is traversed in the constructed route mount tree, and the node is determined as the parent node of the current node; finally, the current node is added to the route mount tree as the leaf node of the parent node, for example, the node of the "v1" route group is used as the leaf node of the "api" route group node, so as to achieve accurate association of the route hierarchy relationship.

[0063] In this embodiment, by distinguishing whether the parent route mount point is empty, the different construction methods of the route node in the mount tree are clarified, thus realizing the orderly and accurate construction of the route mount tree.

[0064] The following is a further explanation of how the parent node of the current node is determined in the route mount tree based on the parent route mount point, such as... Figure 5 As shown, step S402 above includes: S501. If the parent route mount point of the routing group has a corresponding node in the route mount tree, then the node corresponding to the parent route mount point shall be the parent node of the current node.

[0065] When processing the route mount information for the current route group, the existing route mount tree is searched to determine if a node corresponding to the parent route mount point exists. If it exists, that node is directly designated as the parent node of the current node, thus completing the location and addition of the current node in the route mount tree.

[0066] S502. If the parent route mount point of the route group does not have a corresponding node in the route mount tree, the route group is taken as a candidate root node, and the candidate root node is associated with the newly added node.

[0067] If the parent route mount point of the route group does not have a node with the same variable name in the route mount tree, that is, the route group is an isolated node, then the route group can be used as a candidate root node, and new nodes to be added to the route mount tree can continue to be processed.

[0068] When adding a new node to the routing tree, the parent-child relationship between the new node and all nodes in the routing tree can be searched. If an isolated node is a child or parent node of the new node, the relationship between the isolated node and the new node is established, and the new node is added to the routing tree.

[0069] It should be noted that when constructing the route mount tree, each newly added node is compared with all nodes already added to the route mount tree. The newly added node may directly become a leaf node of the route mount tree, or it may cause changes in the relationships of existing nodes in the route mount tree. This is because the API's route group information may be defined across files and in a scattered manner.

[0070] In this embodiment, by distinguishing the existence of parent route mount points in the route mount tree and employing different parent node determination methods, the problem of route node association caused by cross-file and scattered definitions is effectively solved. By leveraging a large language model to mine potential associations and determining parent nodes through similarity filtering, the generation of isolated nodes is avoided, ensuring the integrity of the route mount tree and the accuracy of hierarchical relationships.

[0071] The following is a further explanation of how the target API information for each API is determined based on the routing mount tree and initial API information, such as... Figure 6 As shown, step S104 above includes: S601. Based on the current route mount point of the API, recursively search in the route mount tree to obtain the complete path information of the API.

[0072] In one possible implementation, for the initial API information of each API, its route mount point can be extracted. Starting from the route mount point, all its ancestor nodes (parent nodes, grandparent nodes, etc.) are recursively searched in the route mount tree. Then, the mount path of each ancestor node is extracted and concatenated with the path fragment of the API itself in hierarchical order. For example, the root path of "api", " / v1" of "v1", " / user" of "user" and the API path fragment " / check" are concatenated to obtain the complete path information " / api / v1 / user / check".

[0073] S602. Combine the request method, API path, processing function, and complete path information into a structured routing record to obtain the target API information of the API.

[0074] Optionally, the request method, API path, and processing function in the initial API information can be collected and combined with the complete path information obtained by recursive lookup. These data are then combined into a structured routing record in a preset format. This record contains the target API information, which is used to build query vectors and generate function descriptions in the code vector library.

[0075] In this embodiment, the complete path is completed by recursively searching the route mounting tree and forming a structured route record, effectively solving the problem of incomplete paths caused by scattered definitions across file route groups. This ensures the accuracy and uniqueness of the complete API path information, and the constructed structured route record provides a foundation for subsequent semantic retrieval and functional description generation.

[0076] Optionally, the nodes in the route mount tree include: a list of child nodes, which records at least one child route mount point connected to the node. Each node represents a route group, and the node's child node list records the route mount points of all sub-route groups mounted under the route group.

[0077] like Figure 7 As shown, the process of recursively searching the route mount point of the API in the route mount tree to obtain the complete path information of the API includes: S701. Traverse the nodes in the route mounting tree. For the current node, if the current route mounting point of the current node is the same as the current route mounting point of the API, then the current node is taken as a target node of the API. The path prefix of the parent node of the target node is obtained recursively, and the obtained path prefix of the parent node and the path information of the target node are concatenated to obtain the complete path information of the API.

[0078] Optionally, the path prefix refers to the path string formed by combining the mount paths of all ancestor nodes of the target node in hierarchical order. For example, the root path of the "api" node and " / v1" of the "v1" node are combined to form the path prefix " / api / v1".

[0079] In one possible implementation, the constructed route mounting tree can be traversed, and the current route mounting point of each current node can be compared with the current route mounting point of the API. If they match, the node is determined as the target node. Then, all parent nodes of the target node are recursively traversed, the mounting paths of each parent node are extracted and combined into path prefixes in hierarchical order, and finally the path prefixes are concatenated with the path information of the target node itself to form the complete path information of the API. For example, the path prefix " / api / v1" is concatenated with the target node path " / user" and combined with the API's own path fragment " / check" to obtain the complete path " / api / v1 / user / check".

[0080] S702. If the current route mount point of a node in the route mount tree is different from the current route mount point of the API, then determine whether the current route mount point of the API is in the node's child node list. If so, take the node in the child node list that contains the current route mount point of the API as the target node, and recursively obtain the path prefix of the target node's parent node. Then, concatenate the obtained path prefix of the parent node with the path information of the target node to obtain the complete path information of the API.

[0081] Optionally, if no node matching the API route mount point is found in the top-level node of the route mount tree, check the child node list of each node. If the child node list of a certain node contains the current route mount point of the API, the child node is determined as the target node. Then, following the same logic as step S701 above, recursively obtain the path prefix of the target node's parent node, concatenate the path prefix with the target node's path information, and obtain the complete path information of the API, thus solving the path resolution problem of multi-level nested route groups.

[0082] It should be noted that the route mount tree may include multiple nodes that match the API's route mount point. In this case, the target node can be determined from among the multiple nodes based on the file where each node and the API's route mount point are located, and whether there are variable conflicts. The above S701 steps specifically include: If multiple current nodes have the same current route mount point as the API, then the target node of the API is determined from among the current route mount points of the multiple current nodes based on the current route mount point of the API and the file identifier of each current route mount point.

[0083] In one possible implementation, it can be determined whether the nodes in the extracted route mount tree have the same file identifier as the current route mount point of the API, i.e., whether they are in the same file. If the nodes in the extracted route mount tree are in the same file as the current route mount point of the API, then the nodes in the extracted route mount tree can be determined as the target nodes of the API.

[0084] Optionally, if the nodes of the route mount tree and the current route mount point of the API are not in the same file, the variables of the nodes of the route mount tree and the current route mount point of the API can be further judged. If the variables of the two have the same and unique variables, the extracted nodes of the route mount tree can be determined as the target nodes of the API, thus avoiding the syntax problem of variable name conflict.

[0085] In this embodiment, the target node is located using two methods: direct matching of route mount points and deep lookup of the child node list. Combined with the logic of recursively tracing the path prefix of the parent node, the complete API path parsing is achieved in complex nested routing scenarios. This solves the problem of path concatenation in deeply nested and cross-module routing, ensuring the accuracy and completeness of the full path information.

[0086] The following section describes the overall process of querying route mount points in the route mount tree as described in this application, using a specific business example. It should be understood that the following business example is only one possible embodiment of the aforementioned method and should not be considered limiting.

[0087] For example, suppose a user route file (ID: File_C) is defined for the target API GET / check. The system identifies the following core information from this file: Method: GET; Path fragment: / check; Processor function: checkUserStatus; Router variable name: userRouter.

[0088] Before merging the paths, the system first uses the router variable name (userRouter) identified in the current file (File_C) as a clue to query the global route mount tree built in the first phase. The goal of the query is to find records where userRouter is mounted to its parent router.

[0089] Scenario 1: Unique variable name matching If the variable name userRouter appears in only one file record in the routing mount tree (for example, only in the record for file_B, indicating that userRouter is mounted in file_B), then that record is used directly. This means that the mount path of userRouter is explicit, that is, its route mount point on the parent router is / user.

[0090] Scenario 2: Handling Duplicate Variable Names There may be multiple records for userRouter in the route mount tree because they originate from different files. For example: Record 1: In the file File_B, v1Router mounts userRouter (path is / user).

[0091] Record 2: In the file File_X, adminRouter also mounts another userRouter with the same name (the path may be / admin / user).

[0092] At this point, no single record is randomly selected; instead, precise context matching is performed. For example, it checks which of these records has a sub-router variable name (userRouter) referenced by the file (File_C) containing the API currently being processed.

[0093] By comparing file IDs, it can be uniquely determined that the userRouter in File_C corresponds to the mount record in File_B. This eliminates irrelevant router records in File_X that merely share the same name. This precise matching based on file IDs ensures the correctness of path composition.

[0094] After determining the mount point / user of userRouter in File_B, the path synthesis algorithm is initiated. Starting from mount point / user, it recursively queries the route mount tree to obtain the complete path information. Specifically, the algorithm first appends the path fragment / check of the current API to the mount path / user of userRouter, resulting in / user / check. Next, the algorithm recursively queries the mount path of userRouter's parent router v1Router (in File_B). According to the route mount tree, the mount point of v1Router on the root router rootRouter (in File_A) is / V1. Continuing recursively, the mount point of rootRouter on the application is / api. Finally, by tracing back the entire mount chain, the system correctly concatenates the paths at each level to generate the complete API path: / api / V1 / user / check.

[0095] The following is a further explanation of how the target API information for each API was retrieved from the code vector library to obtain multiple target code fragments corresponding to each API. Figure 8 As shown, step S105 above includes: S801. Generate a query vector based on the target API information of the API.

[0096] Optionally, core features can be extracted from the API target API information, including the processing function name, complete path information, request method, etc., and these core features can be transformed into query vectors with uniform dimensions through a vectorization model.

[0097] S802. Based on the semantic similarity between the query vector and each code vector in the code vector library, determine the candidate query vector corresponding to the query vector.

[0098] Based on the characteristic that vector distance in vector space represents semantic similarity, code vectors related to the target API function are selected. In one possible implementation, the generated query vector can be input into a code vector library. The semantic similarity calculation algorithm of the vector database is used to calculate the semantic similarity between the query vector and all code vectors in the library, and code vectors with a similarity greater than 0 are selected as candidate query vectors.

[0099] S803. Reorder each candidate query vector to obtain the reordering result, and filter the reordering result based on the preset similarity threshold to obtain multiple target query vectors, and use the code slices corresponding to each target query vector as multiple target code slices corresponding to the API.

[0100] Optionally, the candidate query vectors can be reordered from high to low based on their semantic similarity to the query vectors, so that the code vectors with the strongest relevance are ranked first. Based on a preset similarity threshold, candidate query vectors that are lower than the threshold after reordering are filtered out, and the remaining candidate query vectors are the target query vectors, and their corresponding code slices are the target code slices that are highly relevant to the target API.

[0101] In this embodiment, a query vector is generated using target API information. Target code fragments are then obtained through semantic similarity matching, reordering, and threshold filtering, achieving accurate association of scattered unstructured code information. By filtering out context fragments highly relevant to API functions, irrelevant information interference can be effectively eliminated, ensuring the accuracy and richness of the generated API function descriptions, while simultaneously improving the efficiency and accuracy of semantic retrieval.

[0102] Based on the same inventive concept, this application also provides an API information processing device corresponding to the API information processing method. Since the principle of the device in this application is similar to the API information processing method described above in this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0103] Figure 9 A schematic diagram of the structure of an API information processing device provided in an embodiment of this application is shown.

[0104] The parsing module 901 is used to parse the source code of the target application to obtain multiple code fragments and a code vector library, which includes the code vectors corresponding to each code fragment. The first extraction module 902 is used to extract route groups from code fragments based on a large language model, construct a route mounting tree based on the route groups, the route mounting tree includes multiple nodes, each node is used to represent a route group, and the route mounting tree is used to describe the hierarchical relationship between route groups. The second extraction module 903 is used to extract API information from multiple code segments to obtain the initial API information of at least one API. The initial API information includes: request method, API path, processing function and route mount point. Module 904 is used to determine the target API information for each API based on the routing mount tree and the initial API information. The generation module 905 is used to retrieve the target API information of each API from the code vector library, obtain multiple target code fragments corresponding to each API, and generate functional description information of each API based on the large language model according to the multiple target code fragments corresponding to each API and the target API information of each API.

[0105] Optionally, the first extraction module 902 is specifically used for: Based on the large language model, each code segment is judged. If the code segment contains routing information, a preset label is added to the code segment to be extracted. Based on the large language model, route groups are extracted from each code fragment to be extracted, and route mounting information of at least one route group in each code fragment to be extracted is obtained. Then, a route mounting tree is constructed based on the route mounting information of at least one route group.

[0106] Optionally, the first extraction module 902 is specifically used for: Iterate through each code segment to be extracted. For the current code segment to be extracted, fill the current code segment to be extracted into the preset prompt word template to obtain the prompt statement. Input the prompt statement into the large language model. The large language model extracts information from the current code segment to be extracted to obtain at least one route group in the current code segment to be extracted and the route mounting information of each route group. The route mounting information includes: the current route mounting point, the mounting path, and the parent route mounting point. Based on the route mounting information of each route group in the current code fragment to be extracted, generate the current node corresponding to each route group in the current code fragment to be extracted, and add the current node to the route mounting tree.

[0107] Optionally, the first extraction module 902 is specifically used for: If the parent route mount point in the route mount information is empty, then the current node corresponding to the route group is generated according to the route mount information of the route group, and the current node is used as the root node of the route mount tree. If the parent route mount point in the route mount information is not empty, then the current node corresponding to the route group is generated according to the route mount information of the route group, and the parent node of the current node is determined in the route mount tree according to the parent route mount point. The current node is then added to the route mount tree as a leaf node of the parent node.

[0108] Optionally, the first extraction module 902 is specifically used for: If the parent route mount point of the routing group has a corresponding node in the route mount tree, then the node corresponding to the parent route mount point will be the parent node of the current node. If the parent route mount point of the route group does not have a corresponding node in the route mount tree, the route group is treated as a candidate root node, and the candidate root node is associated with the newly added node.

[0109] Optionally, module 904 is specifically used for: The complete path information of the API is obtained by recursively searching the route mount tree based on the current route mount point of the API. The request method, API path, processing function, and complete path information are combined into a structured routing record to obtain the target API information.

[0110] Optionally, the nodes in the route mount tree include: a list of child nodes; Module 904 is specifically used for: Traverse the nodes in the route mounting tree. For the current node, if the current route mounting point of the current node is the same as the current route mounting point of the API, then the current node is taken as a target node of the API. The path prefix of the parent node of the target node is recursively obtained, and the path prefix of the parent node and the path information of the target node are concatenated to obtain the complete path information of the API. If the current route mount point of a node in the route mount tree is different from the current route mount point of the API, then it is determined whether the current route mount point of the API is in the node's child node list. If so, the node in the child node list that contains the current route mount point of the API is taken as the target node, and the path prefix of the target node's parent node is recursively obtained. The obtained path prefix of the parent node and the path information of the target node are concatenated to obtain the complete path information of the API.

[0111] Optionally, the generation module 905 is specifically used for: Generate a query vector based on the target API information; Based on the semantic similarity between the query vector and each code vector in the code vector library, candidate query vectors corresponding to the query vector are determined. The candidate query vectors are reordered to obtain the reordering results. The reordering results are then filtered based on a preset similarity threshold to obtain multiple target query vectors. The code shards corresponding to each target query vector are then used as multiple target code shards corresponding to the API.

[0112] This application's embodiments achieve automation and intelligence in API information processing through source code parsing, route mounting tree construction, API information extraction, and semantic retrieval to generate functional descriptions. By using abstract syntax tree parsing and vectorized storage, it achieves the association of unstructured information. A large language model extracts route groups and basic API information, and the route mounting tree completes the full path, ensuring the integrity and accuracy of API information, especially in scenarios where API interface addresses are stored across files. Based on the retrieval-enhanced generation mechanism, it generates functional descriptions by associating relevant code snippets, enabling a deep understanding of the code's business intent, significantly improving the richness and semantic depth of the description, effectively reducing the burden of manual maintenance, and thus meeting the software development needs for automated and intelligent documentation.

[0113] Figure 10This illustration shows a schematic diagram of an electronic device provided in an embodiment of this application, including: a processor 1001, a storage medium 1002, and a bus 1003. The storage medium 1002 stores machine-readable instructions executable by the processor 1001. When the electronic device runs an API information processing method as described in the embodiment, the processor 1001 communicates with the storage medium 1002 via the bus 1003. The processor 1001 executes the machine-readable instructions. The preamble of the method item of the processor 1001 executes the steps in the above-described API information processing method.

[0114] This application also provides a computer-readable storage medium storing a computer program that is executed by a processor, wherein the processor performs the steps in the above-described API information processing method.

[0115] In this embodiment, the computer program, when run by the processor, can also execute other machine-readable instructions to perform other methods as described in the embodiments. For details on the specific execution steps and principles, please refer to the description of the embodiments, which will not be repeated here.

[0116] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0117] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0118] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0119] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0120] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0121] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. An API information processing method, characterized in that, include: The source code of the target application is parsed to obtain multiple code fragments and a code vector library, wherein the code vector library includes the code vectors corresponding to each code fragment; Based on the large language model, route groups are extracted from the code fragments, and a route mounting tree is constructed according to the route groups. The route mounting tree includes multiple nodes, each node is used to represent a route group, and the route mounting tree is used to describe the hierarchical relationship between route groups. Extract API information from the multiple code shards to obtain initial API information for at least one API. The initial API information includes: request method, API path, processing function, and route mount point. Based on the routing tree and the initial API information, determine the target API information for each API; The target API information for each API is retrieved from the code vector library to obtain multiple target code fragments corresponding to each API. Based on the large language model, functional description information of each API is generated according to the multiple target code fragments corresponding to each API, the target API information of each API, and a preset vocabulary definition table.

2. The method according to claim 1, characterized in that, The step of extracting route groups from the code fragments based on a large language model and constructing a route mounting tree based on the route groups includes: Based on the large language model, each code segment is judged. If the code segment contains routing information, a preset label is added to the code segment to obtain the code segment to be extracted. Based on the large language model, route groups are extracted from each of the code fragments to be extracted, and route mounting information of at least one route group in each of the code fragments to be extracted is obtained. The route mounting tree is then constructed based on the route mounting information of the at least one route group.

3. The method according to claim 2, characterized in that, The step of extracting route groups from each of the code fragments to be extracted based on the large language model, obtaining route mounting information for at least one route group in each code fragment to be extracted, and constructing the route mounting tree based on the route mounting information of the at least one route group, includes: The code fragments to be extracted are traversed. For the current code fragment to be extracted, the current code fragment to be extracted is filled into a preset prompt word template to obtain a prompt statement. The prompt statement is then input into the large language model. The large language model extracts information from the current code fragment to be extracted to obtain at least one routing group and the routing mounting information of each routing group. The routing mounting information includes: the current routing mounting point, the mounting path, the parent routing mounting point, and the child routing mounting point. Based on the routing mount information of each routing group in the current code fragment to be extracted, generate the current node corresponding to each routing group of the current code fragment to be extracted, and add the current node to the routing mount tree.

4. The method according to claim 3, characterized in that, The step of generating a current node corresponding to each route group of the current code fragment to be extracted based on the route mounting information of each route group in the current code fragment to be extracted, and adding the current node to the route mounting tree, includes: If the parent route mount point in the route mount information is empty, then the current node corresponding to the route group is generated according to the route mount information of the route group, and the current node is used as the root node of the route mount tree; If the parent route mount point in the route mount information is not empty, then the current node corresponding to the route group is generated according to the route mount information of the route group, and the parent node of the current node is determined in the route mount tree according to the parent route mount point, and the current node is added to the route mount tree as a leaf node of the parent node.

5. The method according to claim 4, characterized in that, Determining the parent node of the current node in the routing tree based on the parent route mount point includes: If the parent route mount point of the route group has a corresponding node in the route mount tree, then the node corresponding to the parent route mount point is taken as the parent node of the current node. If the parent route mount point of the route group does not have a corresponding node in the route mount tree, then the route group is regarded as a candidate root node, and the candidate root node is associated with the newly added node.

6. The method according to claim 1, characterized in that, The step of determining the target API information for each API based on the routing tree and the initial API information includes: The complete path information of the API is obtained by recursively searching the routing tree based on the current route mount point of the API. The request method, API path, processing function, and complete path information are combined into a structured routing record to obtain the target API information of the API.

7. The method according to claim 6, characterized in that, The nodes in the routing mount tree include: a list of child nodes, wherein the list of child nodes records at least one child-level routing mount point; The step of recursively searching the route mount point of the API in the route mount tree to obtain the complete path information of the API includes: Traverse the nodes in the routing tree. For the current node, if the current routing mount point of the current node is the same as the current routing mount point of the API, then the current node is taken as a target node of the API. The path prefix of the parent node of the target node is recursively obtained, and the obtained path prefix of the parent node and the path information of the target node are concatenated to obtain the complete path information of the API. If the current route mount point of a node in the route mount tree is different from the current route mount point of the API, then it is determined whether the current route mount point of the API is in the node's child node list. If so, the node in the child node list that contains the current route mount point of the API is taken as the target node, and the path prefix of the parent node of the target node is recursively obtained. The obtained path prefix of the parent node and the path information of the target node are concatenated to obtain the complete path information of the API.

8. The method according to claim 7, characterized in that, After traversing the nodes in the routing mount tree, the process also includes: If multiple current nodes have the same current route mount point as the API, then the target node of the API is determined from the current route mount points of the API based on the current route mount point of the API and the file identifier of each current route mount point.

9. The method according to claim 1, characterized in that, The target API information for each API is retrieved from the code vector library to obtain multiple target code fragments corresponding to each API, including: Generate a query vector based on the target API information of the API; Based on the semantic similarity between the query vector and each code vector in the code vector library, a candidate query vector corresponding to the query vector is determined; The candidate query vectors are reordered to obtain a reordering result. The reordering result is then filtered based on a preset similarity threshold to obtain multiple target query vectors. The code slices corresponding to each target query vector are then used as multiple target code slices corresponding to the API.

10. An electronic device, characterized in that, include: The device includes a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of an API information processing method as described in any one of claims 1 to 8.

Images