Service interface document generation method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of computer software, and discloses a service interface document generation method and device, electronic equipment and a storage medium. The method comprises the following steps: acquiring source codes and engineering structure information in a code warehouse corresponding to a target service, wherein the source codes and the engineering structure information are used for determining an analysis range of the target service; constructing and analyzing an abstract syntax tree based on the source code and the engineering structure information, identifying an entry function, analyzing a function call relationship, and forming function call chain information; obtaining interface protocol information based on a reflection mechanism after the target service is deployed; establishing an association relationship between the function call chain information and the interface protocol information and sending the association relationship to an artificial intelligence tool platform; the artificial intelligence tool platform combines the cue words and knowledge base information to generate interface annotation information; and generating a service interface document corresponding to the target service based on the interface protocol information and the interface annotation information. According to the method, automatic association generation of the interface document and the business logic is realized, and the accuracy, the consistency and the updating efficiency of the interface document are improved.

Description

Technical Field

[0001] This application relates to the field of computer software technology, and in particular to a service interface document generation method, apparatus, electronic device, and storage medium. Background Technology

[0002] In existing technologies, GRPC (Google Remote Procedure Call) API documentation typically relies on GRPC's reflection mechanism and requires developers to write complete and standardized comments in the proto protocol file to generate readable API protocol documentation. HTTP API documentation, on the other hand, often relies on frameworks like Swagger, requiring developers to manually write request parameters, response structures, and explanatory information to generate documentation conforming to the OpenAPI format. Both solutions require significant manual maintenance by developers, and the quality of comments is greatly influenced by individual habits, resulting in inconsistent documentation styles, difficulty in ensuring completeness, and document lag after API updates, leading to low overall efficiency. Moreover, existing technologies struggle to perform complete call chain-level analysis of code repositories, cannot automatically extract API meaning and behavior from business logic, and cannot automatically complete API comments or generate full documentation. Therefore, both GRPC and HTTP API documentation generation methods rely on manual writing and maintenance, resulting in low automation and failing to meet the practical needs of modern microservice systems with a large number of frequently changing APIs and the requirement for real-time document synchronization. Summary of the Invention

[0003] The main technical problem addressed by the embodiments of this application is that the generation of service interface documents in the prior art relies on manual maintenance and has a low degree of automation.

[0004] To address the aforementioned technical problems, the first technical solution adopted in this application is: providing a service interface document generation method, comprising: obtaining source code and project structure information from the code repository corresponding to the target service; constructing and analyzing an abstract syntax tree based on the source code and project structure information, identifying the entry function of the target service, parsing the function call relationship, and obtaining function call chain information; after the target service completes service deployment through continuous integration and continuous deployment processes, obtaining the current interface protocol information of the target service based on a reflection mechanism; establishing an association between the function call chain information and the interface protocol information, and sending the associated function call chain information and interface protocol information to a preset artificial intelligence tool platform; generating interface annotation information representing the business semantics of the service interface through the artificial intelligence tool platform, preset prompt words, and knowledge base information; and generating the service interface document corresponding to the target service based on the interface protocol information and the interface annotation information.

[0005] In some embodiments, an abstract syntax tree is constructed and analyzed based on source code and project structure information, including: determining the loading scope of source code in the code repository through project structure information, and loading the source code corresponding to the target service according to the loading scope; resolving the code dependencies between source code based on project structure information; and constructing an abstract syntax tree to characterize the overall structure of the source code of the target service and the relationships between functions through the code dependencies.

[0006] In some embodiments, identifying the entry function of the target service and parsing the function call relationship to obtain function call chain information includes: analyzing the function definition nodes, function call nodes, and syntax nodes representing service interface registration relationships in the abstract syntax tree; identifying the entry function of the target service based on the interface registration relationship or call relationship; parsing the called identifier corresponding to the function call node and the association relationship between the function definition node and the corresponding function call node based on the entry function to obtain function call relationship information; and constructing function call chain information representing the business execution path of the target service based on the function call relationship information.

[0007] In some embodiments, obtaining the current interface protocol information of the target service based on a reflection mechanism includes: obtaining the service identifier information and reflection access parameters of the target service, wherein the reflection access parameters include at least service address information; initiating a reflection query request to the target service through the service address information to obtain the service description information of the target service; determining the interface function list of the target service based on the service description information; performing a reflection query on each interface function in the interface function list to obtain the request parameter structure information and response parameter structure information of each interface function; and constructing structured interface protocol information to describe the service interface definition based on the request parameter structure information and response parameter structure information.

[0008] In some embodiments, interface annotation information representing the business semantics of a service interface is generated using an artificial intelligence tool platform, preset prompts, and knowledge base information. This includes: analyzing the business execution process of the target service based on the function identifier, function call order, and function call relationship in the function call chain information, and extracting business semantic features representing the business processing logic of the target service; extracting structural semantic features of the service interface based on the interface function definition, request parameter structure, and response parameter structure contained in the interface protocol information; submitting the business semantic features, structural semantic features, and preset prompts as input data to the artificial intelligence tool platform; and obtaining the interface annotation information representing the business semantics of the service interface through the artificial intelligence tool platform based on the preset prompts and knowledge base information.

[0009] In some embodiments, after generating interface annotation information representing the business semantics of the service interface, the method further includes: obtaining historical interface annotation information of multiple service interfaces; performing content verification on the text content of the historical interface annotation information, wherein the content verification is based on preset content verification rules or content constraints; and adjusting and optimizing the prompt word configuration for the artificial intelligence tool platform according to the verification result of the content verification.

[0010] In some embodiments, after the step of generating interface annotation information representing the business semantics of the service interface, the method further includes: selecting at least two different artificial intelligence models and calling at least two different artificial intelligence models in the artificial intelligence tool platform; inputting business semantic features and structural semantic features into the artificial intelligence tool platform after updating the artificial intelligence models based on the same prompt word configuration to generate candidate interface annotation information corresponding to different artificial intelligence models; performing semantic matching analysis on the different candidate interface annotation information with function call chain information and interface protocol information to obtain corresponding matching result data; and selecting the target artificial intelligence model in the artificial intelligence tool platform used to generate interface annotation information based on the matching result data.

[0011] To address the aforementioned technical problems, the second technical solution adopted in this application is: providing a service interface document generation device, comprising: a code repository acquisition module, used to acquire source code and project structure information from the code repository corresponding to the target service; a function call chain module, used to construct and analyze an abstract syntax tree based on the source code and project structure information, identify the entry function of the target service, parse the function call relationship, and obtain function call chain information; an interface protocol information module, used to acquire the current interface protocol information of the target service based on a reflection mechanism after the target service completes service deployment through continuous integration and continuous deployment processes; an association relationship construction module, used to establish an association relationship between the function call chain information and the interface protocol information, and send the associated function call chain information and interface protocol information to a preset artificial intelligence tool platform; an interface annotation information module, used to generate interface annotation information representing the business semantics of the service interface through the artificial intelligence tool platform, preset prompt words, and knowledge base information; and a service interface document module, used to generate a service interface document corresponding to the target service based on the interface protocol information and the interface annotation information.

[0012] To solve the above-mentioned technical problems, the third technical solution adopted in the embodiments of this application is: to provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the service interface document generation method as described above.

[0013] To solve the above-mentioned technical problems, the fourth technical solution adopted in the embodiments of this application is: to provide a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by an electronic device, the electronic device executes the service interface document generation method as described above.

[0014] Unlike related technologies, this application provides a service interface documentation generation method, apparatus, electronic device, and storage medium. By acquiring the source code and project structure information from the code repository corresponding to the target service, it can clearly define the code boundaries and analysis scope of the target service under a microservice architecture, avoiding analysis based solely on a single source file or incomplete code fragments. This provides a complete and accurate engineering-level input data foundation for subsequent automated code-based analysis. Based on the source code and project structure information, an abstract syntax tree is constructed and analyzed to identify the target service entry function and parse the function call relationship to obtain function call chain information. This allows for the reconstruction of the actual execution path of the service interface request in the source code from an engineering-level perspective, structurally associating business processing logic scattered across different modules and source files, establishing a clear correspondence between the service interface and its internal business implementation logic. After the target service is deployed, the current interface protocol information of the target service is obtained based on a reflection mechanism. This allows for the direct acquisition of a real and valid interface definition and parameter structure from the running service, avoiding the problems of delayed or inconsistent interface information caused by relying on manually maintained static interface descriptions. By establishing a correlation between function call chain information and interface protocol information and sending it to a pre-defined AI tool platform, the structural information at the interface definition level can be integrated with the business execution path information at the code implementation level. This allows the AI ​​tool platform to simultaneously possess interface structural constraints and business semantic context during semantic generation. By combining pre-defined prompts and knowledge base information, the AI ​​tool platform generates interface annotation information representing the business semantics of the service interface. This generates interface semantic descriptions that match the actual business processing logic while maintaining the accuracy of the interface definition, reducing the workload of manually writing interface annotations. Furthermore, by generating service interface documents corresponding to the target service based on interface protocol information and interface annotation information, service interface documents that simultaneously contain interface structural definitions and business semantic descriptions can be automatically generated. This achieves the integration of code implementation logic, runtime interface definitions, and AI semantic generation capabilities without requiring developers to manually maintain interface annotations. This automatically generates service interface documents consistent with the actual service behavior, thereby improving the automation level of the interface document generation process, the accuracy of interface semantics, and the timeliness of document updates. Attached Figure Description

[0015] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0016] Figure 1 This is a schematic diagram of the operating environment for the service interface document generation method provided in this application embodiment.

[0017] Figure 2 This is a schematic diagram of the execution flow of the service interface document generation method provided in the embodiments of this application.

[0018] Figure 3 This is a comparative example diagram showing the interface annotation information obtained through different artificial intelligence models in the service interface document generation method provided in this application embodiment.

[0019] Figure 4 This is an example diagram of the service interface document generation method provided in this application embodiment being executed in a document system.

[0020] Figure 5 This is an example diagram of a service interface document displayed in a preset graphical manner, as provided in the embodiments of this application.

[0021] Figure 6 This is a schematic diagram of the HTTP interface documentation information generated by the intelligent model provided in this application embodiment.

[0022] Figure 7 This is a schematic diagram comparing the results of semantic generation of the same interface information by different intelligent models provided in the embodiments of this application.

[0023] Figure 8 This is a schematic diagram of the system structure of the service interface document generation device provided in the embodiments of this application.

[0024] Figure 9 This is a schematic diagram of the hardware structure of an electronic device for the execution service interface document generation method provided in this application embodiment. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. Software tools, components, or servers not belonging to this company that appear in the embodiments of this application are merely illustrative examples and do not represent actual use.

[0026] It should be noted that, unless otherwise specified, the various features in the embodiments of this application can be combined with each other, all of which are within the protection scope of this application. Furthermore, although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device schematic diagram or the order in the flowchart.

[0027] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The term "and / or" as used in this specification includes any and all combinations of one or more of the associated listed items.

[0028] In traditional software development, service interfaces are typically used to define the calling methods and interaction rules between different software modules or services, forming the foundation for inter-system functional collaboration and data exchange. To facilitate correct understanding of interface functions, parameter meanings, and return results by interface callers, service interface documentation, as a descriptive representation of the service interface, is usually a crucial basis for interface calls and system integration. Its generation primarily relies on manual writing and maintenance during the development phase. For gRPC-based service interfaces, traditional technologies generally obtain interface definition information by enabling gRPC's reflection mechanism and rely on developers to pre-write relatively complete comments in the proto protocol file to generate readable interface documentation. For HTTP-based service interfaces, frameworks like Swagger are often used, with developers manually configuring request parameters, return structures, and interface description information to generate interface documentation conforming to the OpenAPI specification. Both methods rely heavily on manual configuration and maintenance, and the accuracy and completeness of the documentation content heavily depend on the developers' experience and writing habits, making it difficult to ensure a unified and standardized interface documentation style across different projects or teams.

[0029] Meanwhile, in microservice architectures with an ever-increasing number of interfaces and increasingly complex business logic, service interfaces not only describe the form of interface calls but also need to accurately reflect the processing logic and behavioral semantics of the interface in specific business scenarios. However, related interface documentation generation solutions typically only focus on information at the interface definition level, making it difficult to analyze in conjunction with the actual business implementation logic in the code repository. They cannot perform systematic call chain-level analysis of function call relationships, nor can they automatically extract the true semantics and behavioral meaning of the interface from the business execution path within the service. After interface changes or business logic adjustments, interface documentation often requires manual synchronization, which can easily lead to outdated documentation, inconsistent descriptions, or even missing information. The degree of automation is low, making it difficult to meet the actual needs of microservice systems with large-scale interfaces, frequent iterations, and the requirement for real-time synchronized documentation updates.

[0030] In view of this, this application proposes a service interface documentation generation method. The specific concept includes: First, obtaining the source code and project structure information from the code repository corresponding to the target service, performing overall parsing of the code repository, and constructing an abstract syntax tree based on the source code and project structure information to identify the entry function corresponding to the service interface, and parsing the call relationships between functions to form function call chain information representing the business execution path of the service interface; Second, after the target service is deployed and running through continuous integration and continuous deployment processes, obtaining the current interface protocol information of the target service based on a reflection mechanism, and establishing an association between the function call chain information and the interface protocol information; Third, inputting the associated function call chain information and interface protocol information into an artificial intelligence tool platform, and combining preset prompts and knowledge base information to analyze the business semantics of the service interface, generating interface annotation information representing the business semantics of the service interface; Finally, automatically generating the service interface documentation corresponding to the target service based on the interface protocol information and interface annotation information, thereby achieving automatic generation and dynamic updating of interface documentation, improving the consistency between interface documentation and actual business implementation logic, reducing manual maintenance costs, and being suitable for application scenarios with a large number of interfaces and frequent changes under a microservice architecture.

[0031] To facilitate understanding of this embodiment, a service interface document generation method disclosed in this application embodiment will first be described in detail. Please refer to [link to relevant documentation]. Figure 1 , Figure 1 This is a schematic diagram of the runtime environment for the service interface documentation generation method provided in this application embodiment, such as... Figure 1 As shown, the execution subject of the service interface document generation method provided in this application embodiment is generally an electronic device with a certain computing power, such as a computer device. In some possible implementations, this service interface document generation method can be implemented by a processor calling computer-readable instructions stored in memory. Figure 1The computer equipment mentioned can be a server. A server can be a standalone server or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. It is understandable that... Figure 1 The number of computer devices shown is merely illustrative and can be expanded in any number according to actual needs.

[0032] Please continue reading. Figure 2 , Figure 2 This is a schematic diagram of the execution flow of the service interface document generation method provided in the embodiments of this application, such as... Figure 2 As shown, it includes the following steps: S1. Obtain the source code and project structure information from the code repository corresponding to the target service.

[0033] In this embodiment, step S1 is used to obtain the source code and project structure information from the code repository corresponding to the target service. This is a foundational step for subsequent abstract syntax tree analysis and function call chain construction. The target service refers to a specific service unit in a microservice architecture that requires the generation of service interface documentation. It typically has an independent set of interfaces and business implementation logic, and provides service capabilities externally through continuous integration and continuous deployment processes. The code repository is a version management repository used to store and manage the source code of the target service, containing all source code files implementing the service interfaces and business logic. The project structure information describes the organization of the source code in the code repository and the project configuration relationships, including the source code directory structure, module or package division, and dependencies. By obtaining the source code and project structure information, the analysis scope of the target service can be clarified, and the necessary project-level context can be provided for subsequent construction of the abstract syntax tree and parsing of function call relationships across files and modules, thereby ensuring the completeness and accuracy of the function call chain analysis.

[0034] S2. Based on the source code and project structure information, construct and analyze the abstract syntax tree, identify the entry function of the target service, parse the function call relationship, and obtain the function call chain information.

[0035] Traditional methods of generating API documentation typically rely solely on API definitions or manual annotations, making it difficult to reflect the actual processing flow and semantic behavior of APIs in business scenarios. This results in semantic gaps, inconsistent descriptions, and delayed updates. The function call chain information obtained in step S2 provides verifiable business logic for subsequent semantic extraction and annotation generation. This allows API documentation generation to move beyond simply describing the API structure and instead generate semantic descriptions based on real business execution paths. This fundamentally supports automatic extraction of API meaning, automatic completion of API annotations, and synchronized document updates with code changes. It effectively addresses the issues of low automation levels and difficulty in generating documentation that integrates with business implementation logic.

[0036] As an optional implementation, the process of obtaining the abstract syntax tree by performing the above step S2 may also specifically include the following steps S21 to S23.

[0037] S21. Determine the loading scope of the source code in the code repository through the project structure information, and load the source code corresponding to the target service according to the loading scope.

[0038] The technical objective of step S21 is to provide a complete and consistent project context for the subsequent construction of the abstract syntax tree. Project structure information describes the organization of source code in the code repository, the division of modules or packages, and the build configuration. By parsing the project structure information, it can be determined which directories, modules, or packages belong to the implementation scope of the target service, and which dependent modules need to be loaded as the analysis context. In a microservice architecture, the target service often exists as an independent project or module. If only a simple file-level traversal of the code repository is performed, problems such as missing dependent modules, loading irrelevant code, or missing generated code can easily occur, thus affecting the completeness of subsequent syntax analysis. By limiting the loading scope of source code based on project structure information and loading the corresponding source code, it can be ensured that the abstract syntax tree construction process unfolds from a complete and correct project-level perspective.

[0039] S22. Analyze the code dependencies between source codes based on the project structure information.

[0040] After the source code loading is complete, step S22 establishes the reference relationships between source files, modules, and packages. Code dependencies include module dependencies, package dependencies, and source file import relationships. By combining the module boundaries, dependency declarations, and build rules defined in the project structure information, the attribution relationships and reference paths of functions, types, and interfaces in different modules or packages can be resolved. By resolving code dependencies, the abstract syntax analysis process can understand symbolic references and cross-module call relationships at the project level, rather than being limited to the syntax structure within a single source file. Simultaneously, the code dependency resolution process imposes requirements on the project standardization of the code repository, such as complete dependency declarations and resolvable import paths, to ensure the accuracy of the dependency resolution results.

[0041] S23. Construct an abstract syntax tree through code dependencies to represent the overall structure of the source code of the target service and the relationships between functions.

[0042] An abstract syntax tree (AST) is a data structure that represents the syntactic structure of source code in a tree-like format. Each node corresponds to a syntactic element in the source code (such as function definitions, variable declarations, and expressions). During construction, the AST combines cross-file and cross-module dependencies, unifying syntactic nodes distributed across different source files into a single structured representation. This allows it to simultaneously express the syntactic structure within a source file and the relationships between syntactic nodes related to function definitions, function calls, and service interface registration. Through an engineering-level AST structure, a unified data foundation can be provided for subsequent identification of target service entry functions, parsing function call relationships, and constructing function call chain information, thereby supporting a complete analysis of the service interface's business execution path.

[0043] Through steps S21 to S23, a complete analysis of the code repository corresponding to the target service can be performed from an engineering-level perspective. Based on a clear understanding of the source code loading scope and code dependencies, an abstract syntax tree is constructed that represents the overall structure of the target service's source code and the relationships between functions. This abstract syntax tree not only accurately reflects the syntactic structure and dependencies between different source files and modules, but also provides a unified data foundation for subsequent identification of service interface entry functions and parsing of function call relationships across files and modules. This ensures the completeness and accuracy of function call chain information, avoids deviations in business execution path analysis due to missing project structure or incomplete dependency parsing, and lays a reliable data foundation for subsequent service interface semantic analysis and interface documentation generation.

[0044] As another optional implementation, the process of obtaining function call chain information by performing the above step S2 may also specifically include the following steps S24 to S26.

[0045] S24. Analyze the function definition nodes, function call nodes, and syntax nodes representing service interface registration relationships in the abstract syntax tree, and identify the entry function of the target service based on the interface registration relationship or call relationship.

[0046] In this embodiment, the abstract syntax tree includes function definition nodes, function call nodes, and syntax nodes representing service interface registration relationships. Function definition nodes represent the declaration and implementation of functions in the source code, including function name, parameters, return value, and module / file location; function call nodes represent the calling relationships of functions in the source code; and syntax nodes represent the registration, exposure, or binding relationships of microservice interfaces, used to determine which functions directly expose service capabilities.

[0047] After constructing the abstract syntax tree, step S24 above determines the entry function that provides external service capabilities in the target service. This entry function is the starting point for the target service to process external requests and corresponds to the actual business execution logic of the service interface. Service interfaces are typically associated with function implementations in the source code through specific registration methods, such as interface registration statements, route binding relationships, or framework-defined interface mapping rules. Interface registration statements, route binding relationships, or framework-defined interface mapping rules are all concrete manifestations of interface registration or call relationships in the source code. These registration or call relationships correspond to specific syntax nodes in the abstract syntax tree. The process of identifying the entry function is achieved by analyzing the function definition nodes, function call nodes, and syntax nodes in the abstract syntax tree. Specifically, the analysis includes: establishing a mapping relationship between interfaces and processing functions by parsing the syntax nodes in the abstract syntax tree; tracing the call chain between functions using function call nodes to identify the logical path of direct or indirect calls from interface functions; and obtaining function implementation information using function definition nodes to confirm the function's position in the business logic, thereby accurately identifying the entry function of the target service and providing a reliable starting point for subsequent function call relationship parsing and business execution path analysis.

[0048] S25. Based on the entry function, parse the relationship between the called identifier corresponding to the function call node, the function definition node and the corresponding function call node to obtain the function call relationship information.

[0049] After identifying the entry function, complete function call relationship information can be obtained through step S25 above. This information reflects the call direction, call level, and call order between functions. By parsing the matching relationship between the called identifier and the function definition node, function call statements can be mapped to specific function implementation locations. This process not only covers function call relationships within a single source file but also combines the cross-file and cross-module syntax node associations in the abstract syntax tree to parse cross-module function call relationships, thus forming a complete and traceable set of function call relationships.

[0050] S26. Based on the function call relationship information, construct the function call chain information that represents the business execution path of the target service.

[0051] The function call chain information connects multiple function calls in the order they are triggered by the entry function, forming a call path representation that reflects the business processing flow. This information provides a clear picture of how the service interface processes a request, the order in which business logic unfolds, and the collaborative relationships between key functions. This structured business execution path foundation is then used to extract the service interface's business semantic features, generate interface annotations, and build service interface documentation.

[0052] Through steps S24 to S26 above, based on the unified structured representation provided by the abstract syntax tree, the entry function carrying the external service capabilities in the target service can be accurately located. Using the entry function as the starting point, the call relationships between functions are parsed, thus forming function call chain information that reflects the business processing of the target service. This function call chain information allows for the reconstruction of the actual execution path of service interface requests in the business system from the code implementation level, clarifying the call order and collaboration relationships of each functional function in the business process. This ensures that the service interface is no longer merely described at the interface definition level, but establishes a clear correspondence with the specific business implementation logic. This provides a reliable data foundation for subsequent extraction of business semantic features based on the function call chain, generation of semantic interface annotations, and construction of service interface documentation that accurately reflects business behavior.

[0053] In addition, to achieve automated generation and consistent maintenance of interface documentation for different interface protocol types, precise interface-level analysis can be performed on the code repository based on abstract syntax trees to obtain complete function call chain information associated with the interface. Combined with the interface business logic code and the capabilities of artificial intelligence tool platforms, semantic interface annotations can be generated for GPRS interfaces, and complete interface documentation can be generated for HTTP interfaces. Simultaneously, the generation process is linked with continuous integration and continuous deployment processes, enabling automatic updates to interface documentation after service deployment, improving the real-time nature and readability of the documentation.

[0054] In some embodiments, the function call chain parsing logic for the GRPC interface and the HTTP interface can be consistent, both starting with the entry function and recursively parsing function definitions and function call relationships based on the abstract syntax tree to reconstruct the interface processing flow. However, the difference lies in the characteristics of the abstract syntax tree of the entry function. The GRPC interface focuses on the characteristics of the entry function pointed to by the syntax nodes related to service registration and method binding, while the HTTP interface focuses on the characteristics of the entry function pointed to by the syntax nodes related to route registration and processor binding. Therefore, different entry identification rules are adopted for different protocol types during the entry location phase. Furthermore, to adapt to the common dependency injection organization methods in the target project framework, the syntax nodes related to injection, binding, provider registration, or implementation mapping can also be identified and parsed during the function relationship chain analysis process to establish a mapping relationship between the injected object and the specific implementation. During call chain reconstruction, the specific implementation function corresponding to the injected object is included in the function chain to avoid missing links in injection scenarios and improve the completeness and accuracy of function call chain information.

[0055] In other embodiments, the generation targets and input elements for different protocol types are further differentiated. For HTTP interfaces, in addition to function chain information, routing metadata such as interface type, request route, and request method corresponding to the HTTP entry function registration relationship is additionally parsed, and interface documentation conforming to the OpenAPI specification is generated based on the function chain information and routing metadata. For gRPC interfaces, semantic interface annotation information is generated based on function chain information and interface protocol information obtained through reflection, used to complete and update interface descriptions. Moreover, different prompt words and knowledge base information are configured for HTTP and gRPC interfaces respectively to match their respective generation targets and output structure requirements.

[0056] This embodiment employs differentiated entry point identification for different interface types and relies on link completion and differentiated generation strategies based on injection scenarios. For GRPC interfaces, it automatically completes semantic interface comments by combining protocol information and function call chains obtained through reflection, improving comment consistency and readability. For HTTP interfaces, it additionally parses metadata such as routing and request methods, automatically generating complete interface documentation conforming to the OpenAPI specification, ensuring that the documentation elements are complete and easy to use. This reduces missing links and analysis biases, and can be integrated with CI / CD (Continuous Integration / Continuous Deployment) to achieve rapid automatic updates of interface documentation after deployment, improving the real-time performance and readability of the documentation.

[0057] S3. After the target service completes service deployment through continuous integration and continuous deployment processes, obtain the current interface protocol information of the target service based on the reflection mechanism.

[0058] Traditional methods of generating interface documentation typically rely on static protocol files or manually maintained interface descriptions. When the interface implementation or deployment version changes, the interface documentation is prone to lag or inconsistency. Step S3 directly obtains the interface function definitions and parameter structure information from the running target service. This accurately reflects the current valid interface state of the target service, providing accurate and real-time interface definitions for subsequent interface semantic analysis and documentation generation. This solves the technical problems of inconsistency between interface documentation and the actual running state of the service, and the reliance on manual maintenance for updates.

[0059] In practical implementation, once the service repository code commit triggers the Continuous Integration (CI) and Continuous Deployment / Delivery (CD) processes, the target service is deployed and launched, and the documentation system receives an update notification. Subsequently, the documentation system accesses the running service through reflection to obtain the latest interface definition information, including interface functions, parameter structures, and return value types.

[0060] As an optional implementation, the process of obtaining interface protocol information based on reflection mechanism in step S3 above may also specifically include the following steps S31 to S35.

[0061] S31. Obtain the service identifier information and reflection access parameters of the target service. The reflection access parameters shall include at least the service address information.

[0062] Service identification information is used to uniquely identify the target service instance, enabling the interface protocol information acquisition process to accurately correspond to a specific service. Service address information indicates the access location of the target service in the runtime environment, providing the foundation for establishing communication with the target service through reflection. By obtaining service identification information and reflection access parameters, dynamic interface information of the target service can be obtained after the service is deployed and running, without relying on static configuration files or manually maintained interface descriptions.

[0063] S32. Initiate a reflection query request to the target service using the service address information to obtain the service description information of the target service.

[0064] Service description information describes the service capabilities provided by the target service, including the service name, service interface definition, and the organizational structure of the interface methods. Through reflection queries, service description information can be dynamically retrieved from the running target service without intruding on its business logic. This allows the interface protocol information retrieval process to reflect the current actual interface status provided by the target service in real time.

[0065] S33. Determine the list of interface functions for the target service based on the service description information.

[0066] The interface function list describes all interface function identifiers and names supported by the target service, and serves as the foundation for subsequently obtaining interface parameter structure information. Generating the interface function list by parsing the service description information avoids manually enumerating interface methods, ensuring that the interface function list is consistent with the interfaces actually provided by the target service at runtime.

[0067] S34. Perform reflection query on each interface function in the interface function list to obtain the request parameter structure information and response parameter structure information of each interface function.

[0068] The request parameter structure information describes the composition, type, and hierarchy of the input parameters required when calling the interface function. The response parameter structure information describes the structure and data type of the return result from the interface function. By performing reflection queries on each interface function, the parameter structure definitions of all interface functions of the target service can be comprehensively obtained, providing a complete data source for constructing interface protocol information. S35. Based on the request parameter structure information and the response parameter structure information, construct structured interface protocol information to describe the service interface definition.

[0069] Structured interface protocol information is used to describe interface function identifiers, request parameter structures, and response parameter structures in a unified data structure format. This gives the interface definition information structured and parsable characteristics, thus providing a standardized data foundation for subsequently associating interface protocol information with function call chain information and generating service interface documents based on interface protocol information.

[0070] Through steps S31 to S35 above, assuming the target service is deployed and running, complete and accurate interface definition information is dynamically obtained from the running service based on reflection, and the interface protocol information of the target service is constructed in a structured form. The interface protocol information obtained in this way accurately reflects the interface functions and parameter structures currently provided by the target service, avoiding the lag and inconsistencies caused by relying on static protocol files or manually maintaining interface descriptions. It also provides a reliable data source for subsequently associating interface protocol information with function call chain information, extracting interface business semantics, and generating service interface documentation, thereby improving the automation level of the interface documentation generation process and the accuracy of the interface description.

[0071] S4. Establish the association between function call chain information and interface protocol information, and send the associated function call chain information and interface protocol information to the preset artificial intelligence tool platform.

[0072] By establishing a correlation between function call chain information and interface protocol information, a corresponding mapping relationship is formed between information at the interface definition level and the business execution path at the code implementation level. This provides a complete and understandable contextual basis for subsequent interface semantic analysis. Function call chain information reflects the actual business processing flow of the service interface in the source code, while interface protocol information describes the call format, parameter structure, and return structure of the service interface. Relying solely on interface protocol information is insufficient to reflect the behavioral semantics of the interface in specific business scenarios, while relying solely on function call chain information lacks a structured description of the interface call rules. Therefore, by establishing a correlation between the two, the interface definition and business implementation logic can be organically combined, enabling subsequent processing to analyze both "how the interface is called" and "what the interface actually does."

[0073] After establishing the association, the associated function call chain information and interface protocol information are sent to a pre-defined AI tool platform. The AI ​​tool platform then performs joint semantic analysis on the structured interface definition information and business execution path information to generate interface annotation information representing the business semantics of the service interface. The AI ​​tool platform provides natural language understanding and generation capabilities, combining prompt words and knowledge base information to perform semantic modeling and text generation on the input structured data, thereby achieving automatic generation of interface annotations. Simultaneously, the AI ​​tool platform supports configuring and calling different AI models, switching or replacing between different models to adapt to different business scenarios, language styles, or generation quality requirements, thereby improving the flexibility and scalability of the interface annotation generation process.

[0074] S5. Generate interface annotation information that represents the business semantics of the service interface through artificial intelligence tool platform, preset prompt words and knowledge base information.

[0075] Traditional methods of generating API documentation primarily rely on manual annotation, which makes it difficult to systematically understand the behavioral semantics of APIs in actual business scenarios, and the quality of annotations is greatly affected by individual experience. Step S5 utilizes an artificial intelligence tool platform to jointly model business semantic features and structural semantic features, automatically generating API annotation information under the constraints of prompt words and the assistance of a knowledge base. This achieves automatic extraction and standardized expression of API business semantics, specifically addressing the problems of high manual maintenance costs, semantic inconsistencies, and difficulty in updating API annotations in sync with business changes.

[0076] As an optional implementation, the process of generating interface annotation information in step S5 above may also specifically include the following steps S51 to S54.

[0077] S51. Based on the function identifier, function call order, and function call relationship in the function call chain information, analyze the business execution process of the target service and extract business semantic features that represent the business processing logic of the target service.

[0078] Step S51 specifically includes parsing the hierarchical position of functions in the call chain, the order of calls, and the branching of call paths. Function identifiers are used to distinguish different business processing functions, function call order reflects the execution sequence of business processing flows, and function call relationships describe the collaboration between various business processing functions. By comprehensively analyzing the above information, the processing process of the service interface after receiving a request can be abstracted into one or more business execution paths, and the corresponding function sets in the call chain for different business processing stages such as request verification, business processing, data access, and result assembly can be identified. Based on this, information reflecting the purpose, steps, and logical characteristics of business processing is extracted from the call chain to form business semantic features that characterize the business processing logic of the target service. Using the above analysis and extraction method, the meaning of the interface can be inferred from the interface name or parameter definition alone. It accurately reflects the real business behavior of the interface from the actual execution path of the source code, so that the subsequent interface annotation generation process is based on the business implementation logic, thereby improving the consistency and credibility between the generated interface annotations and the actual business processing process.

[0079] S52. Extract the structural semantic features of the service interface based on the interface function definitions, request parameter structures, and response parameter structures contained in the interface protocol information.

[0080] The interface function definition identifies the entry point and method name of the service interface. Parsing the interface function definition determines the functional boundaries and calling objects of the service interface. The request parameter structure describes the composition, hierarchy, and parameter types of the input parameters during the interface call. Analyzing the request parameter structure extracts structural features reflecting the interface input constraints and data organization. The response parameter structure describes the data composition and field hierarchy of the interface return results. Analyzing the response parameter structure extracts structural features reflecting the interface output content and return data organization. Through comprehensive analysis of the interface function definition, request parameter structure, and response parameter structure, structural semantic features characterizing the service interface call rules and data interaction forms can be formed. Using this extraction method, the subsequent interface annotation generation process accurately understands the structural characteristics of the interface at the call level, complementing the business semantic features extracted based on the function call chain. This avoids generating interface annotations that only describe business meaning while ignoring interface parameters and return structures, improving the usability and accuracy of interface annotations in actual call scenarios.

[0081] S53. Submit the business semantic features, structural semantic features, and preset prompt words as input data to the artificial intelligence tool platform.

[0082] After extracting business semantic features and structural semantic features, these features, along with pre-defined prompts, are submitted as input data to the AI ​​tool platform. This guides the platform in performing unified analysis and generation of service interface semantics. Business semantic features express the business processing logic of the service interface at the source code implementation level, while structural semantic features express the interface definition at the call level. Pre-defined prompts constrain and guide the AI ​​tool platform's generation process, ensuring that the platform outputs content related to the interface's functional description, business processing flow, and parameter meanings, avoiding the generation of information irrelevant to or deviating from the interface definition. By combining prompts with structured feature information, the controllability and consistency of the generated interface annotations in terms of content structure and expression can be improved.

[0083] S54. Using an artificial intelligence tool platform, based on preset prompts and knowledge base information, obtain interface annotation information that represents the business semantics of the service interface.

[0084] After receiving input data, the AI ​​tool platform combines preset prompts and knowledge base information to perform semantic modeling and text generation processing on business semantic features and structural semantic features, thereby generating interface annotation information that represents the business semantics of the service interface. The knowledge base information provides the AI ​​tool platform with background knowledge and example references to aid understanding. This knowledge base information can include framework code examples related to the service interface implementation, general business processing patterns, interface design specifications, or historical interface annotation samples, and is not limited to a specific organization or project. By introducing knowledge base information, the AI ​​tool platform can combine existing practical experience and general design patterns when generating interface annotations, enabling more accurate semantic mapping of business semantics and interface structure, reducing reliance on single code features, and thus improving the accuracy and standardization of the semantic expression of the generated interface annotations.

[0085] Through steps S51 to S54, based on the function call chain information and interface protocol information, semantic analysis is performed on the service interface from two levels: business implementation logic and interface structure. Guided by preset prompts and knowledge base information, interface annotation information that accurately reflects the business meaning of the service interface is generated. By simultaneously incorporating business semantic features and structural semantic features into the generation process of the artificial intelligence tool platform, interface annotations can avoid being inferred solely from interface definitions or code snippets. This results in more complete and accurate descriptions of interface functions, business processing logic, and parameter meanings, providing a reliable semantic foundation for the subsequent generation of highly readable and consistent service interface documentation.

[0086] In some embodiments, after generating interface annotation information representing the business semantics of the service interface in step S5, the configuration of prompt words corresponding to the artificial intelligence tool platform can be optimized, specifically including the following steps S551 to S553.

[0087] S551. Obtain historical interface annotation information for multiple service interfaces.

[0088] S552. Perform content validation on the text content of historical interface annotation information. The content validation is based on preset content validation rules or content constraints.

[0089] S553. Based on the content verification results, adjust and optimize the prompt word configuration used in the artificial intelligence tool platform.

[0090] During the generation of interface annotation information, the output of the AI ​​tool platform is significantly affected by the configuration of prompt words. Furthermore, the text content generated under different interfaces and business scenarios may exhibit non-standard expressions, redundancy, or failure to meet expected constraints. Therefore, it is necessary to continuously validate and optimize the generated interface annotation information. To this end, historical interface annotation information generated for multiple service interfaces can be obtained, and its text content can be validated. Content validation can be performed based on preset content validation rules or constraints, such as checking whether the interface annotation contains field descriptions that do not conform to the interface definition, whether it contains descriptions irrelevant to the business, and whether it conforms to established interface documentation writing specifications or terminology usage rules. After completing the content validation, the prompt word configuration used by the AI ​​tool platform can be adjusted accordingly based on the validation results. For example, the parts of the prompt words used to limit the generation scope, semantic focus, or output format can be corrected to guide subsequent interface annotation generation processes to better meet actual needs. By adopting the above methods, a prompt word optimization mechanism based on historical generation results can be formed, enabling the artificial intelligence tool platform to gradually improve the standardization and applicability of the generated interface annotations during continuous use, reducing the probability of abnormal or unexpected content, thereby improving the stability and overall quality of the interface annotation generation process.

[0091] In some other embodiments, after generating interface annotation information representing the business semantics of the service interface in step S5, the artificial intelligence model in the artificial intelligence tool platform can be optimized, specifically including the following steps S561 to S564.

[0092] S561. Select at least two different artificial intelligence models and call the at least two different artificial intelligence models respectively in the artificial intelligence tool platform.

[0093] S562. Based on the same prompt word configuration, input the business semantic features and structural semantic features into the AI ​​tool platform after updating the AI ​​model to generate candidate interface annotation information corresponding to different AI models.

[0094] S563. Perform semantic matching analysis on different candidate interface annotation information, function call chain information, and interface protocol information to obtain the corresponding matching result data.

[0095] S564. Based on the matching result data, filter the target artificial intelligence models used to generate interface annotation information in the artificial intelligence tool platform.

[0096] During the interface annotation generation process, different artificial intelligence models differ in model structure, training corpus, and semantic modeling capabilities. For the same service interface, the interface annotations generated by different artificial intelligence models may vary significantly in terms of the completeness of business description, semantic fit, and structural expression. To improve the matching degree between the interface annotation generation results and the actual business implementation logic and interface definition, this implementation method introduces a multi-model comparison and screening mechanism. By configuring and calling multiple artificial intelligence models in the artificial intelligence tool platform, parallel generation and analysis are performed on the same business semantic features and structural semantic features. For example, models focusing on code semantic understanding and models focusing on natural language expression can be used respectively to generate interface annotation content under the same prompt word constraints. Combined with function call chain information and interface protocol information, the accuracy of the generated text in reflecting the business execution path and whether it correctly describes the interface function and parameter structure can be compared and analyzed. After completing the semantic matching analysis of the generation results of different models, the artificial intelligence model whose generation results better meet the needs of interface documentation is selected as the target model for subsequent interface annotation generation processes. By adopting the above methods, we can avoid the generation deviation caused by a single artificial intelligence model in a specific business scenario, make the interface annotation generation process more adaptable and stable, and thus improve the overall quality of service interface documents in terms of business semantic expression and interface description.

[0097] As an example, please refer to Figure 3 , Figure 3 This is a comparative example diagram showing the interface annotation information obtained through different artificial intelligence models in the service interface documentation generation method provided in this application embodiment. For example... Figure 3 As shown, for the same service interface, under the conditions of the same interface protocol information, function call chain information, and the same prompt word configuration, multiple different artificial intelligence models are invoked to generate corresponding interface annotation information, and the interface annotation content generated by each artificial intelligence model is displayed in parallel. Figure 3Using interface methods as the operational dimension, this paper showcases examples of interface annotation text generated by different AI models in various columns. These models exhibit varying generation results in terms of interface function description, business process explanation, parameter meaning interpretation, and the level of detail in language expression. Some AI models focus on the structural explanation of interface input parameters and return results, while others emphasize semantic description of the interface's purpose in conjunction with business processing logic. Still others show differences in text organization and completeness of expression. By comparing and displaying the interface annotation information generated by different AI models, the differences in their performance in interface semantic understanding and text generation can be intuitively reflected, providing a reference for subsequent selection of target AI models for generating interface annotation information based on semantic matching analysis results.

[0098] S6. Based on the interface protocol information and interface annotation information, generate the service interface document corresponding to the target service.

[0099] As an example, please refer to Figure 4 , Figure 4 This is an example diagram illustrating the execution of the service interface documentation generation method provided in this application within a documentation system. This documentation system is specifically designed for generating service interface documentation and is used to interface with different development projects. Figure 4 As shown, the documentation system executes the process of generating service interface documentation and displays the generated documentation in a pre-defined graphical format within the system. The code repository stores the source code corresponding to the target service. The documentation system retrieves the source code and project structure information from the code repository and performs abstract syntax tree analysis on the code repository to extract function call chain information representing the service interface's business execution path. The source code in the code repository is deployed through continuous integration and continuous deployment processes to form the corresponding service application. After deployment, the service application sends a deployment update notification to the documentation system. The documentation system uses the reflection capabilities provided by the service application to obtain the updated interface protocol information. Based on this, the documentation system associates the function call chain information with the interface protocol information and sends the associated interface function information and service-related information to an artificial intelligence tool platform. The artificial intelligence tool platform performs semantic analysis on the interface functions and service information, generating interface annotation information and service interface documentation. Finally, the documentation system manages and displays the generated interface annotation information and interface documentation in a unified manner.

[0100] As another example, please continue reading Figure 5 , Figure 5 This is an example diagram of a service interface document displayed in a preset graphical manner, as provided in the embodiments of this application. For example... Figure 5As shown, the example interface displays the interface documentation generated for a specific service interface, including basic interface information, request parameter descriptions, and return parameter descriptions. This interface corresponds to a specific service method identifier, supports access via remote invocation, and the documentation page clearly distinguishes between the request parameter area and the return parameter area. The request parameter area lists multiple request fields, such as entry identifier, field set parameters, product identifier, sales identifier, and scenario identifier, with each field labeled with its corresponding parameter type, such as string or array. Semantic annotations generated by an AI tool platform are also provided for each request field, explaining its meaning and usage in the business scenario. The return parameter area demonstrates the data structure returned by the interface, including the return field names and their corresponding data types, along with explanatory annotations explaining the business meaning of the returned results. This presentation format clearly demonstrates the effectiveness of the service interface documentation generated based on interface protocol information and business semantic analysis in terms of field description and business explanation.

[0101] As yet another example, please continue reading Figure 6 , Figure 6 This is a schematic diagram of the HTTP interface documentation information generated by the intelligent model provided in this application embodiment. For example... Figure 6 As shown, based on the abstract syntax tree analysis of the target code repository, the entry registration relationship of the HTTP interface is first located in the route registration file, and the entry processor identifier information, interface type information, and route metadata are extracted. For example, Figure 6 The document provides the processor name, the request type (HTTP), the route registration file name, and the request path parsed from the route registration statement. It also retains code snippets related to this route registration to provide context for subsequent semantic understanding. Furthermore, it parses and summarizes the structure definition information related to the interface from the interface implementation logic code to form a data structure description of the request and response. For example, Figure 6 The example provides field names and annotations for the request and response structures to support automatic explanations of parameter meanings and formats. After organizing the entry processor identifier, routing metadata, code snippets, and request and response structure information into structured input, the intelligent model, with the assistance of prompt word constraints and knowledge base information, outputs interface documentation. This interface documentation includes at least interface usage instructions, interface routing, request methods, request and response parameter formats, and field descriptions. Thus, based on the reuse of function chain analysis results, it achieves the automatic generation and updating of complete and structurally standardized interface documentation for HTTP interfaces.

[0102] As yet another example, please continue reading Figure 7 , Figure 7 This is a comparative diagram showing the results of different intelligent models providing embodiments of this application generating semantic representations of the same interface information. For example... Figure 7 As shown in the figure, the differences in the generation results of the same interface under different intelligent models are presented in tabular form, and the final hybrid output results are given. This facilitates a visual observation of the differences between different models in terms of understanding the interface's purpose, coverage of key information, expression structure and readability, as well as the effect of the hybrid strategy on improving output quality. Specifically, Figure 7 The left side of the page displays the interface name and the original interface description information, which provide the basic context of the interface. The middle area corresponds to the generated result columns of multiple intelligent models. Each column displays the text content such as the interface purpose description, key input parameters, and supplementary business semantics output by the same interface under different model inference. The right side is the final result (hybrid) column, which displays the target output formed after screening, fusion, and normalization of the candidate results of multiple models.

[0103] by Figure 7 Taking the example interfaces getComboBySaleId and getSaleInfoByEntry as examples, different models have different focuses in extracting interface semantics. Some models tend to provide a brief explanation of the purpose, some models supplement with more complete meanings of input parameters and clues to business processing logic, and some models are more in line with document-style expression in terms of expression structure. The final result is listed after the comprehensive candidate results, which usually balances semantic accuracy and information completeness, making the output closer to the descriptive text that can be directly used for interface comments or interface documentation.

[0104] also, Figure 7 The final results column uses labels to identify the candidate model sources or fusion order referenced in the mixed results, indicating that the final text is not the output of a single model, but is generated by combining multiple model candidate results.

[0105] Based on the above comparison and hybrid mechanism, the complementary advantages of multiple models can be introduced in the generation stage, and the candidate results can be constrained and formatted in the post-processing stage. For example, the coverage of key interface elements can be verified, the consistency between input parameter names and business semantics can be checked, and redundant and ambiguous expressions can be compressed and resolved. This results in an interface description output with more stable semantics, clearer structure, and adaptability to documented scenarios, providing reliable input for subsequent interface annotation completion or interface documentation generation.

[0106] The service interface documentation generation method provided in this application performs engineering-level parsing of the code repository corresponding to the target service, constructs function call chain information by combining abstract syntax tree analysis, and dynamically obtains interface protocol information based on reflection mechanism after the service is deployed and running. It associates the interface definition layer information with the business execution path of the code implementation layer, and then uses an artificial intelligence tool platform to jointly analyze and generate semantics based on business semantic features and structural semantic features, thereby achieving automated generation of service interface comments and service interface documentation. Through the above technical solution, the generated service interface documentation can not only accurately reflect the parameter structure and return structure of the interface function, but also truly reflect the processing logic and behavioral semantics of the interface in actual business scenarios, avoiding the lag and inconsistency problems caused by the reliance on manual writing and maintenance of traditional interface documentation. At the same time, by introducing a prompt word optimization mechanism and a multi-model comparison and filtering mechanism, the standardization, adaptability, and stability of the interface comment generation results can be continuously improved, reducing manual maintenance costs and increasing the efficiency of interface documentation generation. It is suitable for application scenarios with a large number of interfaces and frequent iterations under a microservice architecture, and overall improves the accuracy, readability, and practical value of service interface documentation.

[0107] Please continue reading. Figure 8 , Figure 8 This is a schematic diagram of the system structure of the service interface document generation device provided in the embodiments of this application, such as... Figure 8 As shown, the service interface documentation generation device 60 includes: a code repository acquisition module 61, a function call chain module 62, an interface protocol information module 63, an association relationship construction module 64, an interface comment information module 65, and a service interface documentation module 66.

[0108] The code repository acquisition module 61 is specifically used to acquire the source code and project structure information from the code repository corresponding to the target service. The function call chain module 62 is specifically used to construct and analyze an abstract syntax tree based on the source code and project structure information, identify the entry function of the target service, parse the function call relationship, and obtain the function call chain information. The interface protocol information module 63 is specifically used to acquire the current interface protocol information of the target service based on a reflection mechanism after the target service completes service deployment through continuous integration and continuous deployment processes. The association relationship construction module 64 is specifically used to establish an association relationship between the function call chain information and the interface protocol information, and send the associated function call chain information and interface protocol information to a preset artificial intelligence tool platform. The interface annotation information module 65 is specifically used to generate interface annotation information representing the business semantics of the service interface through the artificial intelligence tool platform, preset prompts, and knowledge base information; the service interface documentation module 66 is specifically used to generate the service interface documentation corresponding to the target service based on the interface protocol information and interface annotation information.

[0109] As an optional implementation, the function call chain module 62 is further specifically used to determine the loading scope of the source code in the code repository for analysis through the project structure information, and load the source code corresponding to the target service according to the loading scope; parse the code dependency relationship between the source code according to the project structure information; and construct an abstract syntax tree to represent the overall structure of the source code of the target service and the relationship between functions through the code dependency relationship.

[0110] As an optional implementation, the function call chain module 62 is further specifically used to analyze the function definition nodes, function call nodes, and syntax nodes representing service interface registration relationships in the abstract syntax tree; identify the entry function of the target service based on the interface registration relationship or call relationship; parse the called identifier corresponding to the function call node and the association relationship between the function definition node and the corresponding function call node based on the entry function to obtain function call relationship information; and construct function call chain information representing the business execution path of the target service based on the function call relationship information.

[0111] As an optional implementation, the interface protocol information module 63 is further specifically used to obtain the service identifier information and reflection access parameters of the target service, wherein the reflection access parameters include at least service address information; initiate a reflection query request to the target service through the service address information to obtain the service description information of the target service; determine the interface function list of the target service based on the service description information; perform reflection query on each interface function in the interface function list to obtain the request parameter structure information and response parameter structure information of each interface function; and construct structured interface protocol information for describing the service interface definition based on the request parameter structure information and response parameter structure information.

[0112] As an optional implementation, the interface annotation information module 65 is further specifically used to analyze the business execution process of the target service based on the function identifier, function call order, and function call relationship in the function call chain information, and extract business semantic features that represent the business processing logic of the target service; extract the structural semantic features of the service interface based on the interface function definition, request parameter structure, and response parameter structure contained in the interface protocol information; submit the business semantic features, structural semantic features, and preset prompt words as input data to the artificial intelligence tool platform; and obtain interface annotation information representing the business semantics of the service interface through the artificial intelligence tool platform based on the preset prompt words and knowledge base information.

[0113] As an optional implementation, the service interface document generation device 60 further includes a prompt word optimization module. The prompt word optimization module is specifically used to obtain historical interface annotation information that has been generated for multiple service interfaces; to perform content verification on the text content of the historical interface annotation information, the content verification being based on preset content verification rules or content constraints; and to adjust and optimize the prompt word configuration for the artificial intelligence tool platform based on the content verification results.

[0114] As an optional implementation, the service interface document generation device 60 further includes an artificial intelligence model screening module. This module is specifically used to select at least two different artificial intelligence models and call these different models in the artificial intelligence tool platform. Based on the same prompt word configuration, business semantic features and structural semantic features are input into the updated artificial intelligence tool platform to generate candidate interface annotation information corresponding to different artificial intelligence models. Semantic matching analysis is performed on the different candidate interface annotation information with function call chain information and interface protocol information to obtain corresponding matching result data. Based on the matching result data, the target artificial intelligence model used to generate interface annotation information in the artificial intelligence tool platform is selected.

[0115] It should be noted that the service interface document generation device 60 described above can execute the service interface document generation method provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects of the method. Technical details not described in detail in the embodiments of the service interface document generation device 60 can be found in the service interface document generation method provided in the embodiments of this application.

[0116] Figure 9 This is a schematic diagram of the hardware structure of the electronic device for the execution service interface document generation method provided in this application embodiment, such as... Figure 9 As shown, the electronic device 700 includes: one or more processors 710 and a memory 720. Figure 9 Taking a processor 710 as an example, the processor 710 and the memory 720 can be connected via a bus or other means. Figure 9 Taking the example of a connection between China and Israel via a bus.

[0117] The memory 720, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the service interface document generation method in this embodiment. The processor 710 executes various functional applications and data processing of the server by running the non-volatile software programs, instructions, and modules stored in the memory 720, thereby implementing the service interface document generation method described in the above embodiment.

[0118] The memory 720 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the service interface documentation generation device. Furthermore, the memory 720 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 720 may optionally include memory remotely located relative to the processor 710, and these remote memories may be connected to the service interface documentation generation device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0119] The one or more modules are stored in the memory 720. When executed by the one or more processors 710, they execute the service interface document generation method in any of the above method embodiments, for example, executing the above-described... Figure 2 Steps S1 to S6 in the method are implemented. Figure 8 The functions of modules 61-66 in the document.

[0120] The above-described product can perform the methods provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for performing the methods. Technical details not described in detail in this embodiment can be found in the methods provided in the embodiments of this application.

[0121] This application provides a non-volatile computer-readable storage medium storing computer-executable instructions that are executed by one or more processors, for example... Figure 9 One of the processors 710 can enable the one or more processors to execute the service interface document generation method in any of the above method embodiments, for example, to execute the method described above. Figure 2 Steps S1 to S6 in the method are implemented. Figure 8 The functions of modules 61-66 in the document.

[0122] This application provides a computer program product, which includes a computer program stored on a non-volatile computer-readable storage medium. The computer program includes program instructions, which, when executed by an electronic device, enable the electronic device to perform the service interface document generation method described in any of the above method embodiments, for example, to perform the above-described... Figure 2 Steps S1 to S6 in the method are implemented. Figure 8 The functions of modules 61-66 in the document.

[0123] The device embodiments described above are merely illustrative. 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 modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0124] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software and a general-purpose hardware platform, or of course, using hardware. Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0125] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of this application as described above, which are not provided in detail for the sake of brevity; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for generating service interface documentation, characterized in that, include: Obtain the source code and project structure information from the code repository corresponding to the target service; Based on the source code and the project structure information, an abstract syntax tree is constructed and analyzed to identify the entry function of the target service, parse the function call relationship, and obtain the function call chain information. After the target service completes service deployment through continuous integration and continuous deployment processes, the current interface protocol information of the target service is obtained based on the reflection mechanism. Establish the association between the function call chain information and the interface protocol information, and send the associated function call chain information and the interface protocol information to a preset artificial intelligence tool platform; The AI ​​tool platform, preset prompts, and knowledge base information are used to generate interface annotation information that represents the business semantics of the service interface. Based on the interface protocol information and the interface annotation information, a service interface document corresponding to the target service is generated.

2. The service interface document generation method according to claim 1, characterized in that, The step of constructing and analyzing the abstract syntax tree based on the source code and the project structure information includes: The loading range of the source code in the code repository is determined by the project structure information, and the source code corresponding to the target service is loaded according to the loading range; Based on the engineering structure information, the code dependencies between the source codes are analyzed; Based on the code dependencies, an abstract syntax tree is constructed to represent the overall structure of the source code of the target service and the relationships between functions.

3. The service interface document generation method according to claim 1, characterized in that, The process of identifying the entry function of the target service, parsing the function call relationship, and obtaining the function call chain information includes: The function definition nodes, function call nodes, and syntax nodes representing service interface registration relationships in the abstract syntax tree are analyzed, and the entry function of the target service is identified based on the interface registration relationship or call relationship. Based on the entry function, the function call relationship information is obtained by parsing the called identifier corresponding to the function call node, the association between the function definition node and the corresponding function call node; Based on the function call relationship information, construct function call chain information that represents the business execution path of the target service.

4. The service interface document generation method according to claim 1, characterized in that, The step of obtaining the current interface protocol information of the target service based on reflection mechanism includes: Obtain the service identifier information and reflection access parameters of the target service, wherein the reflection access parameters include at least service address information; Initiate a reflection query request to the target service using the service address information to obtain the service description information of the target service; Based on the service description information, determine the list of interface functions for the target service; Reflection query is performed on each interface function in the interface function list to obtain the request parameter structure information and response parameter structure information of each interface function; Based on the request parameter structure information and the response parameter structure information, construct structured interface protocol information to describe the service interface definition.

5. The service interface document generation method according to claim 1, characterized in that, The process of generating interface annotation information representing the business semantics of the service interface through the aforementioned artificial intelligence tool platform, preset prompt words, and knowledge base information includes: Based on the function identifier, function call order, and function call relationship in the function call chain information, the business execution process of the target service is analyzed, and business semantic features that characterize the business processing logic of the target service are extracted. Based on the interface function definitions, request parameter structures, and response parameter structures contained in the interface protocol information, extract the structural semantic features of the service interface; The business semantic features, the structural semantic features, and the preset prompt words are submitted as input data to the artificial intelligence tool platform; The artificial intelligence tool platform obtains interface annotation information that represents the business semantics of the service interface based on preset prompts and knowledge base information.

6. The service interface document generation method according to claim 1, characterized in that, Following the step of generating interface annotation information representing the business semantics of the service interface, the method further includes: Retrieve historical interface annotation information for multiple service interfaces; The text content of the historical interface annotation information is validated, and the content validation is based on preset content validation rules or content constraints. Based on the verification results of the content verification, the configuration of prompt words used in the artificial intelligence tool platform is adjusted and optimized.

7. The service interface document generation method according to claim 1, characterized in that, Following the step of generating interface annotation information representing the business semantics of the service interface, the method further includes: Select at least two different artificial intelligence models, and call the at least two different artificial intelligence models respectively in the artificial intelligence tool platform; Based on the same prompt word configuration, the business semantic features and the structural semantic features are input into the artificial intelligence tool platform after the artificial intelligence model has been updated to generate candidate interface annotation information corresponding to different artificial intelligence models; Semantic matching analysis is performed on the different candidate interface annotation information, the function call chain information, and the interface protocol information to obtain the corresponding matching result data; Based on the matching result data, the target artificial intelligence model used to generate the interface annotation information in the artificial intelligence tool platform is selected.

8. A service interface document generation device, characterized in that, include: The code repository acquisition module is used to obtain the source code and project structure information from the code repository corresponding to the target service; The function call chain module is used to construct and analyze the abstract syntax tree based on the source code and the project structure information, identify the entry function of the target service, parse the function call relationship, and obtain the function call chain information; The interface protocol information module is used to obtain the current interface protocol information of the target service based on the reflection mechanism after the target service completes service deployment through continuous integration and continuous deployment processes. The association construction module is used to establish the association between the function call chain information and the interface protocol information, and send the associated function call chain information and the interface protocol information to a preset artificial intelligence tool platform; The interface annotation information module is used to generate interface annotation information that represents the business semantics of the service interface through the artificial intelligence tool platform, preset prompt words and knowledge base information; The service interface documentation module is used to generate the service interface documentation corresponding to the target service based on the interface protocol information and the interface annotation information.

9. An electronic device, characterized in that, include: At least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the service interface document generation method according to any one of claims 1 to 7.

10. A non-volatile computer-readable storage medium, characterized in that, The non-volatile computer-readable storage medium stores computer-executable instructions, which, when executed by an electronic device, cause the electronic device to perform the service interface document generation method according to any one of claims 1 to 7.

Images