CN115576536A

CN115576536A - Method and system for automatically generating interface document by analyzing byte codes

Info

Publication number: CN115576536A
Application number: CN202211410534.2A
Authority: CN
Inventors: 王文龙; 王茹茹
Original assignee: CITIC Aibank Corp Ltd
Current assignee: CITIC Aibank Corp Ltd
Priority date: 2022-11-11
Filing date: 2022-11-11
Publication date: 2023-01-06

Abstract

The application provides a method and a system for automatically generating an interface document by analyzing byte codes, which are characterized by comprising the following steps: s1, uploading JAR and WAR packages which are compiled and packaged; s2, decompressing JAR and WAR packets, and scanning and extracting first format files in the JAR and WAR packets through an ASM byte code tool; s3, converting the first format file into a ClassNode type, and naming the first format file of the ClassNode type as a second file; s4, acquiring class structure information of the second file by using a first tool of an ASM Tree API; and S5, the class structure information is combined with the first annotation information to analyze RESTful API document information of the second file. The invention can solve the problem that a Swagger framework is not introduced, the invasion of the business code caused by modifying the source code is not wanted, and the system RESTful API document is wanted to be obtained.

Description

Method and system for automatically generating interface document by analyzing byte codes

Technical Field

The invention relates to the technical field of automatic generation of interface documents, in particular to a method and a system for automatically generating an interface document by analyzing byte codes.

Background

At present, swagger is often used to generate RESTful API documents in the prior art, but the prior art has the following disadvantages: 1. the Swagger has invasiveness to the business code of the project, and the user can automatically generate the corresponding RESTful API document after the service is started only by introducing the Springfox Swagger dependent component and writing the corresponding Java annotation code. 2. For old systems which do not introduce Swagger, or systems which cannot be recompiled and packed into JAR and WAR packages due to lack of source codes, it is difficult to automatically generate RESTful API documents by modifying business codes in an invasive way, and service starting failure may be caused by introducing new components, so that service instability is caused. 3. The Swagger automatically generates the API document also depends on the service running, and can only sense the change of the RESTful API after the service is started, and the RESTful API document is simultaneously stopped after the service is stopped.

Therefore, in order to solve the above technical problem, the present application provides a method, an apparatus, and a readable storage medium for automatically generating an interface document by analyzing bytecode. Under the condition of not modifying any source code of the project, corresponding OpenAPI 3.0 annotation does not need to be written, the method does not depend on the starting operation of Java service, class files in JAR and WAR packages are directly scanned, and RESTful API document information is automatically analyzed and extracted by scanning the class files through an ASM bytecode tool. The method solves the problems that a Swagger framework is not introduced, the source code is not required to be modified to cause invasion to the business code, and the RESTful API document of the system is required to be obtained.

It is worth noting that the data collection and migration actions involved in the present application are agreed by the user and are necessary for the applicant to perform normal business activities. The collected data applicant is subjected to desensitization processing such as anonymization and confidentiality, and the access right of the data is correspondingly set so as to ensure that the privacy of the user is not revealed. The data processing activities performed by the applicant are in accordance with the regulations of laws and regulations such as data security laws and personal information protection laws.

Disclosure of Invention

In order to overcome the defects of the prior art, the invention provides a method and a device for automatically generating an interface document by analyzing byte codes and a readable storage medium. The method comprises the following steps:

a first aspect of the present application provides a method for automatically generating an interface document by analyzing bytecode, including:

s1, uploading JAR and WAR packets which are compiled and packaged;

s2, decompressing JAR and WAR packets, scanning and extracting first format files in the JAR and WAR packets through an ASM byte code tool, wherein the first format files comprise class files;

s3, converting the first format file into a ClassNode type, and naming the first format file of the ClassNode type as a second file;

s4, obtaining class structure information of the second file by using a first tool of an ASM Tree API, wherein the first tool comprises a ClassNode, a MethodNode, a FieldNode and an AntotationNode, and the class structure information comprises a class name, all classes methods, all member variables of the class and class annotation information;

and S5, analyzing RESTful API document information of the second file by combining the class structure information with the first annotation information, wherein the first annotation information comprises annotation information of Swagger2, openAPI 3.0 and SpringMVC, and the RESTful API document information comprises the name of the interface, the request type of the interface, the request address URI of the interface and input and output parameters of the interface.

Further, the step S1 includes:

s11, automatically uploading JAR and WAR packages by a user through a manual uploading or continuous integration or continuous deployment pipeline;

and S12, judging whether the JAR and WAR packets meet the preset format requirement or not, and caching the JAR and WAR packets if the JAR and WAR packets meet the preset format requirement, wherein the preset format requirement comprises a class type requirement.

Further, the step S3 includes: and caching the second format file in a Key-value mode, wherein the Key stores the class name, and the value stores the structure information of the class node class.

Further, the step S5 includes:

s51, judging whether class annotation information of the second file contains first interface type annotation information of SpringMVC, wherein the first interface type annotation comprises @ Controller and @ RestController interface type annotation information;

s52, if the class annotation information of the second file contains the first interface type annotation information of the SpringMVC, analyzing the second file based on the SpringMVC annotation information to obtain first sub annotation information based on a SpringMVC framework;

s53, judging whether the class annotation information of the second file contains second interface type annotation information of Swagger2 and OpenAPI 3.0, and if so, analyzing the second file based on the Swagger2 and OpenAPI 3.0 annotation information to obtain second sub-annotation information;

and S54, obtaining the first annotation information based on the first sub annotation information and the second sub annotation information.

Further, the method further comprises S6: and converting RESTful API document information into a JSON format.

And further, the RESTful API document information converted into the JSON format is stored in a database and returned to the front-end page for display after being stored.

A second aspect of the present application provides an apparatus for automatically generating a document based on ASM, which includes:

the uploading module is used for uploading the JAR and WAR packages which are compiled and packaged;

the decompression scanning module is used for decompressing JAR and WAR packets, scanning and extracting first format files in the JAR and WAR packets through an ASM byte code tool, wherein the first format files comprise class files;

the conversion module is used for converting the first format file into a ClassNode type and naming the first format file of the ClassNode type as a second file;

the first obtaining module is used for obtaining class structure information of a second file by using a first tool of an ASM Tree API, wherein the first tool comprises a ClassNode, a MethodNode, a FieldNode and an AntotationNode, and the class structure information comprises a class name, all methods of the class and all member variables of the class;

and the analysis module is used for analyzing RESTful API document information of the second file by combining the class structure information with the first annotation information, wherein the first annotation information comprises the annotation information of Swagger2, openAPI 3.0 and SpringMVC, and the RESTful API document information comprises the name of the interface, the request type of the interface, the request address URI of the interface and the input and output parameters of the interface.

A third aspect of the present application provides an electronic device, comprising: a processor, and a memory communicatively coupled to the processor;

the memory stores computer execution instructions;

the processor executes computer-executable instructions stored by the memory to implement the method for automatically generating documents based on ASM.

A fourth aspect of the present application provides a computer-readable storage medium, wherein computer-executable instructions are stored in the computer-readable storage medium, and when the computer-executable instructions are executed by a processor, the computer-readable storage medium is configured to implement the method for automatically generating a document based on ASM.

A fifth aspect of the present application proposes a computer program product, characterized by comprising a computer program, which when executed by a processor, implements the above method for automatically generating a document based on ASM.

The invention has the beneficial effects that: under the condition of not modifying any source code of the project, corresponding OpenAPI 3.0 annotation does not need to be written, the class files in JAR and WAR packages are directly scanned independent of the starting and running of Java service, and RESTful API document information is automatically analyzed and extracted by scanning the class files through an ASM byte code tool. The method mainly solves the problem that a Swagger framework is not introduced, invasion of business codes caused by modifying source codes is not wanted, and system RESTful API documents are wanted to be obtained, and items with the Swagger2 and OpenAPI 3.0 frameworks obtain RESTful API document information based on the Swagger2 and OpenAPI 3.0 annotations.

Drawings

FIG. 1 is a flow chart illustrating a method for automatically generating an interface document by analyzing bytecode according to the present invention.

FIG. 2 is a block diagram of an apparatus for automatically generating an interface document by analyzing bytecode according to the present invention.

Fig. 3 is a schematic structural diagram of an electronic device according to an embodiment of the present invention.

Detailed Description

For a clearer understanding of the contents of the present invention, reference will be made to the accompanying drawings and examples.

It is to be understood that such description is merely illustrative and not intended to limit the scope of the present invention. Moreover, in the following description, descriptions of well-known structures and techniques are omitted so as to not unnecessarily obscure the concepts of the present invention. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The words "a", "an" and "the" and the like as used herein are also intended to include the meanings of "a plurality" and "the" unless the context clearly dictates otherwise. Furthermore, the terms "comprises," "comprising," and the like, as used herein, specify the presence of stated features, steps, operations, and/or components, but do not preclude the presence or addition of one or more other features, steps, operations, or components.

All terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art unless otherwise defined. It is noted that the terms used herein should be interpreted as having a meaning that is consistent with the context of this specification and should not be interpreted in an idealized or overly formal sense. The present invention is an improvement over the prior art, and therefore, the parts not described in the present application are implemented in the prior art.

Interpretation of terms:

swagger: and a related RESTful API document can be automatically generated according to the service code, a corresponding test interface is provided, and a response message in a JSON format is automatically displayed. Developers almost do not need to specially maintain RESTful API, and communication and joint debugging cost of front-end developers and back-end developers is greatly reduced.

In the process of starting a Java project, when a Spring context is initialized, a framework automatically loads some Swagger-related beans to the current context according to configuration, and automatically scans classes which may need to generate API documents in a system, and generates corresponding information for caching. If the project MVC control layer uses SpringMVC, all the Controller classes are automatically scanned, and corresponding API documents are generated according to the annotations of the methods in the Controller classes.

RESTful API: i.e. an application program interface having the REST style. REST (Representational State Transfer, REST for short) describes an architectural style network system, such as a web application. REST refers to a set of architectural constraints and principles, and the application or design that satisfies these constraints and principles is RESTful.

OpenAPI 3.0 specification: the OpenAPI specification (OAS) is a generic, programming language-independent API description specification, and its main role is to describe REST APIs, which can be read by developers as documents, and can make machines automatically generate client codes according to the documents, etc. OpenAPI starts from Swagger specification.

The ASM is an open source framework for bytecode enhancement, and is a class library which is popular in Java and used for reading and writing bytecode, and is used for analyzing and converting code based on a bytecode layer. ASM is a Java bytecode manipulation framework that can be used to dynamically generate classes or enhance the functionality of existing classes. The ASM can directly generate a binary class file, can also dynamically change the class behavior before the class is loaded into the virtual machine, and can change the class behavior, analyze the class information and even generate a new class according to requirements after reading information from the class file. Currently, many frameworks such as cglib, hibernate, spring use ASM opbytecodes directly or indirectly.

JAR file: java ARchive (english: java ARchive) is a software package file format that is typically used to aggregate a large number of Java class files, associated metadata and resource (text, pictures, etc.) files into one file in order to distribute Java platform applications or libraries.

The WAR file: web Application ARchive (english: web Application ARchive) is a JAR file that contains JSP, java Servlet, java classes, XML files, tag libraries, static Web pages (HTML and related files), and other resources that make up a Web Application for distribution.

The technical principle of the application is as follows: java can be compiled once and run everywhere, because the JVM is customized for various operating systems and platforms, and because whatever the platform is, the Java can be compiled to generate a byte code file (class file) with a fixed format for the JVM to use. The JVM specification has certain requirements on the format of class files, such as the requirement on the ordering format of magic numbers, version numbers, constant pools and the like.

Swagger is often used in the prior art to generate RESTful API documents, but has the following disadvantages: 1. the Swagger has invasiveness to the business code of the project, and the user can automatically generate the corresponding RESTful API document after the service is started only by introducing the Springfox Swagger dependent component and writing the corresponding Java annotation code. 2. For old systems which do not introduce Swagger, or systems which cannot be recompiled and packed into JAR and WAR packages due to lack of source codes, it is difficult to automatically generate RESTful API documents by modifying business codes in an invasive way, and service starting failure may be caused by introducing new components, so that service instability is caused. 3. The Swagger automatically generates the API document also depends on the service operation, and can sense the change of the RESTful API only after the service is started, and the RESTful API document is simultaneously deactivated after the service is stopped.

FIG. 1 is a flow chart illustrating a method for automatically generating an interface document by analyzing bytecode according to the present invention. A first aspect of the present application provides a method for automatically generating an interface document by analyzing bytecode, including:

s1, uploading JAR and WAR packages which are compiled and packaged;

further, the step S1 includes:

s11, a user automatically uploads JAR and WAR packages through a manual uploading or continuous integration or continuous deployment pipeline;

s12, judging whether the JAR and WAR packets meet the preset format requirement or not, and caching the JAR and WAR packets if the JAR and WAR packets meet the preset format requirement, wherein the preset format requirement comprises a class type requirement.

Specifically, a user can manually upload (or automatically upload through a CICD continuous integration and continuous deployment pipeline) a JAR and WAR packet which is constructed and compiled by calling an API scanning interface to a server, the API scanning interface can automatically check whether the format of the packet meets the requirement, store the packet in a temporary directory of the server, and delete the file information of the API after scanning and analyzing.

Specifically, the preset format requirement may be set as a class type requirement to select a target class type file, and the target class type file may be screened out by a labeling and marking method.

specifically, the API scanning interface decompresses the uploaded JAR and WAR packages layer by layer, designs corresponding filter rules according to file names and suffixes, and acquires a target class file to be scanned in the packages.

The Java source code is compiled into a class file and the interface information associated with the RESTful API does not disappear or is present in the class file. Therefore, the document information related to the RESTful API can be correctly extracted only by analyzing the corresponding class file and according to a certain rule.

The target class file is firstly converted into a ClassNode type in an ASM Tree API, and then stored in a Map < String, classNode > set. The class name is stored in Key of Map < String, class node >, and the structure description of class node is stored in value, which is used as context buffer of follow-up analysis class information.

S4, obtaining class structure information of the second file by using a first tool of an ASM Tree API, wherein the first tool comprises a ClassNode, a MethodNode, a FieldNode and an AntotatinodeB, and the class structure information comprises a class name, all class methods, all class member variables, class annotation information and the like;

specifically, the second file converted into the classdoude type contains different class structure information, and the class behavior can be changed based on the ASM framework, and after the ASM reads information from the class file, the class behavior can be changed, the class information can be analyzed, and even a new class can be generated according to requirements. The tool classes classdode, methodNode, fieldNode and AnnotationNode provided in the ASM Tree API can completely describe the structure information of the classes in the class file, and through analyzing and processing the class structure information, we can extract the content that we want, such as the names of the classes, all methods of the classes, all member variables of the classes, annotations of the classes, and the like. By annotating with class annotation information, we can obtain all information about RESTful API documents in a JAR, WAR package by analyzing bytecode.

Specifically, the ASM Tree API includes various structures, and if the format of the second file needs to be converted subsequently, the conversion can be performed in the ASM Tree API to meet the requirement of tool parsing. Various structures such as ClassNode class structures, methodNode method class structures, fieldNode member variable class structures, and AntotationNode annotation class structures can obtain class structure information for structure analysis. The ClassNode class structure comprises class version number, class name and class module information, and for other class structures comprising other information, the class structure information can be obtained by analyzing the second file.

And S5, analyzing RESTful API document information of the second file by combining the class structure information with the first annotation information, wherein the first annotation information comprises annotation information of Swagger2, openAPI 3.0 and SpringMVC, and the RESTful API document information comprises the name of the interface, the request type of the interface, the request address URI of the interface and the input and output parameters of the interface.

Further, the step S5 includes:

s51, judging whether the class annotation information of the second file contains first interface type annotation information of SpringMVC, wherein the first interface type annotation comprises @ Controller and @ RestController interface type annotation information;

Specifically, in the process of extracting RESTful API, a large amount of comments related to spring mvc are also used, and by analyzing comments of classes or methods, which class files are classes in which interfaces are located and which class methods are methods in which interface types are located can be quickly located, and information related to descriptions, interface types (GET, POST, etc.), interface URIs, etc. related to the interfaces can also be extracted. The SpringMVC Controller annotation for Web layer interfaces is a well known part of those skilled in the art, such as the annotation name @ Controller, described as Controller annotation, and in HTTP interface request type annotation, the annotation name @ GetMapping, described as handling HTTP GET requests. The custom annotation may be preset.

Similarly, after Swagger2 and OpenAPI 3.0 projects have been accessed, we can obtain information such as a description document of the interface by analyzing annotations related to Swagger2 and OpenAPI 3.0. The same can be preset for custom annotations.

It should be noted that the project may only include one of Swagger2 and OpenAPI 3.0, or the project may not introduce any old system that automatically generates a RESTful API document in frames such as Swagger2 and OpenAPI 3.0, and different annotation information may be selected according to the situation of the project when configuring the annotation.

By analyzing class byte code files in JAR and WAR packages, and by directly scanning annotations such as @ RestController and @ Controller of SpringMVC, the name of an interface, the request type (GET, POST, PUT, DELETE and PATCH) of the interface, the request address URI of the interface and the in-out parameters (including parameter name, type, necessity, parameter description and the like) of the interface are extracted, and information such as complex object parameters and nested object parameters is analyzed, so that a RESTful API document can be extracted and automatically generated.

Further, the method further includes S6: and converting RESTful API document information into a JSON format.

Specifically, the analyzed and extracted related contents are spliced into API interface entity classes, all the scanned interface entity classes are converted into JSON format, and the JSON format is firstly persisted into a MySQL database and finally returned to the front-end page for display.

FIG. 2 is a block diagram of an apparatus for automatically generating an interface document by analyzing bytecode according to the present invention. A second aspect of the present application provides an apparatus for automatically generating a document based on ASM, including:

and the analysis module is used for analyzing RESTful API document information of the second file by combining the class structure information with the first annotation information, wherein the first annotation information comprises annotation information of Swagger2, openAPI 3.0 and SpringMVC, and the RESTful API document information comprises the name of the interface, the request type of the interface, the request address URI of the interface and the input and output parameters of the interface.

Further, the apparatus further includes an upload determination module configured to:

Further, the apparatus further comprises a storage module: the method is used for caching the second format file in a Key-value mode, wherein the Key stores class names, and the value stores structural information of class nodes.

Further, the apparatus further comprises an annotation module configured to:

Further, the device further comprises a conversion module: and converting RESTful API document information into a JSON format.

Further, the device also comprises a storage display module, which is used for storing the RESTful API document information converted into the JSON format into a database, and returning the document information to the front-end page for display after storage.

Fig. 3 is a schematic structural diagram of an electronic device according to an embodiment of the present application. As shown in fig. 3, the electronic device may include: transceiver 121, processor 122, memory 123.

The processor 122 executes computer-executable instructions stored in the memory, causing the processor 122 to perform the aspects of the embodiments described above. The processor 122 may be a general-purpose processor including a central processing unit CPU, a Network Processor (NP), and the like; but also a digital signal processor DSP, an application specific integrated circuit ASIC, a field programmable gate array FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components.

Memory 123 is coupled to and in communication with processor 122 via a system bus, and memory 123 is used to store computer program instructions.

The transceiver 121 may be used to acquire class structure information and first annotation information of the second file.

The system bus may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The system bus may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown, but this does not mean that there is only one bus or one type of bus. The transceiver is used to enable communication between the database access device and other computers (e.g., clients, read-write libraries, and read-only libraries). The memory may include Random Access Memory (RAM) and may also include non-volatile memory (non-volatile memory).

The electronic device provided by the embodiment of the present application may be the terminal device of the foregoing embodiment.

The embodiment of the application also provides a chip for running the instructions, and the chip is used for executing the technical scheme of the method for automatically generating the interface document by analyzing the byte codes in the embodiment.

An embodiment of the present application further provides a computer-readable storage medium, where a computer instruction is stored in the computer-readable storage medium, and when the computer instruction runs on a computer, the computer is enabled to execute a technical solution of the method for automatically generating an interface document by analyzing bytecode in the foregoing embodiment.

The present application further provides a computer program product, where the computer program product includes a computer program stored in a computer-readable storage medium, and at least one processor can read the computer program from the computer-readable storage medium, and when the at least one processor executes the computer program, the at least one processor can implement the technical solution of the method for automatically generating an interface document by analyzing bytecode in the foregoing embodiments.

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.

It will be understood that the present application is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Those skilled in the art will further appreciate that the algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that such functions may be performed in either hardware or software, depending upon the particular application and design constraints imposed on the technology, and that such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

While preferred embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all such alterations and modifications as fall within the scope of the invention.

The above description is only for the preferred embodiment of the present invention, but the scope of the present invention is not limited thereto, and any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope of the present invention are included in the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A method for automatically generating an interface document by analyzing bytecode, comprising:

s1, uploading JAR and WAR packages which are compiled and packaged;

s4, obtaining class structure information of the second file by using a first tool of an ASM Tree API, wherein the first tool comprises a ClassNode, a MethodNode, a FieldNode and an AntotationNode, and the class structure information comprises a class name, all classes methods, all member variables of the class, class annotation information and the like;

2. The method according to claim 1, wherein the step S1 comprises:

3. The method according to claim 1, wherein the step S3 comprises: and caching the second format file in a Key-value mode, wherein the Key stores the class name, and the value stores the structure information of the class node class.

4. The method according to claim 1, wherein the step S5 comprises:

5. The method according to claim 1, characterized in that the method further comprises S6: and converting RESTful API document information into a JSON format.

6. The method of claim 5, wherein the RESTful API document information converted into JSON format is stored in a database and returned to the front-end page for presentation.

7. An apparatus for automatically generating an interface document by analyzing bytecode, comprising:

the decompression scanning module is used for decompressing JAR and WAR packages, scanning and extracting first format files in the JAR and WAR packages through an ASM byte code tool, wherein the first format files comprise class files;

8. An electronic device, comprising: a processor, and a memory communicatively coupled to the processor;

the memory stores computer-executable instructions;

the processor executes computer-executable instructions stored by the memory to implement the method of any of claims 1-6.

9. A computer-readable storage medium having computer-executable instructions stored therein, which when executed by a processor, are configured to implement the method of any one of claims 1-6.

10. A computer program product, characterized in that it comprises a computer program which, when being executed by a processor, carries out the method of any one of claims 1-6.