Information processing method and device of application programming interface and electronic equipment

Abstract

The invention discloses an information processing method and device of an application programming interface and electronic equipment. The method comprises the steps that a plurality of logic blocks of an original document of the application programming interface are obtained, the original document is at least used for describing different functions of the application programming interface, and the logic blocks correspond to the functions; identifying first flow information and second flow information of a function corresponding to the logic block from the logic block; fusing the normative index of the first process information and the readability index of the second process information to obtain target process information; based on the target process information, a target document of the application programming interface is generated, and the target document is used for describing interaction behaviors completed by the application programming interface executing the operation process. The technical problem that the information processing accuracy of the application programming interface is low is solved.

Description

Technical Field

[0001] This application relates to the fields of software engineering and artificial intelligence technology, and more specifically, to an information processing method, apparatus, and electronic device with an application programming interface. Background Technology

[0002] Currently, with the deepening of digital transformation and the popularization of microservice architecture, Application Programming Interfaces (APIs), as a fundamental building block of modern software development, are experiencing rapid growth in both number and complexity. The booming API economy has promoted seamless connections across systems and platforms, but this process has also highlighted significant challenges in writing and maintaining API specifications.

[0003] In related technologies, the creation of API specifications relies on manual operations. This method is not only inefficient and consumes significant human resources, but is also highly susceptible to individual negligence, leading to inconsistencies between API documentation and actual implementation. Especially when API documentation is scattered across multiple formats with inconsistent information presentation and loose structure, accurately extracting and standardizing API information has become a pain point in the industry. Therefore, the technical problem of low accuracy in information processing of application programming interfaces persists.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides an information processing method, apparatus, and electronic device for application programming interfaces (APIs) to at least solve the technical problem of low accuracy in information processing via APIs.

[0006] According to one aspect of the embodiments of this application, an information processing method for an application programming interface (API) is provided, comprising: obtaining multiple logical blocks of the original document of the API, wherein the original document is used to describe at least the different functions possessed by the API, and the logical blocks correspond to the functions; identifying first process information and second process information of the functions corresponding to the logical blocks from the logical blocks, wherein the first process information is used to represent a first operation process to be executed to implement the function, the second process information is used to represent a second operation process to be executed to implement the function, the standardization index of the first operation process is greater than the standardization index of the second operation process, and the readability index of the second operation process is greater than the readability index of the first operation process; fusing the standardization index of the first process information and the readability index of the second process information to obtain target process information; and generating a target document of the API based on the target process information, wherein the target document is used to describe the interactive behavior to be completed by the API executing the operation process.

[0007] Optionally, obtaining multiple logical blocks of the original document of the application programming interface includes: identifying multiple anchor points of the application programming interface from the original document; and using the multiple anchor points to split the original document to obtain logical blocks, wherein the logical block is a portion of the document between any two anchor points in the original document.

[0008] Optionally, multiple anchor points of the application programming interface are identified from the original document, including: determining operation signatures and / or code examples identified from the original document as anchor points; the method further includes: in response to the absence of operation signatures or operation signature code examples in the original document, determining hypertext markup language tags identified from the original document as anchor points.

[0009] Optionally, the first process information is a demonstrative process, and the second process information is a descriptive process. The first process information and the second process information corresponding to the function of the logical block are identified from the logical block, including: inputting the code example extracted from the logical block into the large language model, and using the large language model to generate a demonstrative process based on the code example; inputting the text information extracted from the logical block into the large language model, and using the large language model to generate a descriptive process based on the text information.

[0010] Optionally, code examples extracted from the logical blocks are input into a large language model. Using the large language model, a demonstrative process is generated based on the code examples, including: using the large language model, generating structured information corresponding to the function based on the received code examples; and determining the demonstrative process based on the structured information.

[0011] Optionally, the text information extracted from the logical block is input into the large language model. Using the large language model, a descriptive process is generated based on the text information, including: using the large language model, generating descriptive meta-information corresponding to the function based on the received text information, wherein the text information includes at least one of the following: natural language description, parameter table, and example value; and determining the descriptive process based on the descriptive meta-information.

[0012] Optionally, the normative indicators of the first process information and the readability indicators of the second process information are fused to obtain the target process information, including: in response to the fact that the first process information and the second process information are not contradictory, the target process information is determined based on the priorities corresponding to the first process information and the second process information, respectively; in response to the fact that the first process information and the second process information are contradictory, a large language model is invoked to determine the confidence levels of the first process information and the second process information, respectively; and the target process information is determined based on the confidence levels of the first process information and the second process information.

[0013] Optionally, the target process information is a document fragment to be adjusted. Based on the target process information, a target document for the application programming interface is generated, including: integrating the document fragments to be adjusted corresponding to multiple logical blocks to obtain the document to be adjusted; calling the large language model to adjust the document to be adjusted to obtain the target document, wherein the generality of the target document is greater than that of the document to be adjusted.

[0014] Optionally, a large language model is invoked to adjust the document to be adjusted, resulting in a target document, including at least one of the following: invoking the large language model to adjust the natural language information in the document to be adjusted into structured language information, resulting in a target document; invoking the large language model to add type parameters to the example values ​​in the document to be adjusted, resulting in a target document; or invoking the large language model to add security attributes to sensitive information in the document to be adjusted, resulting in a target document, wherein the security attributes are used to improve the security level of the sensitive information.

[0015] According to another aspect of the embodiments of this application, an information processing apparatus for an application programming interface (API) is also provided, comprising: an acquisition module, configured to acquire multiple logical blocks of an original document of the API, wherein the original document at least describes different functions possessed by the API, and the logical blocks correspond to the functions; an identification module, configured to identify first process information and second process information of the functions corresponding to the logical blocks from the logical blocks, wherein the first process information represents a first operation process to be executed to implement the function, the second process information represents a second operation process to be executed to implement the function, the normative index of the first operation process is greater than the normative index of the second operation process, and the readability index of the second operation process is greater than the readability index of the first operation process; a fusion module, configured to fuse the normative index of the first process information and the readability index of the second process information to obtain target process information; and a generation module, configured to generate a target document of the API based on the target process information, wherein the target document describes the interactive behavior of the API to be completed by executing the operation process of the API.

[0016] According to another aspect of the embodiments of this application, a computer program product is also provided, the computer program product comprising: a computer program, wherein the computer program, when executed by a processor, implements the information processing method of the above-described application programming interface.

[0017] According to another aspect of the embodiments of this application, an electronic device is also provided, the electronic device including: a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the information processing method of the above-described application programming interface through the computer program.

[0018] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the information processing method of the above-described application programming interface when it runs.

[0019] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, the information processing method that controls the device where the computer-readable storage medium is located to execute the above-described application programming interface is provided.

[0020] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the above-described application programming interface information processing method.

[0021] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the information processing method of the above-described application programming interface.

[0022] According to another aspect of the embodiments of this application, a computer program is also provided, which, when executed by a processor, implements the above-described application programming interface information processing method.

[0023] In this embodiment, multiple logical blocks of the original document of the application programming interface (API) are obtained. The original document at least describes the different functions of the API, and the logical blocks correspond to the functions. From the logical blocks, first process information and second process information corresponding to the functions of each logical block are identified. The first process information represents the first operation process to be executed to implement the function, and the second process information represents the second operation process to be executed to implement the function. The standardization index of the first operation process is greater than the standardization index of the second operation process, and the readability index of the second operation process is greater than the readability index of the first operation process. The standardization index of the first process information and the readability index of the second process information are fused to obtain target process information. Based on the target process information, a target document of the API is generated, whereby the target document describes the interactive behavior completed by the API executing the operation process. In other words, in this embodiment, intelligent segmentation preprocessing decomposes the original document into logical blocks corresponding to the API functions. By extracting highly standardized first-process information from logical blocks and easily understandable second-process information from natural language descriptions, and by prioritizing a fusion strategy that balances standardization and readability, information contradictions are resolved, and the consistency and completeness of information output are improved. This further optimizes the quality of process information, resulting in the final target document. The above method, through intelligent means, significantly improves the accuracy and processing efficiency of API information, reduces the burden of manually maintaining API specifications, and thus achieves the technical effect of improving the accuracy of information processing in application programming interfaces (APIs), solving the technical problem of low accuracy in API information processing. Attached Figure Description

[0024] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0025] Figure 1 This is a flowchart illustrating an optional application programming interface information processing method according to an embodiment of this application;

[0026] Figure 2 This is a schematic diagram of an optional API specification generation system architecture based on multi-stage hybrid intelligence according to an embodiment of this application;

[0027] Figure 3 This is a flowchart illustrating an optional API specification generation method based on multi-stage hybrid intelligence according to an embodiment of this application.

[0028] Figure 4This is a schematic diagram of the structure of an information processing device with an optional application programming interface according to an embodiment of this application.

[0029] Figure 5 This is a schematic diagram of the structure of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0030] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present application.

[0031] It should be noted that the terms "first," "second," etc., used in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0032] The information collected in this application embodiment is information and data authorized by the user or fully authorized by all parties. The collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with the relevant laws, regulations and standards of the relevant countries and regions, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse.

[0033] Example 1

[0034] According to an embodiment of this application, an information processing method using an application programming interface is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0035] Figure 1 This is a flowchart illustrating an information processing method using an application programming interface according to an embodiment of this application, such as... Figure 1 As shown, the method may include the following steps:

[0036] Step S102: Obtain multiple logical blocks of the original document of the application programming interface.

[0037] In the technical solution provided by step S102 of the present invention, the original document can at least be used to describe the different functions of the application programming interface, and the logical blocks correspond to the functions.

[0038] Optionally, the original documentation can refer to the original materials containing API information. It can be documentation provided by the API designer or developer, used to describe the API's various functions, parameters, request / response formats, and usage examples. The original documentation can exist in various formats, including but not limited to Hypertext Markup Language (HTML), Markdown, and plain text.

[0039] Optionally, a logical block can refer to an independent unit separated from the original document using intelligent segmentation technology; the logical blocks mentioned above can be simply referred to as blocks. Each logical block focuses on describing a specific operation or function of the API. The purpose of the logical blocks is to better adapt to the processing capabilities of large language models (LLMs) and avoid the loss of contextual information due to excessive document length. The creation of logical blocks modularizes the information for each function (e.g., API operation), facilitating subsequent processing of demonstrative and descriptive paths.

[0040] Optionally, a function can refer to an API operation, that is, a single instruction or service that the API can execute. This includes, but is not limited to, retrieving (GET), updating (PUT), creating (POST), and deleting (DELETE) data. Each function can be defined by an operation signature, such as a Hypertext Transfer Protocol (HTTP) method and path definition, and may include a set of parameters, request / response format, and other details.

[0041] In this embodiment, multiple logical blocks of the original documentation of the application programming interface can be obtained.

[0042] Optionally, the raw API documentation is received. A document parser is launched, capable of recognizing various document structures, including headings, lists, and code blocks, designed to extract key parts describing API operations. The parser scans the document, identifying operation signatures. Simultaneously, the parser can also look for code examples. In HTML documents, the parser also focuses on specific HTML tags.

[0043] Optionally, based on the identified anchor points, the original document is divided into multiple logical blocks, each revolving around an API operation or function. When segmenting logical blocks, the system ensures that each block contains the necessary information describing the API operation, such as operation signatures, code examples, natural language descriptions, and parameter tables. During segmentation, the integrity of the blocks is evaluated using deep learning and natural language processing techniques to ensure that the boundaries of the logical blocks accurately cover all descriptive information of the API operation.

[0044] In this embodiment of the application, the above method can effectively transform the API description information in the original document into a set of logical blocks that can be processed independently. Each block focuses on describing a specific API operation, which greatly simplifies the subsequent information extraction and specification generation process and improves the overall processing efficiency and accuracy.

[0045] Step S104: Identify the first process information and the second process information of the function corresponding to the logical block from the logical block.

[0046] In the technical solution provided by step S104 of the present invention, the first process information is used to represent the first operation process to be executed to realize the function, the second process information is used to represent the second operation process to be executed to realize the function, the standardization index of the first operation process is greater than the standardization index of the second operation process, and the readability index of the second operation process is greater than the readability index of the first operation process.

[0047] Optionally, the first process information can be a demonstrative path, primarily focusing on the structured and standardized parts of the API specification to ensure the accuracy and completeness of information such as API invocation methods, parameter types, and request / response formats. This path places particular emphasis on the specification's normative metrics, namely the quality of the specification in terms of syntax, semantics, and consistency. The demonstrative path mainly extracts information from code examples. The code examples mentioned above provide a direct demonstration of API calls, including core operation flows, parameter names, data types, and whether they are required.

[0048] Optionally, the second process information can be a descriptive path, focusing more on the descriptiveness and readability of the API specification, including parameter descriptions, default values, enumeration values, and formatting information. This descriptive path particularly emphasizes the readability metrics of the specification, i.e., its clarity and comprehensibility for humans. The descriptive path primarily extracts information from the natural language text of the original document, such as descriptive paragraphs of API operations, explanatory text in parameter tables, and example values. This textual information provides the context and details of the API operations, helping users better understand the API's use cases and constraints.

[0049] Optionally, readability metrics can refer to the clarity, comprehensibility, and user-friendliness of API documentation. This emphasizes that the documentation should be quickly and accurately interpreted by both non-technical personnel and professional developers. Readability metrics can focus on aspects such as language clarity, completeness of description, and richness of examples. Normative metrics focus on the correct formatting, syntactic accuracy, standardization and consistency of information, and adherence to industry standards or conventions. These normative metrics ensure that API documentation can be correctly parsed and used by automated tools. Normative metrics can focus on aspects such as syntactic accuracy, data type consistency, information completeness, and adherence to standardized formats.

[0050] In this embodiment, after obtaining multiple logical blocks of the original document of the application programming interface, the first process information and the second process information of the function corresponding to the logical block can be identified from the logical blocks.

[0051] Optionally, logical blocks are received from the intelligent segmentation stage, each block focusing on describing a specific API function. The contents of the logical blocks are previewed, including operation signatures, code examples, natural language descriptions, and parameter tables. Each code example within a block is located and parsed. Structured information contained in the code examples is extracted, such as HTTP methods, resource paths (e.g., / users / {userId}), parameter types in the request body, and their necessity. The extracted structured information is fed into the LLM, instructing it to generate a structured description of the API operation, including the exact path, method, parameter names, parameter types, and their necessity. After the LLM outputs the structured description, its conformity metrics (such as syntactic correctness, information completeness, and matching with the actual API logic) are evaluated.

[0052] Optionally, extract text information such as natural language descriptions, parameter tables, and example values ​​from the logical blocks. This text information is then fed into the LLM, which parses the description information and generates descriptive fields, such as detailed parameter descriptions, default values, enumeration values, and formatting information. The readability metrics of the descriptive information generated by the LLM are evaluated (e.g., clarity of description, understanding of API functionality, and user-friendliness).

[0053] Step S106: The standardization indicators of the first process information and the readability indicators of the second process information are fused to obtain the target process information.

[0054] In the technical solution of step S106 of the present invention, the target process information can be an API operation description that integrates the structured accuracy of the exemplary path and the descriptive richness of the descriptive path. The target process information can also be referred to as the fusion result or generated result obtained by fusing the first process information and the second process information.

[0055] In this embodiment, after identifying the first process information and the second process information from the logical block, the normative indicators of the first process information and the readability indicators of the second process information can be fused to obtain the target process information.

[0056] Optionally, for each API function description, evaluate the prescriptive metrics of the first process information (exemplary path) and the readability metrics of the second process information (descriptive path). Record the evaluation results for each process information, including its conformity to the actual API interaction, the correctness of the syntactic structure, the completeness of the information, and the clarity and richness of the description. Define fusion rules to ensure priority allocation in case of conflicts. For example, when parameter types are inconsistent in the exemplary and descriptive paths, the information with higher prescriptive metrics should be prioritized. Design a conflict arbitration scheme, such as introducing a confidence score for LLM-generated information, to determine which process information should be adopted when information is contradictory.

[0057] Optionally, for each API function description, the structured information from the exemplary path and the descriptive information from the descriptive path are merged. For structured information with high prescriptiveness (such as parameter type and necessity), the values ​​from the first process information are directly adopted. For descriptive information with high readability (such as parameter description, format, and default value), the descriptions from the second process information are directly adopted. Potential conflicts between the two process information are detected and recorded, such as inconsistencies in parameter type and default value information.

[0058] Optionally, for conflicting records, a conflict arbitration scheme can be applied. For example, if the exemplary path and the descriptive path disagree on the data type of the parameter `age`, their respective confidence scores can be used to determine the final type. After resolving all conflicts, ensure that the standardization and readability of each parameter in the target process information are appropriate. Organize the merged information into a structured format according to the API specifications to ensure the machine readability of the final document.

[0059] Optionally, conflict-free information from exemplary and descriptive paths, along with conflict-arbitrated information, is integrated to form target process information. This ensures that each API operation description in the target process information contains accurate structured information and sufficient descriptive information, achieving a good balance between standardization and readability. The generated target process information undergoes a final review to check for syntax errors, missing information, and formatting inconsistencies, ensuring high-quality API specification descriptions.

[0060] In this embodiment of the application, the above method can effectively identify and generate first process information (exemplary path) with high standardization indicators and second process information (descriptive path) with high readability indicators from the logical blocks. Through intelligent fusion and conflict arbitration mechanisms, comprehensive, accurate and easy-to-understand API specification description fragments are generated and finally integrated into a complete API specification document.

[0061] Step S108: Based on the target process information, generate the target document for the application programming interface.

[0062] In the technical solution of step S108 of the present invention, the target document can be used to describe the interactive behavior completed by the execution operation flow of the application programming interface. The target document can refer to the API specification document after intelligent fusion and conflict resolution. This target document integrates the high standardization indicators of the first process information (exemplary path) and the high readability indicators of the second process information (descriptive path) to describe the way the API executes its operation flow and completes interactive behavior. The target document serves as a communication bridge between API developers, testers, and users, clarifying how the API is called, the required parameters, the expected response format, and other information. As a formal specification of the API, the target document provides a unified standard for API development, integration, testing, and management. It helps ensure API consistency, improves its discoverability, understandability, and interoperability, thereby promoting efficient collaboration within the software ecosystem.

[0063] In this embodiment, after fusing the normative indicators of the first process information and the readability indicators of the second process information to obtain the target process information, the target document of the application programming interface can be generated based on the target process information.

[0064] Optionally, metadata such as operation signatures, paths, HTTP methods, parameter names, data types, required status, and descriptions from the target process information are imported one by one into the corresponding fields of the target document. For each API operation, structured fields such as paths, methods, and parameter names (name, in, schema.type, required) are populated based on the exemplary path results in the target process information to ensure the document has an accurate operation flow. Based on the descriptive path results in the target process information, detailed descriptive metadata such as description, default value, enumeration value, and format are added to each parameter to enhance the readability and user-friendliness of the document. A comprehensive consistency check is performed on the above descriptions to ensure that the API operations described in the target document completely match the target process information, without omissions or redundant information. For any conflicts or inconsistencies that may exist between structured and descriptive information, such as different descriptions of parameter types, predefined conflict arbitration rules and confidence scoring mechanisms are applied to resolve them to maintain the accuracy and completeness of the document.

[0065] Optionally, verify that the target document fully conforms to the selected API specification format standard, including syntax, field naming, data type definitions, etc., to ensure the document's compliance. Perform overall document quality control, checking for syntax errors, formatting issues, missing or duplicate information, to ensure high-quality output. Automatically scan and mark sensitive parameters in the target document, adding security attributes to enhance the security of the API specification documentation. Supplement any missing technical details or parameter information to ensure that the API functionality described in the documentation is sufficiently detailed and usable.

[0066] Optionally, integrate the various filled-in, checked, adjusted, and enhanced information to generate the final API specification document. Perform a final review of the generated document, and once confirmed to be error-free, output it as a standard format document file. Save the API specification document to a specified location for access and use by API developers, testers, users, and automation tools.

[0067] In this embodiment of the application, the above method not only describes the process and interaction method of API operation in detail, but also ensures the standardization, readability, security and usability of the document.

[0068] In steps S102 to S108 of this application, multiple logical blocks of the original document of the application programming interface (API) are obtained. The original document at least describes the different functions of the API, and the logical blocks correspond to the functions. From the logical blocks, first process information and second process information corresponding to the functions of each logical block are identified. The first process information represents the first operation process to be executed to implement the function, and the second process information represents the second operation process to be executed to implement the function. The standardization index of the first operation process is greater than the standardization index of the second operation process, and the readability index of the second operation process is greater than the readability index of the first operation process. The standardization index of the first process information and the readability index of the second process information are fused to obtain target process information. Based on the target process information, a target document of the API is generated, wherein the target document describes the interactive behavior completed by the API executing the operation process. In other words, in this embodiment, intelligent segmentation preprocessing decomposes the original document into logical blocks corresponding to the API functions. By extracting highly standardized first-process information from logical blocks and easily understandable second-process information from natural language descriptions, and by prioritizing a fusion strategy that balances standardization and readability, information contradictions are resolved, and the consistency and completeness of information output are improved. This further optimizes the quality of process information, resulting in the final target document. The above method, through intelligent means, significantly improves the accuracy and processing efficiency of API information, reduces the burden of manually maintaining API specifications, and thus achieves the technical effect of improving the accuracy of information processing in application programming interfaces (APIs), solving the technical problem of low accuracy in API information processing.

[0069] The method described in this embodiment will be further described below.

[0070] As an optional embodiment, step S102, obtaining multiple logical blocks of the original document of the application programming interface, includes: identifying multiple anchor points of the application programming interface from the original document; using the multiple anchor points to split the original document to obtain logical blocks, wherein the logical block is a portion of the document between any two anchor points in the original document.

[0071] In this embodiment, the aforementioned anchor points can refer to specific information or formats in the original API documentation that can identify API operations (such as requests / responses, parameter definitions, sample code, etc.). Anchor points can be operation signatures, code examples, HTML tags, titles, etc. These anchor points can serve as reference points in the document for intelligent segmentation and information extraction.

[0072] For example, anchors can be of various types, including: operation signatures, code examples, HTML tags, and titles and descriptions. The operation signature, for instance, can be a unique identifier for the API call, containing the HTTP method (e.g., GET, POST) and resource path (e.g., / users / {userId}), explicitly specifying the API's operation. The code examples, such as Client Uniform Resource Locator (cURL) commands, object notation (e.g., JSON) request or response bodies, directly demonstrate the format and data structure of the API call. The HTML tags can be specific HTML tags (such as \) within an HTML document. <h2 id="get-users" \>、\<pre\> \<code\> () can be used as an anchor point to mark the title of an API operation or wrap code examples, helping the parser to locate information more accurately.

[0073] Optionally, during the process of obtaining multiple logical blocks from the original document, multiple anchor points of the application programming interface can be identified from the original document. These multiple anchor points can then be used to split the original document into multiple logical blocks.

[0074] Optionally, in order to intelligently extract information from the original API documentation, logical blocks can be formed to facilitate further parsing and processing.

[0075] Optionally, receive a raw document containing an API description, which can be in HTML, Markdown, plain text, or other formats. Prepare a parser for document scanning and anchor point recognition. Begin traversing the entire content of the raw document. Look for and mark API operation signatures (HTTP method plus resource path) such as GET / users / {id}. Look for and mark code example areas, such as cURL commands or JSON formatted request / response bodies. Identify specific tags (such as those with IDs) in the HTML document.< / h2> <h2>Label, <pre> <code>Tags are used to help locate the start and end points of API operations.

[0076] Optionally, the first of the identified anchor points is selected as the starting point. For each anchor point in the document, the following steps are performed: find the nearest subsequent anchor point after the current anchor point. The document content between the current anchor point and the next anchor point (excluding the next anchor point itself) is truncated to form an independent logical block. This logical block is stored, containing all relevant information for an API operation.

[0077] In this embodiment of the application, the above method can ensure that information is extracted accurately and efficiently from the original API document, forming independent blocks that are easy to process and standardize, thus providing a foundation for the subsequent generation of high-quality API specifications.

[0078] As an optional embodiment, identifying multiple anchor points of the application programming interface from the original document includes: determining operation signatures and / or code examples identified from the original document as anchor points; the method further includes: in response to the absence of operation signatures or operation signature code examples in the original document, determining hypertext markup language tags identified from the original document as anchor points.

[0079] In this embodiment, an operation signature can be a unique identifier for an API call, consisting of the API request method (such as GET, POST, PUT, DELETE) and the resource path requested. For example, "GET / users / {id}" is a typical operation signature, indicating an API operation to retrieve a user's information, where GET is the HTTP request method and / users / {id} is the resource path, explicitly specifying how to access or manipulate a specific resource. In API documentation, operation signatures often appear at the beginning of the description of each API endpoint, serving as the basis for identifying and distinguishing different API calls.

[0080] Optionally, code examples can refer to sample code provided in the API documentation, demonstrating how to actually call or use the API interface. Common code examples include, but are not limited to, cURL commands, function calls or class implementations using a programming language, and JSON-formatted request and response bodies. These code examples can provide specific format and syntax examples for API calls, helping developers understand and test the API.

[0081] Optionally, HTML tags can be the basic elements that make up an HTML document, used to define the structure and content of a webpage. In API documentation, these HTML tags can be used for highlighting, formatting text, or creating links. For intelligent parsing of API documentation, certain HTML tags or their attributes can serve as auxiliary anchors for identifying API operations.

[0082] Optionally, in the process of identifying multiple anchor points of the application programming interface from the original document, the operation signature and / or code example identified from the original document can be identified as anchor points. If no operation signature or code example is identified from the original document, HTML tags can be identified from the original document and identified as anchor points.

[0083] Optionally, receive the raw document containing API information. Initialize the document parser and rules engine, and configure LLM call parameters. Look for operation signatures (such as HTTP methods and resource paths) related to the API. Search the document for patterns like GET / users / {userId}. Record the start and end positions of each operation signature in the document. Check if the operation signatures are closely related to the API's description text or code examples.

[0084] Optionally, search documents for code blocks containing examples of cURL, JSON, or other programming languages. Leverage the specific syntax (such as curl-X GET, {"id":123}) or semantic features of the code blocks. Mark the locations of code examples, treating them as potential anchors.

[0085] Optionally, confirm whether the anchors identified in the above steps cover all API operations described in the documentation. Prioritize operation signatures and code examples as high-priority anchors. If an API operation description in the documentation lacks a corresponding operation signature or code example—for example, a paragraph describes the functionality of an API operation in detail but doesn't explicitly show GET, POST, or cURL commands—use heading tags, semantic paragraphs, or other HTML tags as alternative anchors. If no operation signature or code example is available, utilize... <h2>、< / h2> <h3>Use heading tags as anchor points. Locate paragraphs describing API functionality and try to infer the nature of the API operations from them. For example... <pre>、 <code>These tags may wrap API descriptions that are not explicitly marked as code examples.

[0086] Optionally, the document is segmented into logical blocks using defined anchor points (operation signatures, code examples, or fallback anchors). Each logical block defines a complete description of an API operation. Ensure the segmentation logic does not omit key information or incorrectly merge different API operation descriptions. Check that each block contains sufficient information to describe an API operation. If an inaccurate block scope or incomplete information is found, reposition the anchor points and adjust the segmentation. Generate a list or data structure containing the locations of each anchor point and its corresponding logical block, providing a foundation for subsequent API specification generation.

[0087] As an optional embodiment, the first process information is an exemplary process, and the second process information is a descriptive process. Step S104 involves identifying the first process information and the second process information of the function corresponding to the logical block from the logical block, including: inputting code examples extracted from the logical block into the large language model, and generating an exemplary process based on the code examples using the large language model; and inputting text information extracted from the logical block into the large language model, and generating a descriptive process based on the text information using the large language model.

[0088] In this embodiment, the aforementioned exemplary process can also be referred to as an exemplary path. The aforementioned descriptive process can be a descriptive path. During the process of identifying the first process information and the second process information from the logical block, code examples extracted from the logical block can be input into a large language model, and the large language model can generate an exemplary process based on the code examples. Alternatively, text information extracted from the logical block can be input into the large language model, and the large language model can generate a descriptive process based on the text information.

[0089] Optionally, the system comprises a set of intelligently segmented logical blocks, each containing a description of an API operation. Code examples, such as cURL commands, JSON-formatted request and response bodies, are extracted from the logical blocks. The code examples are prepared, ensuring proper formatting and removing irrelevant noise (such as comments and redundant spaces). Natural language descriptions, parameter tables, and other textual information are extracted from the blocks. The text is cleaned, formatted, and irrelevant details, such as redundant titles and author information, are removed.

[0090] Optionally, invoke LLM, inputting a preprocessed code example. Based on the code example, generate structured information for the API operation, such as HTTP method, path, parameter types, required fields, etc. Output exemplary flow information, i.e., the core technical details of the API operation. Invoke LLM again, inputting cleaned text information, including parameter descriptions, example values, remarks, etc. Parse the descriptions in the text to generate auxiliary information for the API operation, such as parameter descriptions, default values, enumeration values, formats, etc. Output descriptive flow information, i.e., the metadata or auxiliary descriptive fields of the API operation.

[0091] Optionally, a large language model can be called via API, passing code examples as input. The structured information returned by the LLM is received and converted into a data structure adapted to the API specification format. Similarly, the LLM is called via API, this time passing text information. The descriptive metadata returned by the LLM is also received and converted into a data structure adapted to the API specification.

[0092] In the embodiments of this application, the above method processes exemplary and descriptive information in parallel, and then performs intelligent fusion and optimization to ensure that the generated API specification accurately reflects the actual calling characteristics of the API and fully describes the usage context and details of the API, thus achieving high efficiency and high accuracy in API specification generation.

[0093] As an optional implementation method, code examples extracted from the logical blocks are input into a large language model. Based on the code examples, the large language model is used to generate a demonstrative process, including: using the large language model to generate structured information corresponding to the function based on the received code examples; and determining the demonstrative process based on the structured information.

[0094] In this embodiment, during the process of generating a demonstrative process based on code examples using a large language model, a large-scale model can be used to generate structured information corresponding to the functions based on the received code examples. The demonstrative process can then be determined based on this structured information.

[0095] Optionally, logical blocks are obtained from intelligent segmentation of the document, with each block corresponding to a description of an API operation. Within each logical block, code examples such as cURL commands and JSON request / response bodies are located and identified. These code examples are then separated from the block and prepared as input for the LLM. The code examples are ensured to be correctly formatted; for example, the cURL command syntax is correct, and the JSON structure is error-free. Comments, debugging information, or any irrelevant content that might interfere with the correct parsing by the LLM are removed from the examples.

[0096] Optionally, determine which large language model to use and configure necessary calling parameters, such as model version, temperature (affecting the randomness of generated results), maximum output length, etc. Transform the code example into an LLM-processable format, potentially including specific input prompts such as "parse the HTTP method and path of the following cURL command" or "identify parameter names and types in a JSON structure." Call the large language model via API, using the preprocessed code example as input.

[0097] Optionally, the output returned by the LLM can be transformed into understandable structured data, such as extracting information like HTTP methods, paths, parameter names, types, and whether they are required. Ensure that the parsed information conforms to specific output specifications, such as the Open API Specification (OAS) format, and populate the information into the corresponding fields (e.g., name, in, schema.type, required, etc. in paths, methods, and parameters).

[0098] Optionally, verify the accuracy and completeness of the parsed structured information. If necessary, correct the information generated by the LLM, for example, clarifying ambiguous parameter types and supplementing missing required fields. Based on the corrected structured information, define a demonstrative process, i.e., a structured description of the API call, ensuring it accurately reflects the API's functionality and usage.

[0099] In this embodiment, the above method ensures intelligent parsing of code examples and generation of structured information, thus providing a solid foundation for determining exemplary processes. This method allows for the capture of key technical details from actual API usage examples and their structured expression, providing accurate data support for subsequent specification generation and intelligent integration.

[0100] As an optional implementation method, the text information extracted from the logical block is input into a large language model. Based on the text information, the large language model generates a descriptive process, including: using the large language model to generate descriptive meta-information corresponding to the function based on the received text information, wherein the text information includes at least one of the following: natural language description, parameter table, and example value; and determining the descriptive process based on the descriptive meta-information.

[0101] In this embodiment, during the process of generating a descriptive flow based on text information using a large language model, the large language model can be used to generate descriptive meta-information corresponding to the function based on the received text information. Therefore, a descriptive flow can be generated based on the aforementioned descriptive meta-information.

[0102] Optionally, the logical blocks obtained through intelligent segmentation each focus on the description of a single API operation. Within each logical block, text information is searched and extracted, including but not limited to: natural language descriptions—descriptive text about the purpose of the API operation, the meaning of parameters, expected responses, etc.; parameter tables—tables listing the parameters used when the API is called, along with their types, descriptions, default values, etc.; and example values—example numerical values ​​or response examples that specific parameters may carry.

[0103] Optionally, ensure the extracted information is clean and formatted for LLM to understand and process. Convert text information to a uniform format, such as removing unnecessary whitespace and ensuring consistent table headers. Based on the type of information to be extracted, construct appropriate input formats or guiding statements to help LLM understand the type of metadata to be generated. Set LLM call parameters, including model version, instructions, or prompts, to ensure the model focuses on generating descriptive metadata. Combine the standardized text information and input prompts into an LLM-acceptable input format. Call a large language model via API, sending the constructed input to the model for processing.

[0104] Optionally, the LLM text output can be parsed into structured descriptive metadata, such as parameter descriptions, default values, enumeration values, and formats. Ensure the parsed descriptive information is formatted correctly to facilitate further processing and integration into the API specification. Verify the accuracy and reasonableness of the descriptive metadata, correcting any potential errors or inconsistencies. Add descriptive metadata that the LLM failed to generate, or make reasonable inferences and extensions based on existing descriptive information.

[0105] Optionally, the revised and improved descriptive metadata can be integrated to define a descriptive process, i.e., a descriptive-level specification for API operations. It is confirmed that the generated descriptive process contains all necessary descriptive metadata and meets the requirements of the API specification.

[0106] In this embodiment, the method focuses on extracting rich descriptive content from API documentation and transforming it into structured descriptive meta-information using LLM, further forming a descriptive flow and enhancing the readability and comprehensibility of the API specification. Through in-depth parsing of natural language, subtle differences and special requirements in API usage can be captured, thereby improving the quality and usability of the generated API specification.

[0107] As an optional embodiment, step S106 involves fusing the normative indicators of the first process information and the readability indicators of the second process information to obtain target process information. This includes: determining the target process information based on the priorities of the first and second process information when they are not contradictory; in response to the contradiction between the first and second process information, calling a large language model to determine the confidence levels of the first and second process information respectively; and determining the target process information based on the confidence levels of the first and second process information.

[0108] In this embodiment, a contradictory state can refer to different or inconsistent interpretations given for the same technical detail (such as parameter type, required options, etc.) in the exemplary process information and the descriptive process information. Such contradictory states can stem from unclear original documents, misunderstandings of the LLM, or errors in data processing.

[0109] Optionally, the confidence level can be a metric used to measure the reliability of the LLM-generated results. In this embodiment, the confidence level can be used to reflect the LLM's confidence in the specific API details it has parsed. A higher confidence level indicates greater confidence in the accuracy of the generated results. The aforementioned priority can refer to the principle of prioritizing certain fields or information types over exemplary process information and descriptive process information. This can be based on the nature of the field itself and an assessment of its importance to the API specification.

[0110] Optionally, during the fusion of the first and second process information, if the first and second process information are not contradictory, the target process information can be determined based on their respective priorities. If the first and second process information are contradictory, a large language model can be invoked to determine the confidence levels of the first and second process information, respectively, thereby determining the target process information based on the confidence levels.

[0111] Optionally, compare the descriptions of the same API details in the exemplary and descriptive processes. Determine if there are inconsistencies or contradictions in technical details, such as parameter types or required fields. When the exemplary and descriptive process information is consistent, merge them according to a preset priority strategy. For structured fields (such as name, in, schema.type, required), the exemplary process information takes precedence. For descriptive fields (such as description, default, enum, format), the descriptive process information takes precedence.

[0112] Optionally, when a contradiction is detected, the large language model is invoked again to obtain the confidence score for each path for the same field. The output of the exemplary path is analyzed to obtain the confidence score, such as the logprobs generated by the LLM for type:integer. The output of the descriptive path is also analyzed to obtain the confidence score, such as the logprobs generated by the LLM for type:string. If the exemplary path generates a higher confidence score, then type:integer is adopted; if the descriptive path generates a higher confidence score, then type:string is adopted. Based on the confidence scores, it is determined which information source's description is more accurate, thereby determining the target flow information to be fused.

[0113] Optionally, exemplary process information and descriptive process information are integrated according to a dynamic prioritization strategy and the results of conflict arbitration. This generates the final target process information, which is an API specification description containing both normative and readable information.

[0114] In this embodiment, the method described above, through a dynamic priority and confidence arbitration mechanism, ensures the generation of the most accurate and complete API specification description under both contradictory and non-contradictory conditions. It not only effectively integrates information on both standardization and readability but also handles information conflicts through an intelligent decision-making mechanism, thereby improving the accuracy and robustness of the generated specification.

[0115] As an optional embodiment, step S108, the target process information is a document fragment to be adjusted, and based on the target process information, a target document for the application programming interface is generated, including: integrating the document fragments to be adjusted corresponding to multiple logical blocks to obtain the document to be adjusted; calling the large language model to adjust the document to be adjusted to obtain the target document, wherein the generality of the target document is greater than that of the document to be adjusted.

[0116] In this embodiment, the document fragment to be adjusted can be the preliminary integration result representing the API operation descriptions in each logical block after the intelligent fusion phase. This document fragment may contain a fused output of exemplary and descriptive process information, aiming to describe the standardization and readability details of a single API operation. The document to be adjusted can be a complete API specification draft obtained by integrating the document fragments corresponding to multiple logical blocks. It can also be a collection of documents containing descriptions of various API operations, aiming to provide a structured and readable specification draft for the API.

[0117] Optionally, during the process of generating the target document based on the target process information, the document fragments to be adjusted corresponding to multiple logical blocks can be integrated to obtain the document to be adjusted for the application programming interface. A large language model can then be invoked to adjust the document to be adjusted, resulting in the target document.

[0118] Optionally, each logical block, after intelligent fusion and adjustment, generates a document fragment to be adjusted, containing standardized and readable information. These document fragments for different API operations are then aggregated into a coherent whole document. The document fragments for each logical block are collected. These fragments are organized according to the API operation signature or logical order to ensure a clear document structure. The fragments are then pieced together to form the document to be adjusted. This document is a draft-level API specification, covering descriptions of various API operations, but its universality and format consistency may still have room for improvement.

[0119] Optionally, the universality of the document to be adjusted can be improved, making it more standardized and easier to understand and apply across platforms and languages. The same document to be adjusted can be integrated as input context and provided to a large language model for processing. Explicit instructions can be given to the LLM to check document consistency, supplement missing information, standardize descriptions, and improve the document's universality and readability. The LLM returns an optimized document where technical descriptions are more standardized, parameter naming and types follow common conventions, and descriptive text is easier to understand and apply, thereby increasing the overall universality of the document.

[0120] Optionally, generate the final Application Programming Interface (API) target documentation, which is highly versatile and readable. Based on feedback from the LLM, make final adjustments to the documentation to ensure formatting consistency, information completeness, and standards compliance. Generate and output the target documentation, which is the final version of the document to be adjusted using the LLM, possessing broad versatility and high readability, suitable for multiple development environments and languages.

[0121] In the embodiments of this application, the above method ensures that from detailed block-level processing to document-level adjustment and optimization, the final generated API target document not only accurately and in detail describes each API operation, but also achieves a high standard of universality and readability in terms of format, naming and description, which greatly facilitates the development, use and maintenance of API.

[0122] As an optional implementation method, a large language model is invoked to adjust the document to be adjusted to obtain a target document, including at least one of the following: invoking a large language model to adjust the natural language information in the document to be adjusted into structured language information to obtain a target document; invoking a large language model to add type parameters to the example values ​​in the document to be adjusted to obtain a target document; invoking a large language model to add security attributes to sensitive information in the document to be adjusted to obtain a target document, wherein the security attributes are used to improve the security level of the sensitive information.

[0123] In this embodiment, natural language information can be the portion of the API documentation written in everyday human language, including descriptions, comments, examples, etc., used to intuitively explain the API's functionality and usage. Capturing the richness and complexity of API details allows developers to understand the API's intent and behavior, but may lack structure and standardization, making it difficult for automated tools to parse.

[0124] Optionally, structured language information can be data organized in a predefined format, such as fields in an OpenAPI or JSON Schema. It can express various characteristics of the API in a machine-readable format. This makes the API specification a computer-processable document, facilitating the automated generation of client-side code, server-side tests, documentation tools, etc., thus improving the API's discoverability, understandability, and interoperability.

[0125] Optionally, the type parameter can be an attribute describing the data type, such as `format: "date-time"`, indicating that the parameter should be interpreted as date-time data. Explicitly defining the data type facilitates data validation, serialization, and deserialization, simplifying the understanding and processing flow for both the client and server. For example, parsing a time string into a date-time object.

[0126] Optionally, sensitive information can refer to data that requires special protection, such as API keys, user credentials, and private data. Identifying and properly handling sensitive information is crucial to ensuring API security and compliance. Improper exposure of sensitive information can lead to serious security vulnerabilities.

[0127] Optionally, security attributes can be flags appended to API parameters to indicate how these parameters should be processed and transmitted, such as `writeOnly:true` or `format:"password"`. These security attributes provide additional guidance on the handling of sensitive information. `writeOnly:true` can indicate that the parameter is only used to write the request and should not be returned in the response, preventing the leakage of sensitive data. `format:"password"` can indicate how the password field should be handled, such as encrypted transmission and storage, protecting user privacy.

[0128] When using a large language model to adjust a document, the model can be used to convert natural language information into structured language information. It can also be used to add type parameters to example values ​​in the document. Furthermore, it can be used to add security attributes to sensitive information in the document, resulting in the target document.

[0129] Optionally, during the iterative Artificial Intelligence (AI) enhancement process, Large Language Models (LLMs) are used to further improve the quality of the document to be adjusted, transforming it into a target document. This adjustment process specifically includes three operations: converting natural language information into structured language information, adding type parameters to example values, and adding security attributes to sensitive information.

[0130] Optionally, information such as parameters, operations, and usage scenarios for each natural language description can be extracted from the document to be adjusted. These descriptions are then input into the LLM, which converts them into corresponding structured language information, such as fields from the OpenAPI specification. The LLM outputs a structured API specification, including fields such as parameter names, types, required parameters, descriptions, default values, and enumeration values, conforming to a standardized API documentation format.

[0131] Optionally, sample request and response values ​​can be identified from the documentation, such as JSON-formatted request or response bodies. These sample values ​​are then input into the LLM, which infers the parameter types based on their content and adds appropriate type parameters to each parameter, such as `format: "date-time"`. The LLM returns an API specification description with the added type parameters, making the parameter types clearer and more standardized, facilitating parameter validation during development and testing.

[0132] Optionally, fields that may contain sensitive information, such as API keys and user passwords, can be automatically identified from the document to be adjusted. The identified sensitive information fields are then input into the LLM, which automatically adds security attributes to these fields, such as `writeOnly: true` or setting `format: "password"`, to enhance the protection of sensitive information. The LLM returns an API specification enhanced with security attributes, ensuring that the transmission and storage of sensitive information during API calls are more secure and preventing information leakage.

[0133] In the embodiments of this application, the above method utilizes the powerful processing capabilities of large language models to transform API documents from a state to be adjusted into target documents, ensuring the accuracy, completeness, and security of API specifications.

[0134] Example 2

[0135] The technical solutions of the embodiments of the present invention will be illustrated below with reference to preferred embodiments.

[0136] Currently, with the popularization of microservice architecture and the development of the API economy, the number and complexity of APIs are exploding. To ensure API discoverability, understandability, and interoperability, the writing of API specifications is crucial. However, manually writing and maintaining API specifications is a time-consuming and error-prone task, especially when API documentation is scattered across various formats (such as HTML, Markdown, and plain text) and the information is inconsistent.

[0137] Existing API specification generation technologies primarily rely on: 1) Code parsing, which generates specifications directly from the API's source code (such as route definitions and controller methods). This method requires direct access to the API implementation and struggles with handling the API's documentation descriptions; 2) Direct LLM calls, which input the entire API document (even if very long) directly into a large language model (LLM), expecting it to output the specification in one go. This method is limited by the context length constraints of the LLM, and for large or complex API documents, it is prone to losing information or producing inaccurate output; 3) Template filling, which uses predefined templates and attempts to extract information from the document to fill in the gaps. This method has extremely high requirements for document format and content consistency and is relatively robust. Therefore, existing technologies still have many shortcomings in handling diverse and unstructured API documents, overcoming LLM context constraints, and improving the accuracy and completeness of generated specifications.

[0138] In this application embodiment, an API specification generation method is provided, which aims to solve the problems of low efficiency, poor accuracy, insufficient robustness and difficulty in handling long documents in the existing API specification generation technology. The method, device and system for generating API specifications based on multi-stage hybrid intelligence are proposed, which can effectively extract information from diverse original documents and generate high-quality, structured API specifications using LLM.

[0139] The embodiments of the present invention will be further described below.

[0140] Figure 2 This is a schematic diagram of an optional API specification generation system architecture based on multi-stage hybrid intelligence, according to an embodiment of this application, such as... Figure 2 As shown, this paper illustrates the overall architecture of an API specification generation system based on multi-stage hybrid intelligence, clearly demonstrating the key components and processing flow from raw documents to the generation of high-quality API specification documents. The system receives raw API documents, which may come from different formats and sources. It provides basic information about the API description, including operation signatures, parameters, descriptive paragraphs, and code examples. The system parses the raw documents, identifying operation signatures, code examples, and HTML tags as anchor points, and segments the documents into logical blocks. It circumvents LLM context length limitations, improving processing granularity and enhancing robustness. Information is extracted from code examples to generate API specification fragments focusing on structured data. The structured portion of the API specification is ensured to be accurate. Information is extracted from the natural language description of the documents to generate API specification fragments focusing on descriptive metadata. The descriptive content of the API specification is enriched, increasing its readability and comprehensibility. Based on a preset priority strategy and confidence score, the outputs of the exemplary path and descriptive path are merged to resolve information conflicts. The generated API specification fragments are ensured to be accurate, complete, and consistent. The adjusted document fragments corresponding to each logical block are integrated to form the document to be adjusted. Prepare a comprehensive draft document for subsequent iterative AI enhancements. Use a large language model to refine the integrated document, including converting natural language information into structured information, adding type parameters, and adding security attributes to sensitive information. Improve the document's universality, completeness, and security. Output the final, high-quality API specification document.

[0141] Optionally, intelligent segmentation preprocessing based on operation signatures and HTML tags: Receive the raw document (e.g., HTML, Markdown) containing API information. Utilize a predefined rule system to scan the document to identify API "operation signatures" (e.g., GET / users / {id}) or code examples (e.g., cURL commands, request / response JSON). Improvement: Extend anchor recognition capabilities to allow identification of specific tags in the HTML document (e.g., ... <h2 id="get-users-id">、 <pre> <code class="language-curl">These identified operation signatures, code examples, or specific HTML tags are used as "anchors." Based on these anchors, the original document is intelligently divided into multiple independent logical blocks, each corresponding to an API operation whenever possible. This process effectively circumvents the context length limitations of LLM and improves the granularity of subsequent processing. Robustness enhancement (segmentation fault tolerance): If an anchor is missing during segmentation (e.g., an API operation lacks a clear code example or operation signature), the system can fall back to a header-based approach (e.g., ...). <h2>The process is segmented by the patterns of tags and paths to ensure continuity.

[0142] Optionally, the system performs parallel generation and fusion of demonstrative and descriptive information in two paths: For each segment's logical block, the system executes the following two processing paths in parallel: Demonstrative path: Extracts the code examples contained therein (such as cURL commands, request / response JSON). Using a Large Language Model (LLM), an API operation fragment focusing on structured information (e.g., fields like name, in, schema.type, required, etc. in OpenAPI's paths, methods, and parameters) is generated based on the extracted code examples. Descriptive path: Extracts the text information contained therein, such as natural language descriptions, parameter tables, and example values. Using an LLM, an API operation fragment focusing on descriptive metadata (e.g., fields like description, default, enum, format, etc. in OpenAPI's parameters) is generated based on the extracted text information.

[0143] Optionally, the intelligent fusion module designs an intelligent fusion strategy to merge API operation fragments generated by the exemplary path and the descriptive path. Robustness enhancement (conflict arbitration): When contradictory information appears in the results of the two paths (e.g., the code example shows a parameter of type integer, while the text description claims it is of type string), a confidence scoring mechanism is introduced. The log probability (logprobs) or other confidence metrics output by the LLM are used to dynamically determine which path's result is prioritized. For example, if the LLM has higher confidence when generating integer types, the result of the exemplary path is adopted. Merging is performed according to preset priorities (e.g., structural fields such as name, in, schema.type prioritize the results of the exemplary path; descriptive fields such as description, default, enum prioritize the results of the descriptive path) to resolve conflicting information and ensure the completeness and accuracy of the final API operation fragment.

[0144] Optionally, iterative AI enhancement based on the generated results: The initially fused API specification is used as the input context. The LLM is invoked again to perform refinement and enhancement tasks. The goal of this stage is to improve the completeness, accuracy, and machine readability of the specification. Iterative content enhancement: Specific patterns in the parameter description text (such as "default value is X", "optional", "must be Y") are parsed and transformed into structured OAS fields (such as default:X, required:false, enum:[...]). Technical point supplementation (format inference): Based on parameter types and example values, more precise data patterns are inferred and populated; for example, date strings are automatically identified and formatted as date-time. Potential type mismatches or format errors are checked and corrected. Security extension: Sensitive parameter detection is added at this stage; for example, API key fields are identified and automatically marked as writeOnly:true to enhance security.

[0145] Figure 3 This is a flowchart illustrating an optional API specification generation method based on multi-stage hybrid intelligence according to an embodiment of this application, as shown below. Figure 3 As shown, the method may include the following steps:

[0146] Step S301: Receive the original API documentation.

[0147] Step S302: Identify anchor points.

[0148] In this embodiment, when the system receives a raw API document (e.g., a Markdown file containing descriptions of multiple API endpoints), it starts a document parser to scan the document content. The parser uses predefined rules to identify operation signatures such as GET / users / {userId}, cURL commands such as curl -XGET "http: / / example.com / users / 123", and code blocks containing JSON request or response bodies.

[0149] Optionally, the improvement in this embodiment is that, for HTML documents, the parser also identifies HTML tags with specific IDs or classes, such as...< / h2> <h2> GET / items / {id}< / h2> or <pre> <code class="language-json">{...}< / code> < / pre> These can also be used as potential "anchor points".

[0150] Step S303: Is the anchor point missing?

[0151] In this embodiment, if the anchor point is missing, step S304 can be executed; otherwise, if the anchor point is not missing, step S305 can be executed.

[0152] Step S304: Return to title + path mode.

[0153] In this embodiment, a segmented fault-tolerance mechanism is used to enhance robustness. If an API operation does not have an explicit operation signature or code example in the documentation, but has a clear title (such as ###User Endpoint), it can be rolled back, using the title (possibly combined with path information) as the basis for segmentation, ensuring that no content is missed.

[0154] Step S305: Has the document been traversed completely?

[0155] In this embodiment, it can be determined whether the document has been traversed. If the traversal is complete, step S306 can be executed; otherwise, step S302 can be executed.

[0156] Step S306: Divide into logical blocks.

[0157] In this embodiment, the original document is intelligently segmented based on the identified anchor points. For example, if the signature `GET / users` is detected in the document, and it is immediately followed by a paragraph describing the operation and a related cURL example, then the part containing this content will be divided into a separate logical block.

[0158] Step S307: Extract the code example.

[0159] In this embodiment, code examples such as cURL commands and request / response JSON are extracted from the current block.

[0160] Step S308: LLM generates structured fragments.

[0161] In this embodiment, the extracted code examples are fed into a large language model (LLM). The LLM is instructed to generate structured information for API operations based on these examples, such as parsing the HTTP method, URL path, and request headers in cURL commands, parsing parameter names, types, and whether they are required from JSON, and populating the OpenAPI specification's paths, methods, parameters (name, in, schema.type, required), and other fields.

[0162] Step S309: Extract the text description.

[0163] In this embodiment, text information such as natural language descriptions, parameter tables, and example values ​​are extracted from the current block.

[0164] Step S310: LLM generates descriptive fragments.

[0165] In this embodiment, this textual information is fed into another (or the same) LLM. The LLM is instructed to generate descriptive meta-information for API operations based on these descriptions, such as populating fields like description, default, enum, etc., for parameters, and inferring the format of the parameters (e.g., date format) based on the descriptions.

[0166] Step S311: Intelligent integration of demonstrative and descriptive paths.

[0167] In this embodiment, the intelligent fusion module receives outputs from the exemplary path and the descriptive path. It intelligently fuses the structured and descriptive fragments, adjusting the results according to preset priorities and confidence scores. This ensures that the generated API specification fragments are both accurate and detailed, without information conflicts. For structured fields such as name, in, schema.type, and required, the results from the exemplary path are given priority; for descriptive fields such as description, default, enum, and format, the results from the descriptive path are given priority.

[0168] Step S312, conflict arbitration.

[0169] In this embodiment, when the results of the exemplary path and the descriptive path conflict, the system determines which path's result to adopt based on the confidence score. This improves the accuracy and consistency of API specification generation. Conflict arbitration is performed in robustness enhancements. When two paths generate contradictory information for the same field (e.g., the exemplary path resolves to `type:integer`, while the descriptive path infers `type:string` from the text), the system checks the confidence scores (e.g., logprobs) when the LLM generated these two pieces of information. If the exemplary path has a higher confidence score, `integer` is adopted; otherwise, `string` is adopted. This dynamic prioritization mechanism improves the accuracy of the fusion result. An efficiency-optimized caching mechanism comes into play at this stage: if a code example (such as a standard authentication cURL request) appears repeatedly in multiple blocks, the system caches its structured generation results to avoid repeated calls to the LLM.

[0170] Step S313: Generate preliminary API specifications.

[0171] In this embodiment, the API specification fragment after preliminary fusion is output.

[0172] Step S314, iterative AI enhancement.

[0173] In this embodiment, the various initially merged API specification fragments are integrated into a complete API specification draft, which is then used as context input to another LLM instance. Fine-grained tasks are performed, such as parsing natural language patterns in parameter descriptions like "default value is 10," "optional parameter," and "must be 'A', 'B'," and converting them into structured fields like default:10, required:false, and enum:["A","B"]` from the OpenAPI specification.

[0174] Optionally, format inference in the technical point supplement can be implemented. For example, if the sample value of a parameter is "2023-10-27T10:30:00Z", LLM will recognize that this is a date and time string in ISO 8601 format and automatically add format:"date-time" to it. Security extensions are performed. LLM scans parameter names and descriptions, identifies fields that may contain sensitive information, such as api_key, secret, and token, and automatically adds attributes such as writeOnly:true or format:"password" to them to enhance security. An efficiency-optimized incremental update mechanism can be implemented here: if only part of the original document is modified, the generation and enhancement process can be re-executed only on the affected logical blocks, instead of a global recalculation.

[0175] Step S315: Output the final API specification.

[0176] In this embodiment, the final, high-quality API specification is output.

[0177] Example 3

[0178] According to an embodiment of this application, an information processing apparatus for an application programming interface (API) used to implement the information processing method of the application programming interface in Embodiment 1 is also provided, such as... Figure 4 As shown, the information processing device of this application programming interface includes at least: an acquisition module 41, an identification module 42, a fusion module 43, and a generation module 44, wherein:

[0179] The acquisition module 41 is used to acquire multiple logical blocks of the original document of the application programming interface, wherein the original document is used to describe at least the different functions of the application programming interface, and the logical blocks correspond to the functions.

[0180] The identification module 42 is used to identify the first process information and the second process information of the function corresponding to the logical block from the logical block. The first process information is used to represent the first operation process that should be executed to implement the function, and the second process information is used to represent the second operation process that should be executed to implement the function. The standardization index of the first operation process is greater than the standardization index of the second operation process, and the readability index of the second operation process is greater than the readability index of the first operation process.

[0181] The fusion module 43 is used to fuse the standardization indicators of the first process information and the readability indicators of the second process information to obtain the target process information.

[0182] The generation module 44 is used to generate a target document for the application programming interface based on the target process information. The target document describes the interactive behavior of the application programming interface to complete the operation process and the information processing of the application programming interface.

[0183] It should be noted that each module in the information processing device of the application programming interface in this embodiment corresponds one-to-one with each implementation step of the information processing method of the application programming interface in embodiment 1. Since embodiment 1 has been described in detail, some details not shown in this embodiment can be referred to embodiment 1, and will not be elaborated further here.

[0184] Example 4

[0185] According to an embodiment of this application, a computer program product is also provided, which includes a computer program, wherein when the computer program is executed by a processor, it implements the information processing method of the application programming interface in Embodiment 1.

[0186] According to an embodiment of this application, a non-volatile storage medium is also provided, which includes a stored computer program, wherein the device where the non-volatile storage medium is located executes the information processing method of the application programming interface in Embodiment 1 by running the computer program.

[0187] According to an embodiment of this application, a processor is also provided for running a computer program, wherein the computer program executes the information processing method of the application programming interface in embodiment 1 during runtime.

[0188] According to an embodiment of this application, an electronic device is also provided, comprising: a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the information processing method of the application programming interface in Embodiment 1 through the computer program.

[0189] Specifically, a computer program, when running, can execute the following steps: Obtain multiple logical blocks from the original document of the application programming interface (API), wherein the original document at least describes the different functions possessed by the API, and the logical blocks correspond to the functions; From the logical blocks, identify first process information and second process information corresponding to the functions of the logical blocks, wherein the first process information represents the first operation process to be executed to implement the function, and the second process information represents the second operation process to be executed to implement the function, wherein the standardization index of the first operation process is greater than the standardization index of the second operation process, and the readability index of the second operation process is greater than the readability index of the first operation process; Fuse the standardization index of the first process information and the readability index of the second process information to obtain target process information; Based on the target process information, generate a target document for the API, wherein the target document describes the interactive behavior to be completed by the API executing the operation process.

[0190] As an alternative implementation, the above-mentioned electronic device may exist in the form of a mobile terminal, a computer terminal, or a similar computing device. Figure 5 A hardware block diagram of an electronic device for implementing an application programming interface (API) information processing method is shown. Figure 5 As shown, the electronic device 50 may include one or more processors 502 (shown as 502a, 502b, ..., 502n in the figure) 502 (processor 502 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 504 for storing data, and a transmission device 506 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 5 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device described above. For example, electronic device 50 may also include... Figure 5 The more or fewer components shown, or having the same Figure 5 The different configurations shown.

[0191] It should be noted that the aforementioned one or more processors 502 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element of the electronic device 50. As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0192] The memory 504 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the information processing method of the application programming interface in this embodiment. The processor 502 executes various functional applications and data processing by running the software programs and modules stored in the memory 504, thereby implementing the above-mentioned application vulnerability detection method. The memory 504 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 504 may further include memory remotely located relative to the processor 502, and these remote memories can be connected to the electronic device 50 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0193] The transmission device 506 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the electronic device 50. In one example, the transmission device 506 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 506 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0194] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows the user to interact with the user interface of the electronic device 50.

[0195] According to another aspect of the embodiments of this application, a computer program product is also provided, the computer program product comprising: a computer program, wherein the computer program, when executed by a processor, implements the information processing method of the above-described application programming interface.

[0196] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0197] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0198] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the methods in various embodiments of this application.

[0199] According to another aspect of the embodiments of this application, a computer program is also provided, which, when executed by a processor, implements the methods of the various embodiments of this application.

[0200] The sequence numbers of the above embodiments are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0201] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

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

[0203] 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 units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0204] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

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

[0206] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.< / code> < / pre> < / h2> < / code> < / pre> < / h3> < / code> < / pre> < / h2>

Claims

1. An information processing method using an application programming interface, characterized in that, include: Obtain multiple logical blocks from the original document of the application programming interface, wherein the original document is used to describe at least the different functions of the application programming interface, and the logical blocks correspond to the functions; From the logical block, first process information and second process information of the function corresponding to the logical block are identified, wherein the first process information is used to represent the first operation process to be executed to implement the function, and the second process information is used to represent the second operation process to be executed to implement the function. The standardization index of the first operation process is greater than the standardization index of the second operation process, and the readability index of the second operation process is greater than the readability index of the first operation process. The standardization indicators of the first process information and the readability indicators of the second process information are fused to obtain the target process information; Based on the target process information, a target document for the application programming interface is generated, wherein the target document describes the interactive behavior completed by the application programming interface in executing the operation process.

2. The method according to claim 1, characterized in that, Retrieve multiple logical blocks from the original documentation of the application programming interface, including: From the original document, identify multiple anchor points of the application programming interface; The original document is split using multiple anchor points to obtain logical blocks, wherein the logical blocks are portions of the document between any two anchor points among the multiple anchor points in the original document.

3. The method according to claim 2, characterized in that, From the original document, several anchor points of the application programming interface were identified, including: The operation signature and / or code example identified from the original document will be used as the anchor point; The method further includes: in response to the absence of the operation signature or the code example in the original document, determining the Hypertext Markup Language tag identified from the original document as the anchor point.

4. The method according to claim 1, characterized in that, The first process information is an exemplary process, and the second process information is a descriptive process. The first and second process information, identified from the logical blocks, for the function corresponding to each logical block, include: The code example extracted from the logical block is input into the large language model, and the exemplary process is generated based on the code example using the large language model. The text information extracted from the logical block is input into the large language model, and the descriptive process is generated based on the text information using the large language model.

5. The method according to claim 4, characterized in that, The code example extracted from the logical block is input into the large language model. Using the large language model, based on the code example, the exemplary process is generated, including: Using the large language model, based on the received code example, generate structured information corresponding to the function; Based on the structured information, the exemplary process is determined.

6. The method according to claim 4, characterized in that, The text information extracted from the logical block is input into a large language model. Using the large language model, the descriptive flow is generated based on the text information, including: Using the large language model, based on the received text information, descriptive meta-information corresponding to the function is generated, wherein the text information includes at least one of the following: natural language description, parameter table, and example value; The descriptive process is determined based on the descriptive metadata.

7. The method according to claim 1, characterized in that, The standardization indicators of the first process information and the readability indicators of the second process information are fused to obtain target process information, including: In response to the fact that the first process information and the second process information are not contradictory, the target process information is determined based on the priorities corresponding to the first process information and the second process information, respectively. In response to the contradictory state between the first process information and the second process information, a large language model is invoked to determine the confidence levels of the first process information and the second process information, respectively; and based on the confidence levels of the first process information and the second process information, the target process information is determined.

8. The method according to claim 1, characterized in that, The target process information is a document fragment to be adjusted. Based on the target process information, the target document for the application programming interface is generated, including: The document fragments to be adjusted corresponding to the multiple logical blocks are integrated to obtain the document to be adjusted. The large language model is invoked to adjust the document to be adjusted, resulting in the target document, wherein the generality of the target document is greater than that of the document to be adjusted.

9. The method according to claim 8, characterized in that, The large language model is invoked to adjust the document to be adjusted, resulting in the target document, which includes at least one of the following: The large language model is invoked to adjust the natural language information in the document to be adjusted into structured language information, thereby obtaining the target document; The large language model is invoked to add type parameters to the example values ​​in the document to be adjusted, thereby obtaining the target document; The large language model is invoked to add security attributes to sensitive information in the document to be adjusted, thereby obtaining the target document, wherein the security attributes are used to improve the security level of the sensitive information.

10. An information processing device with an application programming interface, characterized in that, include: An acquisition module is used to acquire multiple logical blocks of the original document of the application programming interface, wherein the original document is used to describe at least the different functions of the application programming interface, and the logical blocks correspond to the functions. The identification module is used to identify first process information and second process information of the function corresponding to the logical block from the logical block, wherein the first process information is used to represent a first operation process that should be executed to implement the function, the second process information is used to represent a second operation process that should be executed to implement the function, the standardization index of the first operation process is greater than the standardization index of the second operation process, and the readability index of the second operation process is greater than the readability index of the first operation process. The fusion module is used to fuse the normative indicators of the first process information and the readability indicators of the second process information to obtain target process information. The generation module is used to generate a target document for the application programming interface based on the target process information, wherein the target document is used to describe the interactive behavior completed by the application programming interface in executing the operation process.

11. A computer program product, characterized in that, include: A computer program, wherein when executed by a processor, the computer program implements the information processing method of the application programming interface according to any one of claims 1 to 9.

12. An electronic device, characterized in that, include: A memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute, through the computer program, the information processing method of the application programming interface according to any one of claims 1 to 9.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the storage medium is located to perform the information processing method of the application programming interface according to any one of claims 1 to 9.

Images