CN115113854A

CN115113854A - Interface document generation method, device, equipment and computer readable storage medium

Info

Publication number: CN115113854A
Application number: CN202110309768.7A
Authority: CN
Inventors: 支猛
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2021-03-23
Filing date: 2021-03-23
Publication date: 2022-09-27

Abstract

The application provides an interface document generation method, device, equipment and a computer readable storage medium; the method comprises the following steps: code submitting information sent by the code warehouse in response to the code submitting event is acquired; inquiring interface document information corresponding to the project branches in a database to generate an inquiry result; generating a file list to be analyzed based on the query result; the file list to be analyzed comprises at least one change code source file; analyzing the code source file in the file list to be analyzed, and updating the interface document information of the project branch; in response to an interface document viewing event for a project branch, an interface document is generated based on the interface document information. By the interface document generation method, the interface document can be automatically generated according to the submitted code source file, and the generation efficiency and timeliness of the interface document are improved.

Description

Interface document generation method, device, equipment and computer readable storage medium

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method, an apparatus, a device, and a computer-readable storage medium for generating an interface document.

Background

With the development of internet technology, more and more software developers will choose to open the program code completed by themselves to the outside in the form of service, and one set of service system corresponds to multiple APIs (Application Programming interfaces). In order to make other users conveniently use the API provided by themselves, the software developer needs to write a corresponding interface document for other users to review. The inventor finds in practice that most software developers tend to concentrate on programming and architecture, and are not good at writing documents, which tends to make the writing of documents less efficient. In addition, in the process of writing the interface document, a software developer needs to manually compare the function codes to obtain the content required by the interface document, so that the content is filled in the interface document, and the problem that the interface document is inconsistent with the function codes is easily caused by manual operation, so that the accuracy of the interface document is low.

Disclosure of Invention

The embodiment of the application provides an interface document generation method, device and equipment and a computer readable storage medium, which can automatically generate an interface document according to a submitted code source file, and improve the generation efficiency and timeliness of the interface document.

The technical scheme of the embodiment of the application is realized as follows:

the embodiment of the application provides an interface document generation method, which comprises the following steps: code submitting information sent by the code warehouse in response to the code submitting event is acquired; the code submission information comprises a change file list and item branches corresponding to the code submission event; the code submission event representation client submits at least one change code source file corresponding to the change file list to the code warehouse; inquiring interface document information corresponding to the project branches in a database to generate an inquiry result; the query result is used for representing whether interface document information corresponding to the item branch exists in the database or not; generating a file list to be analyzed based on the query result; the file list to be analyzed comprises at least one change code source file; analyzing the code source file in the file list to be analyzed, and updating the interface document information of the project branch; in response to an interface document viewing event for a project branch, an interface document is generated based on the interface document information.

In some embodiments of the present application, the method further comprises: receiving a generation request of virtual data aiming at a target interface; sending the target parameter information to a virtual data generator so that the virtual data generator generates virtual parameters corresponding to the target parameter information; and sending the virtual data containing the virtual parameters to the user side. Code submitting information sent by the code warehouse in response to the code submitting event is acquired; the code submission information comprises a change file list and item branches corresponding to the code submission event; the code submission event representation client submits at least one change code source file corresponding to the change file list to the code warehouse; inquiring interface document information corresponding to the project branches in a database to generate an inquiry result; the query result is used for representing whether interface document information corresponding to the item branch exists in the database or not; generating a file list to be analyzed based on the query result; the file list to be analyzed comprises at least one change code source file; analyzing a code source file in a file list to be analyzed, and updating interface document information of project branches; in response to an interface document viewing event for a project branch, an interface document is generated based on the interface document information.

An embodiment of the present application provides an interface document generating apparatus, where the apparatus includes:

the first acquisition module is used for acquiring code submission information sent by the code warehouse in response to a code submission event; the code submission information comprises a change file list and item branches corresponding to the code submission event; the code submission event representation client submits at least one change code source file corresponding to the change file list to the code warehouse;

the query module is used for querying interface document information corresponding to the project branches in the database and generating query results; the query result is used for representing whether interface document information corresponding to the project branch exists in the database or not;

the first generation module is used for generating a file list to be analyzed based on the query result; the file list to be analyzed comprises at least one change code source file;

the analysis module is used for analyzing the code source file in the file list to be analyzed and updating the interface document information of the project branch;

and the second generation module is used for responding to the interface document viewing event aiming at the project branch and generating the interface document based on the interface document information.

An embodiment of the present application provides an interface document generating device, including:

a memory for storing executable instructions;

and the processor is used for realizing the interface document generation method provided by the embodiment of the application when the executable instructions stored in the memory are executed.

The embodiment of the present application provides a computer-readable storage medium, which stores executable instructions for causing a processor to implement the interface document generation method provided by the embodiment of the present application when executed.

The embodiment of the application has the following beneficial effects:

according to the method and the device, the code submitting information sent by the code warehouse in response to the code submitting event is received, and then the interface document updating operation of the project branch corresponding to the code submitting event is executed, so that the timeliness of the interface document updating can be guaranteed. Meanwhile, whether the corresponding interface document information exists in the database or not is inquired through the code submitting event so as to determine a file list to be analyzed, all code source files can be analyzed under the condition that the interface document information is not generated in the project branch, and only the code source files in the changed file list can be analyzed under the condition that the interface document information is generated in the project branch, so that the analysis efficiency can be improved, and the problem of repeated analysis or missing of part of the code source files is avoided.

Drawings

FIG. 1 is an alternative architecture diagram of an interface document generation system provided by an embodiment of the present application;

FIG. 2 is a schematic structural diagram of an interface document generating device according to an embodiment of the present application;

FIG. 3 is a schematic flow chart of an alternative interface document generation method provided by the embodiment of the present application;

FIG. 4 is a schematic flow chart diagram of an alternative interface document generation method according to an embodiment of the present application;

FIG. 5 is a schematic flow chart of an alternative interface document generation method provided by the embodiment of the present application;

FIG. 6 is a schematic flow chart diagram of an alternative interface document generation method according to an embodiment of the present application;

FIG. 7 is a schematic flow chart diagram of an alternative interface document generation method according to an embodiment of the present application;

FIG. 8 is a schematic flow chart diagram illustrating an alternative interface document generation method according to an embodiment of the present application;

FIG. 9A is a schematic flow chart of an alternative interface document generating method according to an embodiment of the present disclosure;

FIG. 9B is a flowchart of a project creation process provided by an embodiment of the present application;

FIG. 9C is a flowchart of a project initialization process provided by an embodiment of the present application;

FIG. 9D is a flow diagram of a project update process provided by an embodiment of the present application;

FIG. 9E is a flowchart of an interface document viewing process provided by an embodiment of the present application;

fig. 9F is a flowchart of a virtual data generation process provided in an embodiment of the present application;

FIG. 10A is a diagram of a java source code file provided by an embodiment of the application;

FIG. 10B is a diagram illustrating a part of an abstract syntax tree of the Package information provided in the embodiment of the present application;

fig. 10C is a diagram illustrating a part of an abstract syntax tree of the Import information provided by an embodiment of the present application;

FIG. 10D is a diagram illustrating a portion of an abstract syntax tree for an interface definition provided by an embodiment of the present application;

FIG. 11A is a schematic diagram of an entry definition source code file provided in an embodiment of the present application;

FIG. 11B is a diagram illustrating an abstract syntax tree for an entry definition source code according to an embodiment of the present application;

FIG. 12A is a schematic diagram of a source code file for a referral definition provided by an embodiment of the application;

FIG. 12B is a diagram illustrating an abstract syntax tree for a source code of a parameter definition provided by an embodiment of the present application;

fig. 13A is a schematic diagram of interface definition source code of Go source code provided in an embodiment of the present application;

fig. 13B is a diagram of an abstract syntax tree of Go source code provided by an embodiment of the present application;

fig. 14 is a schematic diagram illustrating display of interface information and field information provided in an embodiment of the present application.

Detailed Description

In order to make the objectives, technical solutions and advantages of the present application clearer, the present application will be described in further detail with reference to the attached drawings, the described embodiments should not be considered as limiting the present application, and all other embodiments obtained by a person of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

In the following description, reference is made to "some embodiments" which describe a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict.

In the following description, the terms "first \ second \ third" are used merely to distinguish similar objects, and do not represent a specific ordering for the objects, and it should be understood that "first \ second \ third" may be interchanged under the permission of specific ordering or precedence, so that the embodiments of the present application described in the present embodiment can be implemented in an order other than that shown or described in the present embodiment.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of the present application only and is not intended to be limiting of the application.

Before further detailed description of the embodiments of the present application, terms and expressions referred to in the embodiments of the present application will be described, and the terms and expressions referred to in the embodiments of the present application will be used for the following explanation.

(1) AST: the abstract syntax tree is an abstract representation of the source code syntax structure. An abstract syntax tree is a syntax structure that represents a programming language in the form of a tree, where each node on the tree represents a structure in the source code. The syntax is said to be "abstract" in that the syntax does not represent every detail that appears in the true syntax. For example, nesting brackets are implicit in the structure of the tree and are not present in the form of nodes; whereas a conditional jump statement like if-condition-then can be represented using a node with three branches.

(2) Git: the open-source distributed version control system can effectively process the version management of projects from very small to very large at high speed. Such as Github et al.

(3) Webhook: the network hook is a method for increasing or changing the webpage representation by customizing a callback function. These callbacks may be saved, modified, and managed by third party users and developers who may be related to the original website or application.

(4) Code i.e. document: interfacing between different systems in software engineering requires the provision of interface documents (api), i.e. documents, in the form of interface documents generated by the code itself and optionally annotation notes.

Referring to fig. 1, fig. 1 is an alternative architecture diagram of an interface document generation system 100 provided in this embodiment of the present application, in order to implement supporting an interface document generation application, terminals (a terminal 400-1 and a terminal 400-2 are exemplarily shown) are connected to a server 200 through a network 300, and the network 300 may be a wide area network or a local area network, or a combination of the two. Fig. 1 further shows that the server 200 may be a server cluster, where the server cluster includes servers 200-1 to 200-3, and similarly, the servers 200-1 to 200-3 may be physical machines, or virtual machines constructed by using virtualization technologies (such as container technology and virtual machine technology), which is not limited in this embodiment, and of course, a single server may also be used to provide services in this embodiment.

Referring to fig. 2, fig. 2 is a schematic structural diagram of an interface document generating apparatus 500 provided in an embodiment of the present application, and the interface document generating apparatus 500 shown in fig. 2 includes: at least one processor 510, memory 550, at least one network interface 520, and a user interface 530. The various components in the interface document generation apparatus 500 are coupled together by a bus system 540. It is understood that the bus system 540 is used to enable communications among the components of the connection. The bus system 540 includes a power bus, a control bus, and a status signal bus in addition to a data bus. For clarity of illustration, however, the various buses are labeled as bus system 540 in FIG. 2.

The Processor 510 may be an integrated circuit chip having Signal processing capabilities, such as a general purpose Processor, a DiGital Signal Processor (DSP), or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, etc., wherein the general purpose Processor may be a microprocessor or any conventional Processor, etc.

The user interface 530 includes one or more output devices 531 that enable presentation of media content, including one or more speakers and/or one or more visual display screens. The user interface 530 also includes one or more input devices 532, including user interface components to facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

The memory 550 may comprise volatile memory or nonvolatile memory, and may also comprise both volatile and nonvolatile memory. The non-volatile Memory may be a Read Only Memory (ROM), and the volatile Memory may be a Random Access Memory (RAM). The memory 550 described in embodiments herein is intended to comprise any suitable type of memory. Memory 550 optionally includes one or more storage devices physically located remote from processor 510.

In some embodiments of the present application, memory 550 can store data to support various operations, examples of which include programs, modules, and data structures, or subsets or supersets thereof, as exemplified below.

An operating system 551 including system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks;

a network communication module 552 for communicating to other computing devices via one or more (wired or wireless) network interfaces 520, exemplary network interfaces 520 including: bluetooth, wireless compatibility authentication (WiFi), and Universal Serial Bus (USB), and the like;

a display module 553 for enabling the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 531 (e.g., a display screen, speakers, etc.) associated with the user interface 530;

an input processing module 554 to detect one or more user inputs or interactions from one of the one or more input devices 532 and to translate the detected inputs or interactions.

In some embodiments of the present application, the interface document generating apparatus provided in the embodiments of the present application may be implemented by a combination of hardware and software, and as an example, the interface document generating apparatus provided in the embodiments of the present application may be a processor in the form of a hardware decoding processor, which is programmed to execute the interface document generating method provided in the embodiments of the present application.

In some embodiments of the present application, the interface document generating apparatus provided in the embodiments of the present application may be implemented in software, and fig. 2 shows an interface document generating apparatus 555 stored in a memory 550, which may be software in the form of programs and plug-ins, and includes the following software modules: the first obtaining module 5551, the querying module 5552, the first generating module 5553, the parsing module 5554 and the second generating module 5555 are logical and thus may be arbitrarily combined or further split according to the implemented functions.

The functions of the respective modules will be explained below.

In other embodiments, the apparatus provided in the embodiments of the present Application may be implemented in hardware, and for example, the apparatus provided in the embodiments of the present Application may be a processor in the form of a hardware decoding processor, which is programmed to execute the interface document generating method provided in the embodiments of the present Application, for example, the processor in the form of the hardware decoding processor may be one or more Application Specific Integrated Circuits (ASICs), DSPs, Programmable Logic Devices (PLDs), Complex Programmable Logic Devices (CPLDs), Field Programmable Gate Arrays (FPGAs), or other electronic components.

In this embodiment of the present application, the interface document generation method provided in this embodiment is described with a server as an execution subject, where the server may be a document platform.

Referring to fig. 3, fig. 3 is an alternative flowchart of an interface document generating method provided in an embodiment of the present application, and will be described with reference to the steps shown in fig. 3.

In step 301, code submission information sent by the code repository in response to a code submission event is obtained; the code submission information comprises a change file list and item branches corresponding to the code submission event; and the code submitting event representation client submits at least one change code source file corresponding to the change file list to the code warehouse.

In some embodiments of the present application, the code repository is configured to receive a code source file submitted by a user. Prior to step 301, the method may further comprise: the code warehouse receives an item creating request for the item to be updated sent by the user side, and in response to the item creating request, the code warehouse creates a code item which is used for storing and managing a code source file of the item to be updated. After the creation of the code item is completed, after the code repository receives a code source file submitted by the user side for the item to be updated, a change file list corresponding to a current code submission event of the user side can be determined according to a historical code source file stored in the code item and the code source file submitted by the user at this time, and the change file list comprises at least one change code source file.

In some embodiments of the present application, different project branches may be set for the project to be updated in the code repository. The branch is an independent code environment which is used by a developer to develop different services at the same time and carry out cooperative test with a tester; the method can test the independent functions of the services and achieve no mutual influence among the services. The item to be updated may correspond to at least one item branch, and different item branches may be used to store different versions of code source files, i.e., all code source files in one item branch may be used to define all interfaces of the item to be updated.

In a further embodiment, during the process of submitting the code source file to the code repository, the user further specifies the project branch corresponding to the submitted code source file. Correspondingly, in the process of generating the code submitting information by the code warehouse based on the code submitting event, the corresponding code submitting information is generated according to the project branch and the change file list, and the code submitting information is sent to the document platform.

It should be noted that the code submission information may include at least one item branch, and for each item branch, the code submission information includes a change file list corresponding to each item branch. For convenience of understanding, the following embodiments further describe the case where the code submission information includes only one item branch and the change file list corresponding to the item branch.

In step 302, interface document information corresponding to the item branch is queried in a database to generate a query result; and the query result is used for representing whether interface document information corresponding to the item branch exists in the database.

In some embodiments of the present application, the document platform stores interface document information corresponding to all project branches of the project to be updated through a database, and the database may be set in a server corresponding to the document platform, and may also be set in other cloud servers. The interface document information is used for storing interface data corresponding to the project branch, and the interface data may include at least one interface corresponding to the project branch, and interface information and parameter information corresponding to each interface. Wherein the interface information may include at least one of: interface name, interface request path, Http method of interface request, access definition of interface, etc.; the parameter information may include: field name, field type, field description, whether padding is necessary, etc.

In some embodiments of the present application, the interface document information corresponding to the project branch may be a parsing result corresponding to each code source file corresponding to the project branch,

in step 303, a list of files to be analyzed is generated based on the query result; the file list to be parsed includes at least one change code source file.

In some embodiments of the present application, in a case that interface document information corresponding to the project branch does not exist in the database, it indicates that the code source file corresponding to the project branch is not received before the code repository, and therefore, the document platform does not parse the code source file corresponding to the project branch; it can also mean that even if the code repository has previously received the code source file corresponding to the project branch, the document platform does not receive the code submission information corresponding to the project branch due to the communication problem between the code repository and the document platform, and further does not parse the code source file corresponding to the project branch. Of course, there are other situations that cause the document platform not to have the interface document information corresponding to the project branch, and at this time, based on the situation that the database does not have the interface document information corresponding to the project branch, the generated to-be-parsed file list may include all the code source files corresponding to the project branch in the code repository.

In some embodiments of the present application, in a case that interface document information corresponding to the item branch exists in the database, it indicates that a code source file corresponding to the item branch has been received by the code repository before, and the document platform also receives history code submission information generated by the code repository for the previously submitted code source file, parses the code source file corresponding to the item branch in the code repository to obtain the interface document information, and saves the interface document information corresponding to the item branch in the database. At this time, the document platform may determine the file list to be parsed according to the change file list in the code submission information, that is, the file list to be parsed may include the at least one change code source file.

In step 304, the code source file in the file list to be parsed is parsed, and the interface document information of the project branch is updated.

In some embodiments of the present application, the parsing the code source file in the file list to be parsed may be implemented by: based on the file list to be analyzed, all code source files included in the file list to be analyzed are obtained from the code warehouse, a code analysis task corresponding to each code source file is generated, all the code analysis tasks are added into a preset execution queue, all the code analysis tasks are sequentially executed through the execution queue, an analysis result corresponding to each code source file is obtained, and interface document information corresponding to the project branch is updated according to the analysis result corresponding to each code source file.

In some embodiments of the present application, before parsing a code source file in the file list to be parsed, a filtering operation may be further performed on the file list to be parsed, where the method includes: and acquiring the project type of the project branch, acquiring the file type of each code source file in the file list to be analyzed, and filtering the corresponding code source file in the file list to be analyzed under the condition that the file type is inconsistent with the project type. And the file types of all the code source files in the file list to be analyzed after the filtering operation all accord with the item type of the item branch.

For example, java items only process files with the suffix of java, other files (such as xml files and the like) are ignored, Go items only process files with the suffix of Go, and other files are ignored.

In step 305, an interface document is generated based on the interface document information in response to an interface document view event for the project branch.

In some embodiments of the present application, the document platform may receive an interface document viewing request from any user side, and generate an interface document viewing event corresponding to the interface document viewing request. Taking the interface file viewing event for the project branch as an example, the document platform may generate the interface document information according to the interface document information of the project branch generated in step 304.

The document platform may preset a display template of the interface document, and in the process of generating the interface document, the interface document may be added to the display template according to the interface information and the parameter information included in the interface file information and according to a filling rule corresponding to the display template, so as to obtain the interface document.

As can be seen from the foregoing exemplary implementation of fig. 3 in the embodiment of the present application, by receiving the code submission information sent by the code repository in response to the code submission event, and further executing the interface document update operation of the project branch corresponding to the code submission event, the embodiment of the present application can ensure the timeliness of the interface document update. Meanwhile, whether the corresponding interface document information exists in the database or not is inquired through the code submitting event so as to determine a file list to be analyzed, wherein the file list to be analyzed needs to be analyzed, all code source files can be analyzed under the condition that the interface document information is not generated in the project branch, and only the code source files in the file list are analyzed under the condition that the interface document information is generated in the project branch.

Referring to fig. 4, fig. 4 is an optional flowchart of the interface document generation method provided in the embodiment of the present application, based on fig. 3, before step 301, the method further includes step 401 to step 402, before step 302, the method further includes step 403 to step 404, and step 302 may be updated to step 405, which will be described with reference to the steps shown in fig. 4.

In step 401, receiving a project creation request sent by a user side; the item creation request includes a code address of the item to be updated in the code repository and a branching rule for the item to be updated.

In some embodiments of the present application, in order to enable a document platform to directly receive code submission information corresponding to a code submission event while a developer submits a code source file to a code repository, before the embodiment of fig. 3, the document platform needs to initialize an item to be updated corresponding to the code submission event, and a specific initialization process may include steps 401 to 402.

The document platform needs to receive a project creation request sent by a user side, wherein the project creation request includes a code address of the project to be updated in the code repository. In this embodiment of the present application, for the item to be updated, the user may create, on the document platform, a document item corresponding to the item to be updated, where the document item is used to store all item branches corresponding to the item to be updated and the relevant information of the interface document in each item branch, where the relevant information includes interface document information forming the interface document and the interface document obtained by processing the interface document information. Accordingly, the user end can create a code item corresponding to the item to be updated in the code repository, where the code item is used to store all the item branches corresponding to the item to be updated and the code source file corresponding to each item branch. In step 401, the code address of the item to be updated in the item creation request is the code address of the code item corresponding to the item to be updated in the code repository, all code source files corresponding to the item to be updated can be obtained through the code address, and under the condition that any item branch information in the item to be updated is determined, all code source files corresponding to the item branch information in the item to be updated can be further obtained from the code repository.

In some embodiments of the present application, the branching rules are used to decide whether the current project branch requires generation of an interface document. The branch rule can be described by a regular expression, namely the interface document is generated by matching the item branch of the regular expression.

In some embodiments of the present application, the document platform may present the project creation interface to a user side; receiving project creating operation sent by a user through the project creating interface; and analyzing the project creating operation to obtain document project information corresponding to the project to be updated, wherein the document project information comprises a code address of the project to be updated in a code warehouse and a branch rule of the project to be updated.

In step 402, in response to the project creation request, generating a notification address of the project to be updated according to the code address; and after the notification address is configured to the code warehouse, the notification address is used for responding to a code submission event corresponding to the item to be updated received by the code warehouse and sending code submission information to the document platform.

In some embodiments of the present application, the document platform creates a document item corresponding to the item to be updated, and generates a notification address of the item to be updated according to the code address. The notification address may be a Webhook address, and after the Webhook address is configured to the repository address corresponding to the item to be updated in the code repository, when the code repository receives a file update event for the item to be updated, which is uploaded by the user side, code submission information corresponding to the file update event may occur to the document platform based on the Webhook address. After the document platform generates the Webhook address, the Webhook address can be sent to the user side through the address copying interface. That is, the developer may click on a copy button in the address copy interface, copy the Webhook address, and configure into the code repository.

In step 403, a branching rule for the item to be updated is obtained.

In step 404, branch information for the item branch in the code submission information is obtained.

The branch information is name information corresponding to the item branch.

In step 405, under the condition that the branch information conforms to the branch rule, inquiring the interface document information corresponding to the project branch in the database to generate an inquiry result; and the query result is used for representing whether interface document information corresponding to the item branch exists in the database.

As can be known from the foregoing exemplary implementation of fig. 4 in the embodiment of the present application, in the process of configuring the item on the document platform, the branch rule corresponding to the item is added, so that in the case of submitting the code source files of the test branch and the version branch at the same time, the branch rule is used to detect the submitted branch information, perform the subsequent query and parsing interface document generation step on the code source files of the version branch that satisfy the branch rule, and do not perform the corresponding interface document generation step on the code source files of the version branch that do not satisfy the branch rule, thereby improving the flexibility of the present application.

Referring to fig. 5, fig. 5 is an optional flowchart of the interface document generation method according to the embodiment of the present application, and based on fig. 3, step 303 may be implemented by step 501 or step 502, which will be described with reference to the steps shown in fig. 5.

In step 501, in the case that the query result is used to represent that there is no interface document information corresponding to the item branch in the database, determining a to-be-parsed file list based on a code file list corresponding to the item branch; the code file list includes all code source files corresponding to the entry branches.

In step 502, in the case that the query result is used to represent that there is interface document information corresponding to the item branch in the database, the file list to be parsed is determined based on the code submission information.

As can be seen from the foregoing exemplary implementation of fig. 5 in the embodiment of the present application, whether corresponding interface document information exists in the database by querying a code submission event to determine a file list to be parsed, all code source files may be parsed when the interface document information is not generated in the item branch, or only the code source files in the modified file list may be parsed when the interface document information is generated in the item branch, so that parsing efficiency may be improved.

Referring to fig. 6, fig. 6 is an alternative flow chart of the interface document generating method according to the embodiment of the present application, which will be described with reference to the steps shown in fig. 6.

In step 601, a current submission identifier and a first history submission identifier carried by the code submission information are obtained; the current submission identifier is the unique identifier of the code submission information, and the first history submission identifier is the unique identifier of the first history code submission information corresponding to the project branch; the first historical code submission information is adjacent submission information that the code repository sent prior to sending the code submission information.

In some embodiments of the present application, the code submission information includes two submission identifications generated by the code repository, where one submission identification is the current submission identification, and the current submission identification is the unique identification of the code submission information sent by the current code repository; another submission identifier is the first historical submission identifier, which is the adjacent submission information of the code repository before the current code submission information occurs, and the first historical submission identifier is the unique identifier of the adjacent submission message.

It should be noted that, in the process of sending each piece of code submission information to the document platform, the code repository may generate and store a unique identifier corresponding to each piece of code submission information, and in the process of sending any piece of code submission information, the code repository may carry the unique identifier corresponding to the current piece of code submission information and the unique identifier of the last piece of code submission information sent.

In step 602, the current commit identifier in the code commit information is saved.

In some embodiments of the present application, the document platform, upon receiving the code submission information, stores the current submission identification therein. Correspondingly, after receiving the historical code submission information before the current code submission information, the document platform also stores the historical code submission identifications corresponding to the historical code submission information.

In step 603, a second history submission identifier of the locally stored second history code submission information is compared with a first history submission identifier of the first history code submission information carried in the code submission information.

In some embodiments of the present application, the second historic code submission information is adjacent code submission information that the document platform received prior to receiving the current code submission information, and the second historic submission identification is a unique identification of the second historic code submission information. By comparing the second history submission identifier locally stored in the document platform with the first history submission identifier carried in the code submission information, whether the code submission information is missed or lost or the like can be determined.

In step 604, in the case that the first historical submission identifier is inconsistent with the second historical submission identifier, it is determined to be a to-be-parsed file list based on the second historical code submission information and the code submission information.

The code source file with the change between the second historical code submission information stored in the document platform and the code submission information at this time can be used as the file list to be analyzed.

In some embodiments of the present application, the determination as the to-be-parsed file list based on the second historical code submission information and the code submission information may be implemented through steps 6041 to 6044:

in step 6041, at least two change file lists between the code submission information and locally stored historical code submission information are obtained in the code repository; the at least two change file lists include at least a change file list in the code submission information and a change file list in the locally stored historical code submission information.

In step 6042, the file identification and change time of each code source file in each change file list are acquired.

In step 6043, at least one code source file corresponding to each file identifier is filtered according to the change time, and the latest code source file corresponding to each file identifier is reserved

In step 6044, a list of files to parse is determined based on each file identification corresponding to the latest code source file.

For example, if there is a discrepancy between the first historical commit identifier and the second historical commit identifier, at least two change file lists may be determined based on the second historical commit information and the current code commit information. At least one missing submission identifier between the second historical submission identifier and the current submission identifier may be obtained first, at least two change file lists corresponding to the historical submission information and the current code submission information in the history submission information corresponding to each missing submission identifier are obtained, and the file list to be analyzed is determined based on the at least two change file lists.

As can be seen from the above exemplary implementation of fig. 6, in the embodiment of the present application, by recording the submission identifier of each submission, when a submission event is received next time, the submission identifier of the last submission is obtained from the submission information, and by comparing whether the obtained submission identifier of the last submission is inconsistent with the submission identifier of the last submission recorded on the document platform, it is determined whether the code submission information is lost. Meanwhile, the code source file which is changed between the second historical code submission information stored in the document platform and the code submission information at this time is used as the file list to be analyzed, so that the code source file corresponding to the lost code submission information can be added into the file list to be analyzed at this time, and the accuracy of the interface document information of the project to be updated in the document platform can be ensured; in addition, in the process of performing complementary analysis on the missing code source files, the code source files with earlier time are ignored according to the change time of each code source file, so that unnecessary code analysis processes can be reduced, and the analysis efficiency is improved.

Referring to fig. 7, fig. 7 is an optional flowchart of an interface document generation method provided in the embodiment of the present application, and based on the foregoing embodiment and taking fig. 3 as an example, step 304 in fig. 3 may be implemented by steps 701 to 703, which will be described with reference to the steps shown in fig. 7.

In step 701, at least one code source file corresponding to a file list to be parsed is obtained from a code repository.

In step 702, the parsing result is saved to the database to update the interface document information of the item to be updated.

In some embodiments of the present application, the saving the parsing result to the database to update the interface document information of the project to be updated may be implemented through steps 7021 to 7023:

in step 7021, according to the submission time of the code submission information, a current version number related to the submission time is added to the parsing result.

In step 7022, the analysis result with the version number is saved to a database.

In step 7023, the parsing result in the database with the version number smaller than the current version number is deleted to obtain the interface document information of the item to be updated.

In step 703, analyzing at least one code source file to obtain an analysis result of a code to be analyzed in each code source file; the analysis result comprises field identification and field definition information of the definition field; the definition field includes an interface field and/or a parameter field.

In some embodiments of the present application, the parsing at least one code source file to obtain a parsing result of a code to be parsed in each code source file may be implemented through steps 7031 to 7032:

in step 7041, each code source file is converted into a corresponding abstract code tree, resulting in at least one abstract code tree.

In step 7042, each abstract code tree is parsed to obtain identification information and definition information of each code source file; the identification information is used for positioning a code source file in a database to obtain definition information; the definition information comprises field identification and field definition information of definition fields contained in the code source file; the definition field includes an interface field and/or a parameter field.

The parsing result may include field identification and field definition information of an interface field, that is, the interface identification and the interface definition information of the interface; the parsing interface may further comprise field identification and field definition information of the parameter fields, i.e. parameter identification and parameter definition information of the parameters.

In some embodiments of the present application, in a process of parsing an abstract code tree corresponding to each code source file, if the definition field is a parameter field, the parameter definition information includes a built-in type and a composite type. The parameter definition information corresponding to the built-in memory includes specific parameter descriptions of the parameter field, such as parameter type, parameter range, etc.; the parameter definition information corresponding to the composite type does not include the specific description of the parameter field, includes the identification information of other code source files referenced by the parameter field, and can be positioned to the parent code source file referenced by the parameter definition information through the identification information of the other code source files and the parameter identification of the parameter field, so that the specific parameter description of the parent code source file to the parameter field can be obtained.

As can be seen from the foregoing exemplary implementation of fig. 7 in the embodiment of the present application, a code source file is analyzed through an abstract code tree, so that description information and access parameter information of an interface in a source code can be accurately obtained, an attribute inheritance relationship in a source code compiling process can be maintained through the abstract code tree, and specific definition data of a parameter can be obtained in a parameter attribute obtaining process.

Referring to fig. 8, fig. 8 is an alternative flowchart of an interface document generating method provided in an embodiment of the present application, and based on fig. 3, step 305 may be implemented by steps 801 to 804, which will be described with reference to the steps shown in fig. 8.

In step 801, a target item identifier and a target interface identifier carried by an interface document viewing request are obtained.

In step 802, the database is queried for target interface document information corresponding to the target item identifier.

In step 803, target interface information and target parameter information corresponding to the target interface are obtained from the target interface document information based on the target interface identifier.

In some embodiments of the present application, the obtaining of the target interface information and the target parameter information corresponding to the target interface in the target interface document information based on the target interface identifier may be implemented by the following steps 8031 to 8033:

in step 8031, target interface information corresponding to the target interface is obtained from the target interface document information according to the target interface identifier; the target interface information comprises interface identification information corresponding to the interface;

in step 8032, based on the interface identification information, determining an interface parsing result corresponding to the interface source file;

in step 8033, definition information in the interface parsing result is obtained; target parameter information of the interface is generated based on the definition information.

The definition information in the interface analysis result can be acquired in the following manner; generating target parameter information of the interface based on the definition information: acquiring parameter identification and parameter definition information of at least one interface parameter definition field in the definition information; under the condition that the parameter definition information of the interface parameter definition field is of a built-in type, taking the field identification and the field definition information of the interface parameter definition field as target parameter information; determining reference identification information based on field identification of the interface parameter definition field under the condition that the parameter definition information of the interface parameter definition field is of a composite type; and acquiring a field analysis result corresponding to the reference identification information, and generating target parameter information of the interface based on the definition information in the field analysis result.

In step 804, an interface document is generated based on the target interface information and the target parameter information.

In some embodiments of the present application, the method further comprises: receiving a generation request of virtual data aiming at a target interface; sending the target parameter information to a virtual data generator so that the virtual data generator generates virtual parameters corresponding to the target parameter information; and sending the virtual data containing the virtual parameters to the user side.

As can be seen from the above exemplary implementation of fig. 8, in the embodiment of the present application, in response to a viewing request of an interface document, the target interface information and the target parameter information obtained through analysis may be rendered to obtain an intuitive interface document, and meanwhile, in response to a mock request, virtual data matched with the interface document may be generated to provide technical support for project development.

Next, an exemplary application of the embodiment of the present application in a practical application scenario will be described.

For the management problem of the interface document, the following solutions exist in the related art:

(1) an interface document management scheme based on word files, markdown files and the like. According to the scheme, interface document contents are manually recorded into word files, markdown files and the like according to a self-organized format, a viewer asks for the files to view the files, and a writer needs to modify the interface documents in time along with the change of a system and inform the viewer; the scheme tool is simple to obtain and does not need to depend on other systems.

(2) An interface document management platform, such as a RAP interface management platform. The input personnel can input the interface information into the interface document management platform one by one according to the project management interface, or import a file with a fixed format into the interface document management platform, and the viewing personnel can view the interface information through the interface document management platform. The platform can also store detailed interface field information for interfacing with other systems.

(3) Annotation or java doc based document parsing scheme. According to the scheme, the code is annotated according to a certain format by an entry person, the annotation is read by the analyzer, the annotated content is converted into a formatted file for subsequent display, the formatted file can be updated along with the change of the code, and the file can be ensured to be updated along with the code.

(4) And (4) a swagger java project document parsing scheme. According to the scheme, the swagger package is introduced into the java project, the structure information of the interface is acquired when the java project runs, and the interface document is displayed.

The applicant has found through research that the above solution has the following technical problems: (1) the document is written by manually writing one word and one sentence, the early-stage work investment is large, the real-time property of interface change needs to be guaranteed in the later stage, the maintenance cost is high, meanwhile, the interface file cannot be butted with other systems, and the interface file placement management is difficult. (2) The writing cost in the early stage is high, and the updating and maintenance success in the later stage is also high. (3) The interface document information needs to be recorded in the code by the developer, namely, the positions of writing the interface document one by one are only changed, and the comment information in the code still needs to be updated when the interface field is changed. (4) The interface document is displayed by starting the project, the project needs to be restarted when the interface is updated every time, the interface document cannot be managed according to the version, and meanwhile, a centralized platform is not provided, so that the interface document can be conveniently circulated and checked.

In view of the above technical problem, the present application provides an interface document generating method, please refer to fig. 9A, and fig. 9A shows an alternative flowchart. The description will be made in conjunction with the following steps.

In step A01, the code repository receives code submitted by a developer through a user terminal.

Wherein, before step a01, the developer has created the project corresponding to the code on the document platform.

In step A02, the code repository requests a document platform via Webhook.

And B, the code warehouse sends the submitted information carried in the step A01 to the document platform through Webhook corresponding to the project in the document platform. The submission information may include at least one of: submitter, submission time, submitted code (Git) branch, code repository information to which the project belongs, file list of changes, and project identification in the document platform.

In step A03, the document platform receives a Webhook notification and queries for project information.

After receiving the Webhook notification, the document platform acquires submission information carried by the Webhook notification, and verifies the item identifier in the submission information. And the correctness of the signature in the item identifier is mainly verified to ensure that the Webhook notification source is legal, then whether the item identifier exists is inquired, and if the verification fails, error information is returned.

After verification is successful, the document platform queries for project information. The method comprises the steps that a document platform can generate a regular expression according to a branch rule configured during creation, in the process of inquiring project information, whether Git branch information in a Webhook notification is matched with the configured regular expression is checked, if not, it is indicated that the Git branches submitted at this time do not need to generate interface documents (such as some hotsfix and test branches), and then the interface documents are directly returned without processing; if there is a match, indicating that the Git branch requires generation of an interface document, step A04 is performed.

In step a04, whether or not to initialize.

After determining a Git branch needing to generate an interface document, the document platform determines whether the Git branch has completed initialization, and indicates that the initialization has been completed under the condition that document information exists in the Git branch; in the case where the Git branch has no document information, it indicates that the initialization is not completed.

In step A05, Git clone (copy) specifies the item of the branch.

In step A06, the copied item is traversed to obtain all the file contents.

If the branch does not exist, the branch indicates that the branch does not generate an interface document and cannot only analyze the code which is submitted to change at this time, and in this case, all the codes clone of the whole branch needs to be downloaded, and all the code source files are traversed to obtain the content for analysis.

In step A07, the source code file of the change is obtained from the Webhook notification.

In step A08, the request-by-request code repository interface retrieves file content.

If the branch exists, the submission before the project is analyzed and a document is generated, in this case, only the code of the change submitted this time needs to be analyzed, the file path request Git interface is used to obtain the detailed content of the file, and then the file content is analyzed.

In step a09, a code parser is called to obtain interface information and field information.

After the path and the content of the source code file are obtained, the format of the file needs to be judged, the java item is only processed with the java as the suffix file, other files (such as xml files and the like) are ignored, the Go item is only processed with the Go as the suffix file, and other files are also ignored. File contents meeting the file format requirement are submitted to a code resolver to be resolved, the code resolver converts a source code into an AST, tree traversal is carried out on the AST, interfaces (including an interface name, an interface request path, an Http method of an interface request, an entry definition of the interface, an exit definition of the interface and the like) defined in the codes and protocol information (including a field name, a field type, a field description, whether filling is necessary and the like) defined in the codes are obtained according to the grammar and annotation comments of the codes, and the obtained information is recorded into a database.

In step a10, the interface information and field information are recorded to a database.

When the interface information is analyzed and updated from the source code, due to the disorder of arrival of the Webhook notification and the fact that certain time is consumed when the source code is analyzed, a newer change may be processed first, and an old change is processed later due to the reason that the notification and the processing are time-consuming, so that the newer information of the interface is covered by the old information. For the above problems, the document platform records the submission time of each file in Git, when the document information of the analyzed file is updated, the document platform first judges whether the update time of the file to be processed is later than the update time of the file recorded by the document platform, if the update time of the file is earlier, the interface information is already updated by the same newer source code file, and the analysis is not needed to directly ignore; the parsing process is performed only when the update time of the file to be processed is later than the update time recorded by the document platform. Because the update time of the file is the file submission time taken from the Git warehouse record, the time is derived from the Git submission record, and the morning and evening of the time can correctly reflect the file change sequence.

In some embodiments, the change of the interface information of the document platform is to acquire the interface information and the field information by analyzing the source code file and record the interface information and the field information into the database, which can well handle the situations of addition and change, but the deletion of the interface and the field cannot be sensed. The deletion of fields and interfaces is common in actual use, so this situation needs to be handled. The scheme adopted by the document platform is that when the definition of the interface and the definition of the field are recorded, the file information to which the interface and the field belong is recorded at the same time; when the source file updating information is analyzed each time, the file platform uses the submission time of the file as a version number, and updates the version numbers of the interface and the field records with each file change. In this case, for the interfaces and fields deleted from the file, the version numbers of the interfaces and the fields are not updated any more, after the file is analyzed and the information is recorded in the database, the interface definitions and the field definitions with the version numbers smaller than the version number updated this time are deleted, so that the interfaces and the field definitions which do not exist in the file any more are deleted, and the interfaces which do not exist in the codes are deleted.

In step A11, the document renderer associates the interfaces and fields of different files and the processing of the generic etc.

When a user views the interface information, the stored interface information and field information are read from the database, and because the interface definition and the interface in-out reference field type definition may be distributed in different files, and meanwhile, java source codes also have situations of generalization, class inheritance and the like which need special processing, and Go languages also have situations of pointer type, structure multiplexing, composite type and the like. The document renderer needs to associate a limited class name (namely, a full name of a package containing a class and a class name) of a file where each interface and field type definition are located, perform real type replacement on a generic type, merge and cover fields inherited by the class, perform pointer removal on a pointer type of Go, perform field replication on structural body multiplexing of the Go and the like, and finally splice the generic type and the fields into a complete interface name, a request address, an Http method, entry-participation detailed information and exit-participation detailed information.

In step A12, the interface document is exposed.

The interface platform can display the interface document corresponding to the project through the interface.

Turning to FIG. 9B, a flow diagram of a project creation process is shown and will be described in conjunction with the following steps.

In step B01, the user side sends a request for the creation of a code item to the code repository.

The document platform is generated by parsing based on the code source file, and therefore, a code item needs to be created in the code repository, where the code item is used for managing the corresponding code source file. After the code warehouse has completed the creation of the code item, step B02 is performed.

In step B02, the code repository sends the entry path corresponding to the code entry to the user end.

And the code warehouse responds to the creation request, creates the code item and generates a item path corresponding to the code item. The project path is used for obtaining a code source file corresponding to the code project in the code warehouse.

In step B03, the user sends a new request for the document project to the document platform.

Wherein the new request includes a project path. In some embodiments, the new request also includes project information for the document project.

In step B04, the document platform queries the code item for item information through an interface provided by the code repository.

The document platform needs to access the code repository through a login account corresponding to the document platform in the process of accessing the code repository, and the code item can be inquired from the interface under the condition that the login account has the access right of the code item; and if the login account does not have the access authority of the code item, ending the process and reporting an error.

In step B05, the code repository sends project information for the code project to the document platform.

In step B06, the document platform sends the creation success information and the Webhook address of the project information to the user side.

And the document platform generates Webhook addresses corresponding to the document items one by one according to the item information of the code items and displays the Webhook addresses at the front end.

In step B07, the user side sends the configuration information carrying the Webhook address to the code repository.

After the code warehouse receives the Webhook address, a Webhook notification can be generated after the code project receives a user-side submitted code, and the Webhook notification is sent to a document project corresponding to the code project on a document platform.

In step B08, the code repository returns a configuration success message to the user end.

It should be noted that the code repository also provides an interface so that the document platform can directly configure the Webhook address, but the operation of the interface requires that higher authority of the code repository be granted to the common account of the document platform, which increases the risk of the code item.

Referring to FIG. 9C, a flowchart of a project initialization process is shown and will be described in conjunction with the following steps.

In step C01, the user end submits the code source file to the code repository.

The client side corresponding to the code warehouse is arranged in the client side, and the client side can access the code warehouse through the client side.

In step C02, the code repository sends the change file information to the document platform via Webhook.

After receiving the code source file, the code repository may obtain a modified code file list from the code source file, and generate corresponding modified file information.

In step C03, the document platform sends a project information query request (and rules) to the database;

in step C04, the database sends a project information query response to the document platform.

In step C05, the document platform generates an initialization task based on the project query response.

The initialization tasks include a project initialization task and a branch initialization task. If the item branch is inquired that no interface is generated, it indicates that only the changed file cannot be analyzed, and all code files of the whole item need to be acquired for analysis processing. In the case of pulling all source codes of the whole project, the time consumption is long, and the return in a synchronous state cannot be guaranteed.

In step C06, the document platform writes the initialization task into the message queue.

In step C07, the message queue sends the write result to the document platform.

In step C08, the document platform sends a Webhook response to the code repository. .

In step C09, the code repository sends a code submission response to the user end.

Wherein, the information in the message queue is consumed by asynchronous task, then the amplitude (clone) code warehouse appoints the source code file of the branch to the local; traversing all source code files, requesting a code parser one by one, acquiring interface definitions and field definitions in the source code files, recording the interface definitions and the field definitions in a database, and finally completing the whole task; thus, the interface information and field information defined in all source codes of the current branch are recorded in the database.

In step C10, the asynchronous task processing module sends a task get request to the message queue.

In step C11, the message queue sends an initialization task to the asynchronous task processing module.

In step C12, the asynchronous task processing module sends a code fetch request to the code repository.

The code obtaining request is used for pulling a source code file corresponding to the initialization task.

In step C13, the code repository sends a code fetch response to the asynchronous task processing module.

In step C14, the asynchronous task processing module traverses all code source files and sends the code source files to the code parser.

In step C15, the code parser parses the code source file to obtain the interface definition and the field definition corresponding to the code source file.

In step C16, the code parser returns the interface definition and field definition to the asynchronous task processing module.

In step C17, the asynchronous task processing module stores the interface definition and the field definition in a database.

In step C18, the database returns the store results to the asynchronous task processing module.

By the method, the interface definition and the field definition corresponding to the code source file in the change file can be obtained and stored in the database.

Referring to FIG. 9D, a flowchart of an item update process is shown and will be described in conjunction with the following steps.

In step D01, the user side submits the code source file to the code repository.

In step D02, the code repository sends the change file information to the document platform via Webhook.

In step D03, the document platform sends a project information query request to the database;

in step D04, the database sends a project information query response to the document platform.

Wherein, the steps D01 to D04 correspond to C01 to C04 in the above embodiments.

In step D05, in the case where it is judged that the item branch has completed initialization, the code path of the changed code source file is sent to the code parser.

In step D06, the code parser sends a code acquisition request to the code repository.

In step D07, the code repository sends a code acquisition response to the code parser.

In step D08, the code parser parses the code source file to obtain the interface definition and the field definition corresponding to the code source file.

In step D09, the code parser returns the interface definition and field definition to the document platform.

In step D10, the document platform stores the interface definitions and field definitions in a database.

In step D11, the database returns the stored result to the document platform.

In step D12, the document platform sends a Webhook response to the code repository.

In step D13, the code repository sends a code submission response to the user terminal.

In some embodiments of the present application, since Webhook notification does not have a retry mechanism, a situation is also encountered in which the code repository does not trigger Webhook for submission of code; once the above problem occurs, the interface document cannot be updated due to the lack of the change information of the source code file for the document platform. In the face of this situation, the document platform records the commit Id (commit identifier) of each commit, when a commit event is received next time, the commit Id of the last commit is acquired from the information notified by Webhook, if the acquired commit Id of the last commit is not consistent with the commit Id of the last commit recorded by the document platform, it indicates that there is a commit loss between the two commits, at this time, a file changed between the commit ids of the two commits is acquired through an interface of the code repository, and then the missing files are parsed according to the above-described flow (if the missing file commit time is older than that recorded by the document platform, the missing files are directly ignored). This solves the problem that interface information may be lost due to Webhook notification quality.

Referring to FIG. 9E, a flowchart of an interface document viewing process is shown and will be described in conjunction with the following steps.

In step E01, the user side sends an interface information viewing request to the document platform.

In step E02, the document platform sends a parameter query request to the database.

In step E03, the database returns the query result carrying the interface information to the document platform.

In step E04, the document platform sends the interface information to the document renderer.

The interface information queried in the query result is fragmented, for example, the interface definition and the field definition are distributed in different code source files, the type of the field itself refers to the field definition in another file, the generic type is to be specified, and the inheritance of the class of the field definition is required to be handled and integrated, so that the document renderer is required to handle the interface information.

In step E05, the document renderer processes the interface information to obtain an interface document.

In step E06, the document renderer sends the interface document to the document platform.

In step E07, the document platform presents the interface document through the interface.

Referring to fig. 9F, a flowchart of a virtual data generation process is shown, which will be described in conjunction with the following steps.

In step F01, the user side sends an interface information viewing request to the document platform.

In step F02, the document platform sends a parameter query request to the database.

In step F03, the database returns the query result to the document platform.

In step F04, the document platform sends the interface information to the document renderer.

In step F05, the document renderer will process the interface information to obtain an interface document.

In step F06, the document renderer sends the interface document to the document platform.

In step F07, the document platform sends the interface document to the virtual data generation module.

In step F08, the virtual data generation module sends the generated virtual data to the document platform.

In step F09, the document platform sends the virtual data to the user side.

In some embodiments of the present application, there is also provided an implementation method of a code parser, where a core basis of a code, i.e., a document scheme, for obtaining interface information from a source code is AST, i.e., an abstract syntax tree. The abstract syntax tree represents all syntactical definitions in the code (including but not limited to class definitions, method parameters, structure and field definitions, comments, notes, etc.) as a series of nodes on the tree, and the relationships between the various definitions in the source code are also represented in the parent and child sibling relationships of the tree. For ease of understanding, the description will be made by taking an actual code as an example.

Turning to FIG. 10A, a code diagram of java source code is shown in which interface names and interface routes are provided via annotations, with ingress and egress references (i.e., method arguments and returns) being specified on the interface method definitions.

The Java source code provided in fig. 10A is converted into the corresponding abstract syntax tree, so as to obtain the abstract syntax tree diagrams shown in fig. 10B to fig. 10D. Fig. 10B is a part of an abstract syntax tree of Package information in the source code, and fig. 10C is a part of an abstract syntax tree of image information (one of the image information is exemplarily shown) in the source code; FIG. 10D is a partial abstract syntax tree for interface definitions in source code.

Fig. 10B shows AST defined by the Package, from which the Package in which the class is located can be obtained, and in combination with the name of the class, the definition name of the class can be obtained, and this definition name is unique throughout the project. Fig. 10C shows information of the source code inport, and the limited names of other class definitions referred to in the source code can be obtained through the inport information, so that the file where the field definition is located can be uniquely located through the obtained limited names. Fig. 10D shows a definition of an interface, where line 110 may read a name of the interface from the annotation, line 117 may read a request path to the interface from the annotation, line 121 may obtain a return type Response of the interface, and a limited name of a parameter may be obtained by combining with the input, com. Response defines the generic type, and row 125 can obtain the name representation of the Response generic type, so that the complete exit definition of the interface is obtained. Line 136 may obtain the entry parameter of the interface as Protocol, and obtain its qualified name com. Meanwhile, the limited name of the class where the interface is located can be known by combining the Package information, namely com.

Accordingly, based on the interface definition code in fig. 10A, the parameter definition source code corresponding to the interface may refer to the entry definition source code shown in fig. 11A. The abstract syntax tree diagram of fig. 11B can be obtained by converting the source code of the entry definition provided in fig. 11A into the corresponding abstract syntax tree.

As shown in fig. 11B, line 223 obtains the class name of the field definition, and combines the definition of Package to obtain its qualified name com.tent.sr.mktbackend.protocol.demo.protocol; 225 rows can acquire that the field definition class inherits the class name Parent; line 235 may obtain the description of the first field, line 239 may obtain the type of the first field, and line 240 may obtain the name of the first field, thus obtaining the full information of the first field. Line 249 may obtain a description of the second field, line 253 may obtain the type of the second field, and at the same time, may know that it is a composite type, and may obtain the name of the restriction of this type in conjunction with the Import, which is referred to as com.

Accordingly, based on the interface definition code in fig. 10A, the out-reference parameter definition source code corresponding to the interface may refer to the out-reference definition source code shown in fig. 12A. The abstract syntax tree diagram of fig. 12B can be obtained by converting the source code of the argument definition provided in fig. 12A into the corresponding abstract syntax tree.

As shown in fig. 12B, the qualified name com. tent.sr. mktbackend. protocol.demo. response can be obtained also from the class name and Package. Line 311 in combination with line 354 may obtain that the current class is a generic class, which is named T, and needs to be replaced with the true class when used specifically. The other types of definition acquisition modes are the same as the type acquisition information of the parameter.

In some embodiments of the present application, the definition of the interface is obtained through the above-mentioned manner and recorded in the database, the request path and the description information of the interface already have, the limited name of the entry parameter is com.tent.sr.mktbackend.protocol.demo.protocol, that is, the limited name of the field definition class analyzed in the embodiment corresponding to fig. 11B, and the association of the interface entry parameter to the entry parameter specific definition can be completed by combining the two; the qualified name of the out-parameter is com.tent.sr.mktbackend.protocol.demo.response, which is the qualified name of the field definition class analyzed by the embodiment corresponding to fig. 12B, and the association of the interface out-parameter to the out-parameter specific definition is completed by combining the com.tent.sr.mktbackend.protocol.demo. The specific field type in the following field definition may also be other types, and the parsing method is also to search the specific definition according to the above procedure until all field types are built-in types.

Referring to fig. 13A, a schematic diagram of interface definition source code of Go source code is shown, and correspondingly, fig. 13B shows a schematic diagram of abstract syntax tree of Go source code. The AST style of Go language and the java language are different in analysis and structure, but basic ideas of basic analysis are consistent. In fig. 13B, the name of the first field can be obtained in line 65, the type of the first field can be obtained in line 75, the remark information of the first field can be obtained in line 81, so far, the information of the first field is obtained, and the information of the other fields is obtained in sequence.

In some embodiments of the present application, the above-described document renderer may be implemented by: the interface information and the access information acquired by combining the above embodiments are recorded in the database. The method comprises the steps of inquiring an interface name apinamine, a request path route of the interface, an Http request method of the interface, an interface access limited name com.tencent.moonzhi.apijava.protocol.rest.fileprocessrequest and an interface access limited name com.tencent.moonzhi.apijava.protocol.rest.fileprocess Response through the id of the interface, and then inquiring field definition of access according to the access reference limited name in a field definition table. The parameter-in field path and the parameter-out three fields code, data and message can be queried, wherein the field data is a composite type. The interface information and field information display diagram shown in fig. 14 can be obtained. The lookup continues through the qualified name in the field _ type of this record to obtain the detailed field definition for the compound type, and so on. And finally, combining the interface information, the parameter entering detailed field information and the parameter exiting detailed field information to display the complete interface information.

In some embodiments of the present application, it is known whether a field is generic when performing field parsing, and during document rendering, the generic is replaced by a type that is introduced when the generic is actually used, and the following processing is performed as described above. For the inherited class, the document renderer lists fields of the inherited class and fields of the inherited class, and combines the fields of the inherited class and the fields of the inherited class, wherein if the fields exist in the inherited class and the fields of the inherited class at the same time, the definition of the fields of the inherited class is controlled; the following parsing flow for each field is also the same as described above. In addition, the document renderer will also handle type conversion and normalization, such as converting java's BigDecimal to digital type for interface presentation. In conclusion, the document renderer associates the dispersed interface information with the field information, and renders the interface information into complete and readable interface information for front-end display and output to platforms such as quality testing platforms and mock platforms.

In some embodiments of the present application, the Git-based Webhook notification is used to obtain the code change, and other platforms that can support Webhook notification, such as code hosted in svn, can also be implemented using the present solution. It should be noted that, in the above embodiments, the present application uses java and Go languages for verification, and other languages supporting AST parsing, including but not limited to development languages such as c + +, js, and the like, may also be implemented by using the present application.

By the interface document generation method provided by the embodiment, the following technical effects can be realized: (1) and the code, namely the implementation mode of the document scheme, uses the code hosted by the Git warehouse and the version of the document platform corresponding to the branch of Git, namely the code in the Git warehouse exists, the document can be rendered and generated at any time, and the document information can be well preserved by preserving the code. (2) The document is generated by analyzing the codes, so that the time for manually and independently writing the document is saved. (3) After the code change is submitted to the Git warehouse, the change is notified to the document platform through the Webhook, and then the interface document information can be updated, so that the timeliness of the interface document updating is ensured, and the time and energy cost for manually and independently updating the interface document is reduced. (4) The fields, method names and the like in the codes can be directly used as the field information of the document, the association relationship (such as parent-child type and the like) in the codes can also be directly used as the association relationship of the interface document, and developers can complete the setting of the relationship in the interface document after completing the writing of the codes and uploading the codes to generate the accurate interface document. And (5) annotation comments of the interface additional description information are defined next to the code fields, and can be synchronously updated at the cost of minimum movement of a cursor when the fields are modified by developers. (6) Through a unified centralized interface management platform, the system is convenient to provide for all demand parties to check, does not need to rely on the operation of projects, and can provide more management functions such as authority management and module division. (7) The detailed interface information recorded based on the document platform can be used for mock service, interface protocol information is provided for a quality testing team to generate a test case, the interface protocol information is provided for a safety scanning platform to construct a scanning case, sdk and the like are generated based on the detailed interface protocol, and the labor input cost of the corresponding platform is reduced. (8) The invention verifies that in use, all access projects have complete, accurate and timely updated interface documents, solves the problem of interface document missing delay caused by higher document creating and maintaining cost, and saves more than one third of workload by returning to a document platform according to a quality team.

Continuing with the exemplary structure of the interface document generation apparatus 555 provided by the embodiments of the present application implemented as software modules, in some embodiments of the present application, as shown in fig. 2, the software modules stored in the interface document generation apparatus 555 of the memory 550 may include:

a first obtaining module 5551, configured to obtain code submission information sent by the code repository in response to a code submission event; the code submission information comprises a change file list and item branches corresponding to the code submission event; the code submission event representation client submits at least one change code source file corresponding to the change file list to the code warehouse;

the query module 5552 is configured to query the interface document information corresponding to the item branch in the database, and generate a query result; the query result is used for representing whether interface document information corresponding to the project branch exists in the database or not;

the first generating module 5553 is configured to generate a to-be-analyzed file list based on the query result; the file list to be analyzed comprises at least one change code source file;

the parsing module 5554 is configured to parse the code source file in the file list to be parsed, and update the interface document information of the project branch;

a second generating module 5555 is configured to generate an interface document based on the interface document information in response to an interface document viewing event for a project branch.

In some embodiments of the present application, the interface document generation apparatus 555 further includes a creation module and a virtual data generation module.

In some embodiments of the present application, the creating module is configured to receive a project creating request sent by a user side; the project creating request comprises a code address of the project to be updated in the code warehouse and a branch rule of the project to be updated; responding to the project creating request, and generating a notification address of the project to be updated according to the code address; and after the notification address is configured to the code warehouse, the notification address is used for responding to a code submission event corresponding to the item to be updated received by the code warehouse and sending code submission information to the document platform.

In some embodiments of the present application, the query module 5552 is further configured to obtain a branch rule of the item to be updated; acquiring branch information of item branches in the code submission information; and under the condition that the branch information accords with the branch rule, inquiring the interface document information corresponding to the project branch in the database to generate an inquiry result.

In some embodiments of the present application, the first generating module 5553 is further configured to, in a case that the query result is used to characterize that there is no interface document information corresponding to the item branch in the database, determine a file list to be parsed based on the code file list corresponding to the item branch; the code file list comprises all code source files corresponding to the item branches; and determining a file list to be analyzed based on the code submission information under the condition that the query result is used for representing that interface document information corresponding to the item branch exists in the database.

In some embodiments of the present application, the first generating module 5553 is further configured to determine the changed file list as a file list to be parsed.

In some embodiments of the present application, the first generating module 5553 is further configured to obtain a current submission identifier and a first historical submission identifier carried in the code submission information; the current submission identifier is the unique identifier of the code submission information, and the first history submission identifier is the unique identifier of the first history code submission information corresponding to the project branch; the first historical code submission information is adjacent submission information sent by the code warehouse before the code submission information is sent; saving the current submission identifier in the code submission information; comparing a second history submission identifier of the locally stored second history code submission information with a first history submission identifier of the first history code submission information carried in the code submission information; and determining the file list to be analyzed based on the second historical code submission information and the code submission information under the condition that the first historical submission identifier is inconsistent with the second historical submission identifier.

In some embodiments of the present application, the first generating module 5553 is further configured to obtain at least two change file lists between the code submission information and the locally stored historical code submission information in the code repository; the at least two change file lists at least comprise a change file list in the code submission information and a change file list in the locally stored historical code submission information; acquiring file identification and change time of each code source file in each change file list; filtering at least one code source file corresponding to each file identifier according to the change time, and reserving the latest code source file corresponding to each file identifier; and determining a file list to be analyzed based on the latest code source file corresponding to each file identifier.

In some embodiments of the present application, the parsing module 5554 is further configured to obtain at least one code source file corresponding to a file list to be parsed from a code repository; analyzing at least one code source file to obtain an analysis result of a code to be analyzed in each code source file; the analysis result comprises field identification and field definition information of the definition field; the definition field comprises an interface field and/or a parameter field; and storing the analysis result to a database so as to update the interface document information of the project to be updated.

In some embodiments of the present application, the parsing module 5554 is further configured to add, to the parsing result, a current version number related to a submission time according to the submission time of the code submission information; storing the analysis result with the version number to a database; and deleting the analysis result of which the version number is smaller than the current version number in the database to obtain the interface document information of the item to be updated.

In some embodiments of the present application, the parsing module 5554 is further configured to convert each code source file into a corresponding abstract code tree, so as to obtain at least one abstract code tree; analyzing each abstract code tree to obtain identification information and definition information of each code source file; the identification information is used for positioning the code source file in the database to obtain the definition information; the definition information comprises field identification and field definition information of definition fields contained in the code source file; the definition field includes an interface field and/or a parameter field.

In some embodiments of the present application, the second generating module 5555 is further configured to obtain a target item identifier and a target interface identifier carried in the interface document viewing request; inquiring target interface document information corresponding to the target item identification in a database; acquiring target interface information and target parameter information corresponding to a target interface from the target interface document information based on the target interface identifier; an interface document is generated based on the target interface information and the target parameter information.

In some embodiments of the present application, the second generating module 5555 is further configured to obtain, according to the target interface identifier, target interface information corresponding to the target interface from the target interface document information; the target interface information comprises interface identification information corresponding to the interface; determining an interface analysis result corresponding to the interface source file based on the interface identification information; acquiring definition information in an interface analysis result; target parameter information of the interface is generated based on the definition information.

In some embodiments of the present application, the second generating module 5555 is further configured to obtain parameter identification and parameter definition information of at least one interface parameter definition field in the definition information; under the condition that the parameter definition information of the interface parameter definition field is of a built-in type, taking the field identification and the field definition information of the interface parameter definition field as target parameter information; determining reference identification information based on field identification of the interface parameter definition field under the condition that the parameter definition information of the interface parameter definition field is of a composite type; and acquiring a field analysis result corresponding to the reference identification information, and generating target parameter information of the interface based on the definition information in the field analysis result.

In some embodiments of the present application, the virtual data generation module is configured to receive a generation request of virtual data for a target interface; sending the target parameter information to a virtual data generator so that the virtual data generator generates virtual parameters corresponding to the target parameter information; and sending the virtual data containing the virtual parameters to the user side. Code submitting information sent by the code warehouse in response to the code submitting event is acquired; the code submission information comprises a change file list and item branches corresponding to the code submission event; the code submitting event representation user side submits at least one change code source file corresponding to the change file list to the code warehouse; inquiring interface document information corresponding to the project branches in a database to generate an inquiry result; the query result is used for representing whether interface document information corresponding to the project branch exists in the database or not; generating a file list to be analyzed based on the query result; the file list to be analyzed comprises at least one change code source file; analyzing the code source file in the file list to be analyzed, and updating the interface document information of the project branch; in response to an interface document viewing event for a project branch, an interface document is generated based on the interface document information.

Embodiments of the present disclosure provide a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the interface document generation method described above in the embodiment of the present application.

The disclosed embodiments provide a computer-readable storage medium storing executable instructions, which when executed by a processor, will cause the processor to perform the interface document generation method provided by the embodiments of the present application, for example, the method as shown in fig. 3 to 8.

In some embodiments of the present application, the computer readable storage medium may be memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or may be various devices including one or any combination of the above memories.

In some embodiments of the application, the executable instructions may be in the form of a program, software module, script, or code, written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

By way of example, executable instructions may, but need not, correspond to files in a file system, and may be stored in a portion of a file that holds other programs or data, such as in one or more scripts in a hypertext Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code).

By way of example, executable instructions may be deployed to be executed on one computing device or on multiple computing devices at one site or distributed across multiple sites and interconnected by a communication network.

The above description is only an example of the present application, and is not intended to limit the scope of the present application. Any modification, equivalent replacement, and improvement made within the spirit and scope of the present application are included in the protection scope of the present application.

Claims

1. An interface document generation method, characterized in that the method comprises:

code submitting information sent by the code warehouse in response to the code submitting event is acquired; the code submission information comprises a change file list and item branches corresponding to the code submission event; the code submitting event representation client submits at least one change code source file corresponding to the change file list to the code warehouse;

inquiring interface document information corresponding to the project branch in a database to generate an inquiry result; the query result is used for representing whether interface document information corresponding to the item branch exists in the database or not;

generating a file list to be analyzed based on the query result; the file list to be analyzed comprises the at least one change code source file;

analyzing the code source file in the file list to be analyzed, and updating the interface document information of the project branch;

generating an interface document based on the interface document information in response to an interface document viewing event for the project branch.

2. The method of claim 1, further comprising:

receiving a project creation request sent by the user side; the project creation request comprises a code address of a project to be updated in the code warehouse and a branch rule of the project to be updated;

responding to the project creating request, and generating a notification address of the project to be updated according to the code address; and after the notification address is configured to the code repository, the notification address is used for responding to a code submission event corresponding to the item to be updated received by the code repository, and sending the code submission information to the document platform.

3. The method of claim 2, wherein before querying the database for interface document information corresponding to the item branch and generating a query result, the method further comprises:

acquiring a branch rule of the item to be updated;

acquiring branch information of the project branch in the code submission information;

and under the condition that the branch information accords with the branch rule, inquiring the interface document information corresponding to the project branch in the database to generate an inquiry result.

4. The method according to claim 1, wherein the generating a list of files to be parsed based on the query result comprises:

determining the file list to be analyzed based on the code file list corresponding to the project branch under the condition that the query result is used for representing that the interface document information corresponding to the project branch does not exist in the database; the code file list comprises all code source files corresponding to the item branches;

and determining the file list to be analyzed based on the code submission information under the condition that the query result is used for representing that interface document information corresponding to the item branch exists in the database.

5. The method of claim 4, wherein the determining the list of files to be parsed based on the code submission information comprises:

acquiring a current submission identifier and a first historical submission identifier carried by the code submission information; the current submission identifier is the unique identifier of the code submission information, and the first history submission identifier is the unique identifier of the first history code submission information corresponding to the project branch; the first historical code submission information is adjacent submission information sent by the code repository before sending the code submission information;

saving the current submission identifier in the code submission information;

comparing a second history submission identifier of second history code submission information stored locally with a first history submission identifier of first history code submission information carried in the code submission information;

and determining the file list to be analyzed based on second historical code submission information and the code submission information under the condition that the first historical submission identifier is inconsistent with the second historical submission identifier.

6. The method of claim 5, wherein determining the list of files to be parsed based on the second historical code submission information and the code submission information comprises:

obtaining at least two change file lists between the code submission information and the locally stored historical code submission information in the code repository; the at least two change file lists at least comprise a change file list in the code submission information and a change file list in the locally stored historical code submission information;

acquiring file identification and change time of each code source file in each change file list;

filtering at least one code source file corresponding to each file identifier according to the change time, and reserving the latest code source file corresponding to each file identifier;

and determining the file list to be analyzed based on the latest code source file corresponding to each file identifier.

7. The method according to claims 1 to 6, wherein the parsing the code source file in the file list to be parsed and updating the interface document information of the project branch comprises:

acquiring at least one code source file corresponding to the file list to be analyzed from the code warehouse;

analyzing the at least one code source file to obtain an analysis result of a code to be analyzed in each code source file; the analysis result comprises field identification and field definition information of a definition field; the definition field comprises an interface field and/or a parameter field;

and storing the analysis result to the database so as to update the interface document information of the project to be updated.

8. The method according to claim 7, wherein the saving the parsing result to the database to obtain interface document information of the item to be updated includes:

adding a current version number related to the submission time to the analysis result according to the submission time of the code submission information;

storing the analysis result carrying the version number to the database;

and deleting the analysis result of which the version number is smaller than the current version number in the database to obtain the interface document information of the item to be updated.

9. The method of claim 7, wherein said parsing each code source file to obtain a result of parsing the code to be parsed in each code source file comprises:

converting each code source file into a corresponding abstract code tree to obtain at least one abstract code tree;

analyzing each abstract code tree to obtain identification information and definition information of each code source file; the identification information is used for positioning the code source file in the database to obtain the definition information; the definition information comprises field identification and field definition information of definition fields contained in the code source file; the definition field includes an interface field and/or a parameter field.

10. The method of claim 1, wherein generating an interface document based on the interface document information in response to an interface document viewing event for the project branch comprises:

acquiring a target item identifier and a target interface identifier carried by the interface document viewing request;

inquiring target interface document information corresponding to the target item identification in the database;

acquiring target interface information and target parameter information corresponding to a target interface in the target interface document information based on the target interface identifier;

generating the interface document based on the target interface information and the target parameter information.

11. The method according to claim 10, wherein the obtaining target interface information and target parameter information corresponding to a target interface from the target interface document information based on the interface identifier comprises:

acquiring target interface information corresponding to the target interface from the target interface document information according to the target interface identifier; the target interface information comprises interface identification information corresponding to the interface;

determining an interface analysis result corresponding to the interface source file based on the interface identification information;

acquiring definition information in the interface analysis result; and generating target parameter information of the interface based on the definition information.

12. The method of claim 10, wherein the generating target parameter information for the interface based on the definition information comprises:

acquiring parameter identification and parameter definition information of at least one interface parameter definition field in the definition information;

taking the field identification and the field definition information of the interface parameter definition field as the target parameter information under the condition that the parameter definition information of the interface parameter definition field is a built-in type;

determining reference identification information based on field identification of the interface parameter definition field under the condition that the parameter definition information of the interface parameter definition field is of a composite type; and acquiring a field analysis result corresponding to the reference identification information, and generating target parameter information of the interface based on definition information in the field analysis result.

13. An interface document generation apparatus, comprising:

the first acquisition module is used for acquiring code submission information sent by the code warehouse in response to a code submission event; the code submitting information comprises a change file list and a project branch corresponding to the code submitting event; the code submitting event representation client submits at least one change code source file corresponding to the change file list to the code warehouse;

the query module is used for querying the interface document information corresponding to the item branch in the database to generate a query result; the query result is used for representing whether interface document information corresponding to the item branch exists in the database or not;

the first generation module is used for generating a file list to be analyzed based on the query result; the file list to be analyzed comprises the at least one change code source file;

a second generation module to generate an interface document based on the interface document information in response to an interface document viewing event for the project branch.

14. An interface document generation apparatus, characterized by comprising:

a memory for storing executable instructions;

a processor for implementing the method of any one of claims 1 to 12 when executing executable instructions stored in the memory.

15. A computer-readable storage medium having stored thereon executable instructions for, when executed by a processor, implementing the method of any one of claims 1 to 12.