LLM-based OpenAPI specification automatic generation method and system

Abstract

The invention provides an automatic OpenAPI specification generation method and system based on LLM, and belongs to the field of artificial intelligence, and the method comprises the steps: S1, designing a multi-agent workflow, and recognizing a server-side technology stack of a Web application program to be analyzed by using the LLM, thereby generating a cue word template; s2, based on the cue word template, acquiring corresponding code semantics by using LLM; designing a corresponding multi-agent workflow, and extracting an API endpoint of the Web application program to be analyzed; s3, based on the cue word template, acquiring corresponding OpenAPI knowledge by using LLM; and designing a corresponding multi-agent workflow, generating an API endpoint request parameter and a response specification, and performing correction and integration to obtain a complete OpenAPI specification. According to the method, under the condition that the API is triggered without depending on the client of the Web application program, the Web API is found in an active mode, and the OpenAPI specification is generated.

Description

Technical Field

[0001] This invention belongs to the technical field of artificial intelligence and Web API, and specifically relates to an automatic generation method and system for OpenAPI specifications based on LLM. Background Technology

[0002] Web APIs are a crucial component of modern web applications, enabling data exchange and function calls between different systems and supporting various application scenarios, including microservice architectures, mobile applications, and cloud computing. Currently, APIs based on the REST architectural style are gradually becoming the mainstream of Web APIs. To address the lack of a standard for describing REST APIs, the OpenAPI Initiative created the OpenAPI specification. This is a vendor-neutral, portable, and open REST API specification that allows humans and machines to understand the functionality of REST APIs without directly accessing the API implementation details. With strong support from organizations such as Google and Microsoft, it has become the de facto standard for describing REST APIs. Due to the powerful flexibility and compatibility of the OpenAPI specification, its application scope far exceeds its original design intent; it can be used to describe Web APIs that do not strictly adhere to the REST style, and even APIs based on other protocols.

[0003] Throughout the entire lifecycle of a web software project, writing and maintaining a comprehensive OpenAPI specification facilitates efficient collaboration between client-side and server-side developers. It also supports the use of automated Web API testing tools to verify software quality, benefiting the development, testing, and maintenance of software projects. On the other hand, as web applications become increasingly complex and the number of Web APIs surges, relying on development teams to manually write and maintain OpenAPI specifications is time-consuming and labor-intensive. Methods that rely on network sniffing or web crawling to obtain data packets containing Web API calls and then infer OpenAPI specifications are insufficient to discover APIs that cannot be triggered by the web application's client, resulting in incomplete results. Traditional methods of generating OpenAPI specifications based on static analysis or instrumentation techniques of web server-side code are only applicable to a few adapted programming languages ​​or Web API development frameworks, lacking generalizability.

[0004] Therefore, how to proactively discover Web APIs and generate OpenAPI specifications that are applicable to multiple programming languages ​​and Web API development frameworks without relying on client-side API triggering in Web applications has become a pressing technical problem in this field. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides an automatic generation method for OpenAPI specifications based on LLM, comprising the following steps:

[0006] Step S1: Utilize the cross-programming language understanding capabilities of LLM to design a corresponding multi-agent workflow, identify the server-side technology stack of the web application to be analyzed, and then generate a prompt word template;

[0007] Step S2: Based on the prompt word template, use LLM to obtain the corresponding code semantics; design the corresponding multi-proxy workflow, extract the API endpoints that the web application to be analyzed can accept, and obtain a tuple consisting of the request path and the request method;

[0008] Step S3: Based on the prompt word template, use LLM to obtain the corresponding OpenAPI knowledge; design the corresponding multi-proxy workflow, generate the specifications of the API endpoint request parameters and responses of the web application to be analyzed, and correct and integrate them to obtain the complete OpenAPI specification.

[0009] Beneficial effects:

[0010] 1. This invention provides an automatic OpenAPI specification generation method based on LLM. It automatically generates API specifications based on the LLM multi-agent workflow, without the need for human expert intervention or modification of the web application to be analyzed, thereby improving the automation and intelligence level of OpenAPI specification writing and maintenance.

[0011] 2. By analyzing the server-side code of a web application, this invention avoids dependence on client-side API triggering of the web application, thereby improving the comprehensiveness of web API discovery results.

[0012] 3. This invention utilizes the OpenAPI knowledge learned by LLM and its cross-programming language semantic understanding capabilities to achieve support for multiple programming languages ​​and server-side Web API development frameworks.

[0013] 4. The OpenAPI specification generated by this invention strictly follows OpenAPI version 3.1.0, which can meet the needs of both human reading and computer program processing, and provides support for tasks including API documentation generation and automated testing. Attached Figure Description

[0014] Figure 1 This is a flowchart illustrating an automatic OpenAPI specification generation method based on LLM according to the present invention.

[0015] Figure 2 This is a schematic diagram of the API dependency graph;

[0016] Figure 3 A schematic diagram of the endpoint extraction process for a Web API;

[0017] Figure 4 A schematic diagram illustrating the process of generating the OpenAPI specification for Web APIs;

[0018] Figure 5 This is a structural block diagram of an LLM-based OpenAPI specification automatic generation system according to the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.

[0020] In recent years, the natural language understanding and content generation capabilities of Large Language Models (LLMs) have empowered numerous vertical industries to solve automation and intelligentization problems. This invention relates to two solutions for using LLM to solve complex problems: the LLM workflow breaks down complex problems into a series of sub-tasks through predefined code paths defined by the developer, and calls the LLM multiple times to progressively solve the problem; the LLM agent enables the LLM to call external tools (such as executing system commands and online searches) and maintains multi-turn dialogue records with the LLM, achieving autonomous decision-making and forming a closed loop of perception-planning-execution. Based on this, the LLM multi-agent workflow decomposes complex tasks into multiple sub-tasks and processes them through either the LLM workflow or the LLM agent according to the specific circumstances of each sub-task, thereby improving the overall efficiency and effectiveness of the system. This invention improves the automation and intelligence level of OpenAPI specification writing and maintenance by introducing the LLM multi-agent workflow.

[0021] Example 1:

[0022] like Figure 1 As shown in the figure, an embodiment of the present invention provides an automatic generation method for OpenAPI specifications based on LLM, which includes the following steps:

[0023] Step S1: Utilize the cross-programming language understanding capabilities of LLM to design a corresponding multi-agent workflow, identify the server-side technology stack of the web application to be analyzed, and then generate a prompt word template;

[0024] Step S2: Based on the prompt word template, use LLM to obtain the corresponding code semantics; design the corresponding multi-proxy workflow, extract the API endpoints that the web application to be analyzed can accept, and obtain a tuple consisting of the request path and the request method;

[0025] Step S3: Based on the prompt word template, use LLM to obtain the corresponding OpenAPI knowledge; design the corresponding multi-agent workflow, generate the specifications of the API endpoint request parameters and responses of the web application to be analyzed, and correct and integrate them to obtain the complete OpenAPI specification.

[0026] In one embodiment, step S1 above: leveraging the cross-programming language understanding capabilities of LLM, designing a corresponding multi-agent workflow, identifying the server-side technology stack of the web application to be analyzed, and then generating a prompt word template, specifically includes:

[0027] Design an LLM proxy to probe and collect information from the server-side code of the web application to be analyzed, and obtain the server-side technology stack of the web application to be analyzed, including: programming language and Web API development framework.

[0028] In this step, the server-side code of the web application to be analyzed is probed. The initial prompts from the LLM agent include a task description and the results of executing the `ls` command in the server-side code repository of the web application to be analyzed. Simultaneously, the LLM agent has the ability to execute other Unix commands to collect necessary information. It can autonomously decide whether to execute commands and collect information, or determine and output the server-side technology stack of the web application to be analyzed based on existing information, including the main programming languages ​​and Web API development frameworks. This step is optional. Human experts can directly specify the server-side technology stack of the web application to be analyzed, or the server-side technology stack can be left empty without affecting the execution of subsequent steps S2 and S3, but this may degrade the performance of subsequent steps and the quality of the final generated OpenAPI specification.

[0029] In one embodiment, step S2 above involves: obtaining the corresponding code semantics using an LLM based on the prompt word template; designing a corresponding multi-proxy workflow; extracting the API endpoints acceptable to the web application being analyzed; and obtaining a tuple consisting of the request path and the request method, specifically including:

[0030] Step S21: The LLM is prompted to analyze each code file and identify API entry points for building the API dependency graph. Each API entry point includes: a request path, a function, class, or object Handler that handles requests matching the request path, and a boolean value Same indicating whether the implementation of the Handler is located in the same file.

[0031] API entry point: It is an abstraction of the routing function of the Web API development framework. It refers to binding a partial or complete request path to a function, class or object Handler that handles requests matching the request path, so as to directly handle the corresponding request or dispatch the request to other Handlers for processing according to the path. In addition to Path and Handler, it also records a boolean value Same indicating whether the implementation of the Handler is located in the same file.

[0032] In this embodiment of the invention, each code file of the web application is analyzed independently. For each code file, the LLM workflow prompts include a task description injecting the main programming language and Web API development framework of the web application to be analyzed, as well as the file path and file content of the file to be analyzed. The LLM workflow ultimately outputs a list containing all API entries in the file to be analyzed. For frameworks like Express.js and Gin, the Handler can use an anonymous implementation of the Web API development framework. The Handler using the anonymous implementation will be marked as Anonymous for subsequent processing.

[0033] For example, when analyzing the server-side code of a web application based on the Gin framework, the entry point identification module can identify API entry points {"path": " / api / ping", "handler": "Anonymous", "same": true} and {"path": " / api / tags", "handler": "articles.TagsAnonymousRegister", "same": false} from the hello.go file; and identify API entry points {"path": " / ", "handler": "TagsAnonymousRegister", "same": true} from the articles / router.go file.

[0034] The API dependency graph constructed in this step models the dependencies between API entry points in various files. It is a directed acyclic graph, where V represents the set of nodes, and each node... It maintains a file (File) and all the identified API entries within it, where E represents the set of edges, and each edge... This represents a dependency relationship between a pair of files, i.e. At least one Handler implementation in In the maintained files, determine The complete request path for the corresponding API entry point needs to be... Information about the maintained files; the process of building the API dependency graph, specifically including:

[0035] Step S211: Create a new node for each file with an API entry. The node includes: a file (File) and all the API entries in that file.

[0036] Step S212: For each API entry where Same is false It iterates through the files containing the concrete implementation of the Handler. If the file is not added to the API dependency graph, a new node is created in the API dependency graph. ;

[0037] Step S213: For each API entry where Same is false Then, iterate through the File containing the specific implementation of Handler again, and add a directed edge from File to the file where the API entry point is located to represent the dependency relationship.

[0038] Step S22: For API entry points where Same is false, prompt the LLM to determine the file containing the Handler implementation and add a directed edge in the API dependency graph from the file containing the Handler implementation to the file containing the API entry point that introduced the corresponding Handler.

[0039] In this embodiment of the invention, each identified API entry point is analyzed independently. For each identified API entry point, the initial prompts from the LLM agent include a task description injecting the main programming language and Web API development framework of the web application to be analyzed, the file path and content of the file containing the API entry point, as well as its Path and Handler. Simultaneously, the LLM agent has the ability to execute other Unix commands to collect necessary information. It can autonomously decide whether to execute commands and collect information, or determine and output a list of file paths containing the specific implementation of the Handler based on existing information. The LLM prompts are output in list form to support the implementation of routing group functionality within the Web API development framework.

[0040] For example, for the API entry {"path": " / api / tags", "handler": "articles.TagsAnonymousRegister", "same": false} identified from the hello.go file in step S21, the file association module can determine that the specific implementation of the API entry's Handler is located in the articles / router.go file, and thus add a directed edge in the API dependency graph from the node containing articles / router.go to the node containing hello.go. As another example, for the API entry {"path": " / api", "handler": "api", "same": false} identified from the src / app / routes / routes.ts file, the file association module can determine that the specific implementation of the API entry's Handler is located in multiple files such as src / app / routes / tag / auth.controller.ts and src / app / routes / tag / tag.controller.ts, and thus add a directed edge in the API dependency graph from the nodes containing these files that contain the specific implementation of the Handler to the node containing src / app / routes / routes.ts. Figure 2 This is a structural example of a completed API dependency graph.

[0041] Step S23: Traverse the API entry points where Same is true, perform topological sorting on the API dependency graph subgraph consisting of the API dependency graph node where it is located and its successor nodes, prompting the LLM analysis to identify the files involved, determine the complete request path and request method, and thus obtain the Web API endpoint.

[0042] For all API entries in a node that are true (Same), starting from the corresponding node, search for all its successor nodes, construct a subgraph of the API dependency graph based on these nodes, and perform topological sorting on the subgraph to obtain a list of files containing the API entry to be analyzed and all its dependencies. This suggests that the LLM workflow can merge path prefixes to obtain the complete request path and request method of the corresponding API entry.

[0043] The complete request path is the request path with the prefix combined, and the request method includes the eight methods defined by the OpenAPI specification: GET, PUT, POST, DELETE, OPTIONS, HEAD, PATCH, and TRACE, plus the ALL method additionally set by this invention. The ALL method is included because some Web API development frameworks are designed to allow developers to request the corresponding path without explicitly specifying the acceptable request method, allowing the use of any method.

[0044] In this embodiment of the invention, each eligible API entry point is analyzed independently. For each eligible API entry point, the LLM workflow prompts include a task description injecting the main programming language and WebAPI development framework of the web application to be analyzed, the file paths and contents of all dependencies of the API entry point, and its Path and Handler. The LLM workflow ultimately outputs the complete request path and request method of the API entry point to be analyzed. To minimize the illusion of LLM, this embodiment of the invention prompts the LLM to output the request method in one-hot encoding.

[0045] For example, for the API entry point {"path": " / ", "handler": "TagsAnonymousRegister", "same": true} identified from the articles / router.go file, its dependent file includes hello.go. Based on the above content, the endpoint generation module can obtain {"path": " / api / tags", "get": true, "put": false, "delete": false, "patch": false, "head": false, "post": false, "options": false, "trace": false, "all": false}. For example, the API entry point {"path": " / api / health-check", "handler": "healthCheck", "same": true} identified from the file src / main / java / org / TestController.java has no dependent files, and healthCheck uses the @RequestMapping(" / api / health-check") annotation to map requests. Based on the above, we can obtain {"path": " / api / health-check", "get": false, "put": false, "delete": false, "patch": false, "head": false, "post": false, "options": false, "trace": false, "all": true}.

[0046] Figure 3 This is a schematic diagram of the endpoint extraction process for a Web API.

[0047] In one embodiment, step S3 above involves: using LLM to obtain the corresponding OpenAPI knowledge based on the prompt word template; designing a corresponding multi-proxy workflow to generate the specifications of the API endpoint request parameters and responses of the web application to be analyzed, and revising and integrating them to obtain the complete OpenAPI specification, specifically including:

[0048] Step S31: The LLM proxy is prompted to start from the API entry point where Same is true for each Web API endpoint, analyze its request parameters, and output the request structure according to the definition in the OpenAPI specification;

[0049] In this step, each Web API endpoint obtained in step S2 is traversed, prompting the LLM agent to describe the request structure according to the OpenAPI specification. In this embodiment of the invention, each Web API endpoint is analyzed independently. For each Web API endpoint to be analyzed, the initial prompt from the LLM agent includes a task description injected with the main programming language and Web API development framework of the web application to be analyzed, the request path and request method of the corresponding Web API endpoint, and the file path and content of the Handler file that determines the API entry point of the Web API endpoint. Simultaneously, the LLM agent has the ability to execute other Unix commands to collect necessary information, and can autonomously decide whether to execute commands and collect information, or to output the request specification of the Web API endpoint in the form of a JSON string based on existing information.

[0050] Existing LLMs are designed for outputting natural language. When outputting OpenAPI specifications with complex formal definitions, they suffer from severe syntactic and semantic illusions. In request specification generation, the semantic illusion primarily stems from the confusion between Swagger 2.0 and OpenAPI 3.0 versions of the OpenAPI specification, failing to accurately output the version specified in the prompt. This invention, considering that Swagger 2.0 is predominantly used in LLM output, while OpenAPI 3.0 is currently more widely adopted, prompts the LLM to output Parameter objects describing the request using Swagger 2.0 as the primary version. Then, through a heuristic method, the LLM output is converted into Parameter objects conforming to OpenAPI 3.1.0, and a Request Body object describing the request body structure.

[0051] For example, when analyzing the Web API endpoint POST / api / user / login, the request specification generation module will obtain {"parameters": [{"name": "username", "in": "body", "schema": {"type": "string"}}, {"name": "password", "in": "body", "schema": {"type": "string"}}]}. After heuristic correction and transformation, multiple request parameters located in the body are merged to obtain {"requestBody": {"content": {"application / json": {"schema": {"type": "object","properties": {"username": {"type": "string"}, "password": {"type": "string"}}}}}}}}.

[0052] Step S32: For each Web API endpoint, prompt the LLM proxy to start from the API entry point where Same is true for the corresponding endpoint, analyze its response structure, and output the response structure according to the definition in the OpenAPI specification;

[0053] In this embodiment of the invention, each Web API endpoint is analyzed independently. For each Web API endpoint to be analyzed, the initial prompts from the LLM agent include a task description injected with the main programming language and Web API development framework of the web application to be analyzed, the request path and request method of the corresponding Web API endpoint, and the file path and content of the Handler file that determines the API entry point of the Web API endpoint. Simultaneously, the LLM agent has the ability to execute other Unix commands to collect necessary information, and can autonomously decide whether to execute commands and collect information, or to output the response specification of the Web API endpoint in the form of a JSON string based on existing information.

[0054] Regarding response specification generation, existing LLMs suffer from several semantic illusions. Besides the difficulty in accurately outputting the specified OpenAPI specification version, they also struggle to correctly utilize the OpenAPI specification's referencing mechanism. For example, they might output something like "$ref": "# / components / schemas / RespClass", without actively using tools to determine the specific structure of RespClass. To address this, this embodiment of the invention prompts the LLM to use tools to determine the specific structure of $ref when outputting the Responses object describing the response, thus avoiding the use of $ref references and mitigating this illusion. Simultaneously, it verifies the $ref references output by the LLM; if the content referenced by $ref does not exist, the non-existent part is set to null. This situation is common in Schema objects of 4xx or 5xx status code errors and less frequently affects normal responses.

[0055] For example, when analyzing the Web API endpoint POST / api / user / login, the response specification generation module will obtain {"responses": {"200": {"description": "Success", "schema": {"type": "string"}},"400": {"description": "Fail", "schema": {"$ref": "# / schemas / Err"}}}}. After heuristic correction and transformation, replacing the non-existent $ref references, it will obtain {"responses": {"200": {"description": "Success", "content": {"application / json": {"schema": {"type":"string"}}}}, "400": {"description": "Fail", "content": {"application / json":{"schema": {}}}}}}}.

[0056] Step S33: Heuristically correct any syntactic and semantic illusions that may exist in the request and response specifications generated by LLM, obtain Operation objects that conform to the OpenAPI specification, and reorganize each Web API endpoint according to the Path and Path Item objects defined by the OpenAPI specification, and finally output the complete OpenAPI specification of the Web application to be analyzed.

[0057] Regarding the handling of request and response specifications, the OpenAPI merging module corrects various syntax illusions in the LLM output, as shown in Table 1, thereby obtaining a valid JSON object.

[0058] Table 1: Common JSON Error Types and Handling Methods

[0059]

[0060] Regarding the organization of Web API endpoints, the OpenAPI merging module, based on the existing mapping from "request path and request method" to "request specification and response specification", transforms it into a two-level index structure from "request path" (Paths object in the OpenAPI specification) to "request method" (Path Item object in the OpenAPI specification) to "operation definition containing request specification and response specification" (Operation object in the OpenAPI specification), thus forming the complete OpenAPI specification of the Web application to be analyzed.

[0061] Figure 4 A schematic diagram illustrating the process of generating the OpenAPI specification for Web APIs.

[0062] This invention designs an LLM multi-agent workflow for automatically generating OpenAPI specifications. By analyzing the server-side code of a web application, it proactively discovers Web API endpoints, avoiding dependence on client-side API triggers and improving the comprehensiveness of Web API discovery results. Leveraging the OpenAPI knowledge learned by the LLM and its cross-programming language semantic understanding capabilities, it supports multiple programming languages ​​and server-side Web API development frameworks. This invention follows OpenAPI version 3.1.0 to generate OpenAPI specifications, satisfying both human readability and computer program processing needs. During the OpenAPI specification generation process, no human expert intervention or modification of the web application being analyzed is required, thus enhancing the automation and intelligence of OpenAPI specification writing and maintenance.

[0063] Example 2:

[0064] like Figure 5 As shown, this embodiment of the invention provides an automatic OpenAPI specification generation system based on LLM, comprising the following modules:

[0065] The Web server technology stack identification module is used to leverage the cross-programming language understanding capabilities of LLM to design corresponding multi-agent workflows, identify the server technology stack of the Web application to be analyzed, and then generate prompt word templates.

[0066] The Web API endpoint extraction module is used to obtain the corresponding code semantics based on prompt word templates using LLM; it designs a corresponding multi-proxy workflow to extract the API endpoints that the web application to be analyzed can accept, and obtains a tuple consisting of request path and request method.

[0067] The Web API specification generation module is used to obtain the corresponding OpenAPI knowledge based on prompt word templates using LLM; design the corresponding multi-proxy workflow, generate the specifications of API endpoint request parameters and responses of the web application to be analyzed, and correct and integrate them to obtain the complete OpenAPI specification.

[0068] An LLM-based automatic OpenAPI specification generation device includes one or more electronic devices, wherein the one or more electronic devices are used to implement the LLM-based automatic OpenAPI specification generation method.

[0069] An electronic device includes: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement an LLM-based OpenAPI specification automatic generation method.

[0070] A computer-readable storage medium having stored executable instructions thereon, which, when executed by a processor, cause the processor to implement an LLM-based method for automatically generating OpenAPI specifications.

[0071] A non-transitory computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements an LLM-based method for automatically generating OpenAPI specifications.

[0072] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for automatically generating OpenAPI specifications based on LLM, characterized in that, include: Step S1: Utilize the cross-programming language understanding capabilities of LLM to design a corresponding multi-agent workflow, identify the server-side technology stack of the web application to be analyzed, and then generate a prompt word template; Step S2: Based on the prompt word template, use LLM to obtain the corresponding code semantics; Design a corresponding multi-agent workflow, extract the API endpoints that the web application to be analyzed can accept, and obtain a tuple consisting of the request path and the request method; Step S3: Based on the prompt word template, use LLM to obtain the corresponding OpenAPI knowledge; Design a corresponding multi-agent workflow, generate specifications for the API endpoint request parameters and responses of the web application to be analyzed, and then correct and integrate them to obtain the complete OpenAPI specification.

2. The method for automatically generating OpenAPI specifications based on LLM according to claim 1, characterized in that, Step S1: Utilizing the cross-programming language understanding capabilities of LLM, a corresponding multi-agent workflow is designed to identify the server-side technology stack of the web application to be analyzed, and then a prompt word template is generated, specifically including: Design an LLM proxy to probe and collect information from the server-side code of the web application to be analyzed, and obtain the server-side technology stack of the web application to be analyzed, including: programming language and Web API development framework.

3. The method for automatically generating OpenAPI specifications based on LLM according to claim 1, characterized in that, Step S2: Based on the prompt word template, use LLM to obtain the corresponding code semantics; Design a corresponding multi-proxy workflow, extract the API endpoints that the web application to be analyzed can accept, and obtain a tuple consisting of the request path and request method, specifically including: Step S21: The LLM is prompted to analyze each code file and identify API entry points for building the API dependency graph. Each API entry point includes: a request path, a function, class, or object Handler that handles requests matching the request path, and a boolean value Same indicating whether the implementation of the Handler is located in the same file. Step S22: For API entry points where Same is false, prompt the LLM to determine the file containing the Handler implementation and add a directed edge to the API dependency graph from the file containing the Handler implementation to the file containing the API entry point that introduced the corresponding Handler. Step S23: Traverse the API entry points where Same is true, perform topological sorting on the API dependency graph subgraph consisting of the API dependency graph node where it is located and its successor nodes, prompting the LLM analysis to identify the files involved, determine the complete request path and request method, and thus obtain the Web API endpoint.

4. The method for automatically generating OpenAPI specifications based on LLM according to claim 3, characterized in that, The API dependency graph construction process described in step S21 specifically includes: Step S211: Create a new node for each file with an API entry. The node includes: a file (File) and all the API entries in that file. Step S212: For each API entry where Same is false It iterates through the files containing the concrete implementation of the Handler. If the file is not added to the API dependency graph, a new node is created in the API dependency graph. ; Step S213: For each API entry where Same is false Then, iterate through the File containing the specific implementation of Handler again, and add a directed edge from File to the file where the API entry point is located to represent the dependency relationship.

5. The method for automatically generating OpenAPI specifications based on LLM according to claim 1, characterized in that, Step S3: Based on the prompt word template, use LLM to obtain the corresponding OpenAPI knowledge; Design a corresponding multi-proxy workflow, generate specifications for the API endpoint request parameters and responses of the web application to be analyzed, and then revise and integrate them to obtain the complete OpenAPI specification, specifically including: Step S31: Prompt the LLM proxy to start from the API entry where Same is true for each of the aforementioned Web API endpoints, analyze its request parameters, and output the request structure according to the definition in the OpenAPI specification; Step S32: For each of the Web API endpoints, prompt the LLM proxy to start from the API entry point where Same is true for the corresponding endpoint, analyze its response structure, and output the response structure according to the definition in the OpenAPI specification; Step S33: Heuristically correct any syntactic and semantic illusions that may exist in the request and response specifications generated by LLM, obtain Operation objects that conform to the OpenAPI specification, and reorganize each Web API endpoint according to the Path and Path Item objects defined by the OpenAPI specification, and finally output the complete OpenAPI specification of the Web application to be analyzed.

6. An automatic OpenAPI specification generation system based on LLM, characterized in that, Includes the following modules: The Web server technology stack identification module is used to leverage the cross-programming language understanding capabilities of LLM to design corresponding multi-agent workflows, identify the server technology stack of the Web application to be analyzed, and then generate prompt word templates. The Web API endpoint extraction module is used to obtain the corresponding code semantics using LLM based on the prompt word template; Design a corresponding multi-agent workflow, extract the API endpoints that the web application to be analyzed can accept, and obtain a tuple consisting of the request path and the request method; The Web API specification generation module is used to obtain the corresponding OpenAPI knowledge using LLM based on the prompt word template; Design a corresponding multi-agent workflow, generate specifications for the API endpoint request parameters and responses of the web application to be analyzed, and then correct and integrate them to obtain the complete OpenAPI specification.

7. An automatic OpenAPI specification generation device based on LLM, characterized in that, It includes one or more electronic devices, wherein the one or more electronic devices are used to implement the method of any one of claims 1 to 5.

8. An electronic device, characterized in that, include: One or more processors; A memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the method of any one of claims 1 to 5.

9. A computer-readable storage medium, characterized in that, It stores executable instructions that, when executed by a processor, cause the processor to perform the method described in any one of claims 1 to 5.

10. A non-transitory computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the steps of the method as described in any one of claims 1 to 5.

Images