CN112650533A

CN112650533A - Interface document generation method and device and terminal equipment

Info

Publication number: CN112650533A
Application number: CN202011535639.1A
Authority: CN
Inventors: 李宗波; 张卓韬; 杨永帮; 邬秋元; 陈晓丹; 张涛
Original assignee: WeBank Co Ltd
Current assignee: WeBank Co Ltd
Priority date: 2020-12-22
Filing date: 2020-12-22
Publication date: 2021-04-13
Anticipated expiration: 2040-12-22
Also published as: CN112650533B

Abstract

The application provides a generation method, a generation device and terminal equipment of an interface document, wherein the method comprises the following steps: after receiving a generation request for generating an interface document, determining an object program code according to the generation request, then respectively determining a request field and a return field according to the object program code, respectively acquiring a field name and a field type corresponding to the request field and the return field through a Java reflection mechanism, and then generating the interface document corresponding to the object program code according to the field name and the field type corresponding to the request field and the return field. The interface document generation method, the interface document generation device and the terminal equipment can avoid the phenomenon that a user manually writes the interface document, so that the interface document generation efficiency can be improved, and the software system development cost can be reduced.

Description

Interface document generation method and device and terminal equipment

Technical Field

The present application relates to computer technologies, and in particular, to a method and an apparatus for generating an interface document, and a terminal device.

Background

With the development of computer technology, more and more technologies (big data, distributed, artificial intelligence, etc.) are applied in the financial field, and the traditional financial industry is gradually changing to financial technology (Fintech), but because of the requirements of security and real-time performance of the financial industry, higher requirements are also put forward on the service request technology. At present, in the field of financial technology, with the continuous development of computer technology, the complexity of a software system is higher and higher, and the amount of program codes is larger and larger.

In the prior art, because a software system may have a large amount of program codes, multiple developers are often required to collaborate to develop the software system. In order to facilitate different developers to know the code content mutually, the developers need to spend a lot of time writing an interface document corresponding to the program code of the software system in addition to writing the code, thereby not only resulting in low efficiency of generating the interface document, but also resulting in high development cost of the software system.

Disclosure of Invention

In order to solve the problems in the prior art, the application provides an interface document generation method, an interface document generation device and terminal equipment, which can improve the interface document generation efficiency and reduce the development cost of a software system.

In a first aspect, an embodiment of the present application provides a method for generating an interface document, where the method for generating an interface document may include:

a generation request for generating an interface document is received.

And determining a target program code according to the generation request.

And respectively determining a request field and a return field according to the target program code.

And respectively acquiring the field name and the field type corresponding to the request field and the return field through a Java reflection mechanism.

And generating an interface document corresponding to the target program code according to the field name and the field type corresponding to the request field and the return field respectively.

In a possible implementation manner, the generating an interface document corresponding to the target program code according to the field name and the field type corresponding to each of the request field and the return field includes:

and judging whether the field type of the field is a common data type or not aiming at any field in the request field and the return field, if the field type of the field is not the common data type, determining the sub-field included in the field according to the field type of the field, acquiring the field name and the field type corresponding to the sub-field, determining the sub-field as a new field, and repeatedly executing the step until the field type of the field is the common data type.

And generating an interface document corresponding to the target program code according to the field name and the field type of the field and the field name and the field type of the sub-field corresponding to the field.

In a possible implementation manner, the generating an interface document corresponding to the target program code according to the field name and the field type of the field and the field name and the field type of the subfield corresponding to the field includes:

and acquiring a preset template corresponding to the target program code.

The hierarchical relationship between all fields and all subfields is determined.

And importing the field name and the field type of the field and the field name and the field type of the sub-field corresponding to the field into the preset template according to the hierarchical relationship to generate the interface document.

In one possible implementation, determining a request field according to the object program code includes:

and acquiring a plurality of classes in the target program code.

For each class, if the code annotation corresponding to the class comprises annotation information identified by a first identifier, and the class is determined to be a request class according to the annotation information identified by the first identifier, determining a field in the request class to be the request field.

In one possible implementation, the method further includes:

and if the code annotation corresponding to each of the plurality of classes does not include the annotation information identified by the first identifier, judging whether the code annotation corresponding to each class includes a preset method.

And if the code annotation corresponding to the first type in the multiple types comprises a preset method, acquiring annotation information identified by a second identifier in the reference of the preset method.

And determining a field in the annotation information identified by the second identifier as the request field.

In one possible implementation, determining a return field according to the object program code includes:

and acquiring a plurality of classes in the target program code.

And judging whether the code annotation corresponding to the class comprises annotation information identified by the third identifier or not for each class.

And if the code annotation corresponding to the class comprises annotation information identified by a third identifier, judging whether a preset class exists in the annotation information identified by the third identifier.

And if the preset class exists, determining the field in the preset class as the return field.

In one possible implementation, the method further includes:

and if the preset class does not exist in the annotation information identified by all the third identifiers, matching the class names of all the classes according to a preset rule.

And if the matching is successful, determining the fields in the successfully matched class as the return fields.

If the matching fails, acquiring a second class of the annotation information with the first identifier identification in all the classes, determining a request class in the second class according to the annotation information identified by the first identifier, acquiring an interface identification corresponding to the request class, determining an unsolicited class in the second class according to the annotation information identified by the first identifier, and determining a field in the unsolicited class, in which the interface identification corresponding to the unsolicited class is the same as the interface identification corresponding to the request class, as the return field.

In one possible implementation, the method further includes:

and acquiring interface information corresponding to the target program code according to the code annotations corresponding to the multiple classes in the target program code, wherein the interface information comprises at least one of an interface identifier, an interface name and interface description information.

And adding the interface information into the interface document.

In one possible implementation, the method further includes:

and if the field comprises annotation information related to parameter verification, acquiring an attribute value in the annotation information related to parameter verification.

And determining the attribute value as the value description information of the field, and adding the corresponding relation between the field and the value description information into the interface document.

In one possible implementation, the method further includes:

and generating a Java file corresponding to the simple Java object POJO according to the request field and the return field.

And sending the Java file corresponding to the POJO to a cloud server.

In a second aspect, an embodiment of the present application further provides an apparatus for generating an interface document, where the apparatus for generating an interface document may include:

a receiving unit, configured to receive a generation request for generating an interface document.

And the processing unit is used for determining a target program code according to the generation request and respectively determining a request field and a return field according to the target program code.

And the acquisition unit is used for respectively acquiring the field names and the field types corresponding to the request fields and the return fields through a Java reflection mechanism.

And the generating unit is used for generating the interface document corresponding to the target program code according to the field name and the field type corresponding to the request field and the return field respectively.

In a possible implementation manner, the generating unit is specifically configured to determine, for any one of the request field and the return field, whether a field type of the field is a normal data type, determine, if the field type of the field is not a normal data type, a subfield included in the field according to the field type of the field, acquire a field name and a field type corresponding to the subfield, determine the subfield as a new field, and repeatedly perform this step until the field type of the field is a normal data type; and generating an interface document corresponding to the target program code according to the field name and the field type of the field and the field name and the field type of the sub-field corresponding to the field.

In a possible implementation manner, the generating unit is specifically configured to obtain a preset template corresponding to the target program code; determining a hierarchical relationship between all fields and all subfields; and importing the field name and the field type of the field and the field name and the field type of the sub-field corresponding to the field into the preset template according to the hierarchical relationship to generate the interface document.

In a possible implementation manner, the processing unit is specifically configured to obtain a plurality of classes in the target program code; for each class, if the code annotation corresponding to the class comprises annotation information identified by a first identifier, and the class is determined to be a request class according to the annotation information identified by the first identifier, determining a field in the request class to be the request field.

In a possible implementation manner, the processing unit is further configured to determine whether the code annotation corresponding to each of the plurality of classes includes a preset method if the code annotation corresponding to each of the plurality of classes does not include annotation information identified by the first identifier.

The obtaining unit is further configured to obtain annotation information identified by a second identifier in a reference of a preset method if a code annotation corresponding to the first class includes the preset method in the multiple classes.

The processing unit is further configured to determine a field in the annotation information identified by the second identifier as the request field.

In a possible implementation manner, the processing unit is specifically configured to obtain a plurality of classes in the target program code; judging whether the code annotation corresponding to each class comprises annotation information identified by a third identifier or not; if the code annotation corresponding to the class comprises annotation information identified by a third identifier, judging whether a preset class exists in the annotation information identified by the third identifier; and if the preset class exists, determining the field in the preset class as the return field.

In a possible implementation manner, the processing unit is further configured to, if the preset class does not exist in the annotation information identified by all the third identifiers, match class names of all classes according to a preset rule; if the matching is successful, determining the fields in the successfully matched class as the return fields; if the matching fails, acquiring a second class of the annotation information with the first identifier identification in all the classes, determining a request class in the second class according to the annotation information identified by the first identifier, acquiring an interface identification corresponding to the request class, determining an unsolicited class in the second class according to the annotation information identified by the first identifier, and determining a field in the unsolicited class, in which the interface identification corresponding to the unsolicited class is the same as the interface identification corresponding to the request class, as the return field.

In a possible implementation manner, the obtaining unit is further configured to obtain, according to the code annotation corresponding to the multiple classes in the target program code, interface information corresponding to the target program code, where the interface information includes at least one of an interface identifier, an interface name, and interface description information.

The processing unit is further configured to add the interface information to the interface document.

In a possible implementation manner, the obtaining unit is further configured to obtain an attribute value in the annotation information related to parameter verification if the field includes annotation information related to parameter verification.

The processing unit is further configured to determine the attribute value as value description information of the field, and add a correspondence between the field and the value description information in the interface document.

In one possible implementation, the apparatus further includes a sending unit.

And the generating unit is also used for generating a Java file corresponding to the simple Java object POJO according to the request field and the return field.

And the sending unit is used for sending the Java file corresponding to the POJO to a cloud server.

In a third aspect, an embodiment of the present application further provides a terminal device, where the terminal device may include a processor and a memory; wherein the content of the first and second substances,

the memory is used for storing the computer program.

The processor is configured to read the computer program stored in the memory, and execute the interface document generation method in any one of the possible implementation manners of the first aspect according to the computer program in the memory.

In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, where a computer-executable instruction is stored in the computer-readable storage medium, and when a processor executes the computer-executable instruction, the method for generating an interface document in any one of the possible implementation manners of the first aspect is implemented.

In a fifth aspect, an embodiment of the present application further provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the method for generating an interface document according to any one of the foregoing possible implementation manners of the first aspect is implemented.

According to the interface document generation method, the interface document generation device and the terminal equipment, after a generation request for generating an interface document is received, an object program code is determined according to the generation request, then a request field and a return field are respectively determined according to the object program code, field names and field types corresponding to the request field and the return field are respectively obtained through a Java reflection mechanism, and then the interface document corresponding to the object program code is generated according to the field names and the field types corresponding to the request field and the return field. On one hand, the phenomenon that a user manually writes the interface document can be avoided, so that the generation efficiency of the interface document can be improved, and the development cost of a software system can be reduced. On the other hand, through a Java reflection mechanism, the field names and the field types corresponding to the request field and the return field can be obtained through deep traversal of the fields, and the generation of the interface document under various scenes such as extensive types, lists, object nesting and the like can be supported, so that the interface document can be generated even when annotation information does not exist in some fields, the manual intervention cost can be greatly reduced, and the phenomenon that the interface document needs to be strongly dependent on the annotation information when being generated is avoided.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art that other drawings can be obtained according to the drawings without inventive exercise.

Fig. 1 is a system architecture diagram of a method for generating an interface document according to an embodiment of the present application;

fig. 2 is a schematic flowchart of a method for generating an interface document according to an embodiment of the present application;

FIG. 3 is a schematic diagram of the structure of an interface document;

fig. 4 is a schematic structural diagram of an interface document generation apparatus according to an embodiment of the present application;

fig. 5 is a schematic structural diagram of a terminal device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

The terms "first," "second," "third," and "fourth," if any, in the description and claims of this application and the above-described figures are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the application described herein are capable of operation in sequences other than those illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

In order to help those skilled in the art to better understand the technical solutions of the present application, the related contents related to the technical solutions of the present application will be described below.

(1) Annotation (Annotation), an Annotation mechanism introduced in JDK5.0, can be tagged in the fields of classes, methods, variables, parameters, and packets.

(2) The Java reflection mechanism refers to that all properties and methods of a class can be known for any class in a running state, and any method and property of an object can be called for any object.

(3) Generic, refers to a mechanism of parameterized types in the Java language.

The method for generating the interface document can be applied to scenes in which the interface document is required to be used for developing or maintaining system software. For example, at present, the complexity of software systems is higher and higher, the corresponding amount of program code is also higher and higher, and many software systems may have hundreds of thousands or even millions of lines of code, which requires multiple developers to collaborate to develop. However, the docking between different systems may require both parties to agree on parameters, and if developers read codes to obtain related parameters, the development efficiency is low. To facilitate inter-system interfacing, therefore, interface documentation is required. For another example, in the development process of a project, a caller and a server of a web project are usually separately developed, and the development of some application programs also requires developers of the caller and the server to define an interface together, and by writing an interface document, the developers of the caller and the server will develop according to the interface document to achieve the consistency of the interface of the caller and the server.

In the prior art, one implementation manner is that a user manually compiles an interface document through an Excel or MarkDown tool, and after the compilation is completed, the interface document is sent to other developers through a wire or manually uploaded to a cloud server for storage. Another implementation manner is that after a user manually writes an interface document through tools such as ApiPost or PostMan, the interface document can be automatically uploaded to a cloud server through the tools for storage and maintenance.

However, in the first implementation manner, besides writing program codes, testers need to spend a lot of time and effort to write interface documents, which not only results in low generation efficiency of the interface documents and high development cost of system software, but also easily causes problems of inconsistent versions of the interface documents maintained by different developers. In addition, after the writing is completed, the user needs to manually upload the file to the cloud for storage, so that the operation of the user is complicated, and mistakes are easily made.

In the second implementation manner, although the interface document can be automatically sent to the cloud server for storage, the tester still needs to manually write the interface document, which causes low generation efficiency of the interface document and high development cost of system software.

In view of the above problems, the embodiments of the present application provide a method for generating an interface document, the basic idea of the method is that, due to a Java reflection mechanism, in a program running state, for any class, all attributes and methods of the class can be known, and for any object, any method and attribute of the object can be called, in addition, a format of the interface document is generally relatively fixed, and a field name and a field type corresponding to a request field and a return field are included in the interface document, so a terminal device may obtain the request field and the return field included in an object program code by traversing the object program code corresponding to a software system, and obtain the field name and the field type corresponding to the request field and the field name and the field type corresponding to the return field by the Java reflection mechanism, thereby generating an interface document corresponding to the target level code. Therefore, the phenomenon that a user manually writes the interface document can be avoided, the generation efficiency of the interface document can be improved, and the development cost of a software system can be reduced. In addition, the function of writing the interface document in the code can be realized by using a mode of marking interfaces, classes and attributes by using Java custom Annotation (Annotation).

Before describing the scheme of the interface document generation method of the present application, the system architecture of the present application is explained with reference to fig. 1.

Fig. 1 is a system architecture diagram of a method for generating an interface document according to an embodiment of the present application. As shown in fig. 1, the system includes:

terminal device

101, 103 and server 104. Different developers can cooperatively develop the software system through different terminal devices. In addition, the program codes written by the developers through the terminal device 101 and the server 103 can be stored locally or transmitted to the server 104 through the network for storage. The server 104 may be a single server, or may be a server cluster formed by a plurality of servers.

Any one of the

terminal devices

101 and 103 may generate an interface document, taking the terminal device 101 as an example, when receiving a generation request for generating the interface document, the terminal device 101 determines an object program code, which may be obtained locally or from the server 104, and generates the interface document by traversing the object program code.

In addition, after the terminal device 101 generates the interface document, it generates a Java file corresponding to a simple Java object (POJO) according to the request class and the related information of the return class in the interface document, and sends the interface document and the Java file to the server 104 through the network for saving, so that other developers can call the interface document from the server 104 to check the interface document, thereby facilitating the user operation. In addition, other developers can download Java files from the server 104 to be applied to the program codes, so that the unification of the codes and the documents is realized, and the consistency of the interface codes is ensured.

It should be understood that the number of

terminal devices

101 and 103 and servers 104 in the system architecture shown in fig. 1 is merely exemplary, and that a greater or lesser number is within the scope of the present application. Also, in the above example operational scenario, the terminal device may be, for example, a Personal computer, a server, a tablet, a mobile phone, a Personal Digital Assistant (PDA), a notebook, or any other computing device with networking functionality. The network for communication between the terminal device and the server may include various types of wired and wireless networks, such as, but not limited to: the internet, a Local Area network, Wireless Fidelity (WIFI), a Wireless Local Area Network (WLAN), a cellular communication network (General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), 2G/3G/4G/5G cellular network), a satellite communication network, and so on.

With the system architecture of the present application understood, a detailed description will be given of a scheme of the interface document generation method of the present application with reference to fig. 2.

Fig. 2 is a flowchart illustrating a method for generating an interface document according to an embodiment of the present application, where the method may be performed by any device that performs the method for generating an interface document, and the device may be implemented by software and/or hardware. In this embodiment, the apparatus may be integrated in a terminal device as shown in fig. 1. As shown in fig. 2, the method for generating an interface document according to the embodiment of the present application includes the following steps:

step 201: a generation request for generating an interface document is received.

In this step, in the development process of the system software, the interface document export interface may be developed in the terminal device, and therefore, the generation request may be triggered by the user by clicking a certain control on the interface document export interface, or by inputting a certain command, such as by a Gradle command. In addition, the generation request may also be triggered automatically by the terminal device, for example, the generation request may be triggered periodically.

Step 202: and determining the target program code according to the generation request.

In this step, after receiving the generation request, the terminal device may determine, according to the generation request, the object program code of which the interface document needs to be generated. For example, the generation request may include a method name or a class name, and the terminal device may determine the corresponding object program code according to the method name or the class name.

Step 203: and respectively determining a request field and a return field according to the target program code.

For example, when a request field is determined, multiple classes in the target program code may be obtained, and for each class, if a code annotation corresponding to the class includes annotation information identified by a first identifier, and the class is determined as the request class according to the annotation information identified by the first identifier, a field in the request class is determined as the request field.

Specifically, the first identifier may be an @ Message, and an interface Identifier (ID), an interface name, interface description information, and whether a class is requested are maintained in the @ Message.

It will be appreciated that relevant annotations are included in the target program code for annotating classes and methods in the target program code for a developer to annotate a document in a manner that is, on the one hand, non-intrusive to business logic and, on the other hand, facilitates scanning of the target program code to determine classes in the target program code. Based on this, the terminal device scans the object program code, so as to obtain all classes in the object program code. If the code annotation corresponding to a certain class in all classes includes annotation information identified by the first identifier, whether the class is a request class or not can be determined according to the annotation information identified by the first identifier, and if the class is determined to be the request class, a field in the class can be determined as a request field.

In this manner, if the code annotation corresponding to a certain class in the target program code includes annotation information identified by the first identifier, and the class is determined as the request class according to the annotation information identified by the first identifier, the field in the request class may be directly determined as the request field, so that the efficiency of determining the request field may be improved.

For example, if the code annotation corresponding to each of the plurality of classes does not include the annotation information identified by the first identifier, it is determined whether the code annotation corresponding to each class includes the preset method, and if the code annotation corresponding to the first class includes the preset method, the annotation information identified by the second identifier included in the preset method is obtained, and a field in the annotation information identified by the second identifier is determined as the request field.

Specifically, the preset method may be a Controller method, wherein in a scenario of a hypertext Transfer Protocol (Http) interface, some classes are marked in the Controller method. The second identifier may be @ RequestParam or @ RequestBody.

If the code annotations corresponding to all classes in the target program code do not include the annotation information identified by the first identifier, whether each class is labeled in the Controller method or not is judged. If the first type is marked in the Controller method, the @ RequestParam or the @ RequestBody of the Controller method is acquired. Wherein, for @ RequestParam, an entity structure defining a request class is generally displayed in this way, and therefore, a parameter of the @ RequestParam label can be determined as a request field. For @ RequestBody, the parameter annotated by @ RequestBody may be determined as a request class by obtaining a field in the request class and determining the obtained field as a request field.

In this way, if the code annotation corresponding to the first class includes the preset method in the multiple classes, the annotation information identified by the second identifier in the preset method entry can be acquired, and the field in the annotation information identified by the second identifier is determined as the request field, so that the request field can be acquired in various scenes, and the reliability of acquiring the request field is improved.

For example, when the return field is determined, multiple classes in the target program code may be obtained, and for each class, it is determined whether a code note corresponding to the class includes note information identified by a third identifier, and if the code note corresponding to the class includes the note information identified by the third identifier, it is determined whether a preset class exists in the note information identified by the third identifier; and if the preset class exists, determining the field in the preset class as a return field.

If the preset class does not exist in the annotation information identified by all the third identifiers, matching the class names of all the classes according to the preset rule; if the matching is successful, determining the fields in the successfully matched class as return fields; if the matching fails, acquiring a second class of the annotation information with the first identifier identification in all the classes, determining a request class in the second class according to the annotation information identified by the first identifier, acquiring an interface identification corresponding to the request class, determining an unsolicited class in the second class according to the annotation information identified by the first identifier, and determining a field in the unsolicited class, in which the interface identification corresponding to the unsolicited class is the same as the interface identification corresponding to the request class, as a return field.

The third identifier may be @ ResponseClass at the same level as @ Message, and this manner may be used for a scenario where the return parameter has a general type, and is used to define a specific return implementation class for a developer. The preset Class may include a specified Class (Class).

Scanning the target program code can obtain all classes in the target program code. For each class, judging whether the code annotation corresponding to the class comprises @ ResponseClass annotation information of the same level as the @ Message, if the code annotation corresponding to a certain class comprises the @ ResponseClass annotation information, judging whether a specified class exists in the annotation information of the class, if the specified class exists, determining the specified class in the @ ResponseClass parameter as a return class, and determining a field included in the return class as a return field.

In this manner, when it is determined that the code annotation corresponding to a certain class includes annotation information identified by the third identifier, and the annotation information includes a preset class, a field in the preset class may be determined as a return field, so that efficiency of determining the return field may be improved.

Further, if there is no preset class in the annotation information identified by the third identifier in all classes, that is, there is no specified class, the class names of all classes are matched according to the preset rule. The preset rule may be matching the class names of all classes and the class name of the returned class. If the class name of a certain class is Req xxx, the class is matched with Rsp xxx or Resp xxx from all classes corresponding to the target program code, if the matching is successful, the successfully matched class is determined as a return class, and a field in the return class is determined as a return field. And if the matching fails, acquiring the class with the @ message annotation information from all classes corresponding to the target program code. Since information such as an interface Identification (ID), an interface name, description information of the interface, and whether a class is requested or not is maintained in the @ Message annotation information. Therefore, according to the obtained @ message annotation information, the request class in the classes and the interface Identification (ID) corresponding to the request class can be determined. In addition, according to the obtained @ message annotation information, the unsolicited classes in the classes and the interface Identifiers (IDs) corresponding to the unsolicited classes can be determined. The terminal device may determine, as the return class, a class in the unsolicited class in which the interface Identifier (ID) is the same as the interface Identifier (ID) corresponding to the solicited class, and therefore, it may be understood that the determined return class is part or all of the unsolicited class. After the return class is determined, the fields in the return class may be determined to be return fields.

It should be noted that if all classes in the target program code do not include @ ResponseClass annotation information, a prompt message may be output to remind the developer to add @ message annotation information according to a preset rule or a return field, and designate it as a return field. Wherein the prompt information is output when the Gradle command generation interface document is executed.

In this mode, when no preset class exists in the annotation information identified by the third identifier, the class names of all classes can be matched according to the preset rule, so that the return class is determined, and the field in the return class is determined as the return field, so that the return field can be acquired in various scenes, and the reliability of acquiring the return field is improved.

Step 204: and respectively acquiring field names and field types corresponding to the request field and the return field through a Java reflection mechanism.

The Java reflection mechanism can determine all attributes and methods of any class in the program running state, and can call any method and attribute of any object. Therefore, after the terminal device determines the request field and the return field, the terminal device may obtain the field name and the field type corresponding to each of the request field and the return field through a Java reflection mechanism.

It can be understood that, in the current way of generating the interface document by using the Swagger tool, the protocol description field is strongly associated with the annotation information, that is, a developer is required to mark all the fields with the annotation information to obtain the field name and the field type, so as to generate the interface document. In contrast, in the embodiment of the application, the field name and the field type of the field can be acquired through the Java reflection mechanism without depending on annotation information to generate the interface document, so that not only can the flexibility and the compatibility of generation of the interface document be improved, but also the working efficiency of developers can be improved, and the development difficulty can be reduced.

Step 205: and generating an interface document corresponding to the target program code according to the field name and the field type corresponding to the request field and the return field respectively.

In this step, a preset template corresponding to the interface document may be predefined, for example, the preset template may be understood as a document description object ProtoInfo. Fig. 3 is a schematic structural diagram of an interface document, and as shown in fig. 3, the document description object ProtoInfo includes an interface identifier, an interface name, description information of the interface, a request field list, and a return field list. In addition, a document field description object ProtoFieldInfo may be defined to maintain a request field and a return field, where the ProtoFieldInfo includes a field ID, a field name, a field type, field description information, and a value range.

For example, in order to facilitate the use of developers and distinguish the interface document, interface information, such as at least one of the above-mentioned interface identifier, interface name and interface description information, is usually included in the interface document. For example, interface information corresponding to the target program code may be obtained according to code annotations corresponding to multiple classes in the target program code, and the interface information may be added to the interface document.

Specifically, after the target program code is scanned and all classes in the target program code are determined, if annotation information identified by a first identifier exists in a certain class and the class belongs to a request class, annotation instance content in the annotation information identified by the first identifier may be imported into a preset template for maintaining interface information. The first identifier is @ Message, which is an annotation for classes and methods, and which maintains an interface Identification (ID), an interface name, and interface description information, and whether or not to request a class.

As shown in fig. 3, the comment instance content of @ Message may be converted into a ProtoInfo object, that is, the interface Identification (ID), the interface name and the description information of the interface maintained in @ Message are filled into the ID, name and description fields in the ProtoInfo object in fig. 3 for maintaining the interface information.

If the code annotations corresponding to all classes in the target program code do not include the annotation information identified by the first identifier, whether each class is labeled in the Controller method or not is judged. If a first class is marked in a Controller method, and a Web related annotation carried by Spring is obtained from the first class, for example, a method marked with Mapping annotations such as @ RestController or @ RequestMapping in the first class is obtained, and the method is used as interface information, and for example, the method has annotation information marked with @ Message, the content in the obtained annotation information of @ Message is imported into a preset template, that is, the content in the annotation information of @ Message is filled into interface ID, name and description fields in the ProtoInfo object shown in fig. 3, so as to be used for maintaining the interface information. If the method does not mark the annotation information of @ Message, a Uniform Resource Locator (URL) in the annotation information such as @ RestController or @ RequestMapping is obtained and is filled into the interface ID in the Protolfo object shown in FIG. 3.

It should be noted that, the class is labeled in the Controller method, so that the Web-related interface can automatically obtain the URL configured in the annotation information and import the URL into the preset template. If the @ Message does not support the annotation to the method, the developer needs to add description or field name, etc. to the request field to manually maintain the requested URL.

In the embodiment, the interface information corresponding to the target program code is obtained and is imported into the preset template, so that the interface document is more complete, the interface documents of different interfaces can be effectively distinguished, the use of developers is facilitated, and the user experience is improved.

In addition, the preset template also comprises the relevant information of the request field and the relevant information of the return field. Therefore, after determining the field names and the field types corresponding to the request field and the return field, the terminal device may import the field names and the field types corresponding to the request field and the return field into a preset template, thereby generating the interface document.

Illustratively, when the interface document corresponding to the target program code is generated according to the field name and the field type corresponding to the request field and the return field, the following steps may be performed: judging whether the field type of the field is a common data type or not aiming at any field in the request field and the return field, if the field type of the field is not the common data type, determining the sub-field included in the field according to the field type of the field, acquiring the field name and the field type corresponding to the sub-field, determining the sub-field as a new field, and repeatedly executing the step until the field type of the field is the common data type; and then generating an interface document corresponding to the target program code according to the field name and the field type of the field and the field name and the field type of the subfield corresponding to the field.

For example, when generating an interface document corresponding to an object program code, the interface document may be generated by obtaining a preset template corresponding to the object program code, determining a hierarchical relationship between all fields and all subfields, and then importing the field names and field types of the fields and the field names and field types of the subfields corresponding to the fields into the preset template according to the hierarchical relationship.

Specifically, for example, to reduce useless information in the interface document and improve the usability of the interface document, after the request fields are obtained, the request fields having static and final identifications or being marked as obsolete (@ delete) or ignored (@ json ignore) may be removed from all the request fields. In the remaining request fields, for each remaining request field, the field name and field type of each request field may be obtained through a Java reflection mechanism. The terminal equipment judges whether the field type of each request field is a common data type, and if the field type of a certain request field is the common data type, the field name and the field type of the request field are directly imported into a preset template. The common data types may include string, char, int, float, and the like.

If the field type of a certain request field is judged not to be a common data type, the sub-field included in the request field can be determined according to the field type of the field. For example, if the field type of the request field is a class, the field included in the class may be acquired, and the field included in the class is determined as a subfield, then the field name and the field type of the subfield are acquired through a Java reflection mechanism, and it is determined whether the field type of the subfield is a normal data type, and if the field type is a normal data type, the field name and the field type of the request field, and the field name and the field type of the subfield are imported into a preset template according to a hierarchical relationship, thereby generating the interface document. If the field type of the sub-field is not the normal data type and the field type of the sub-field is the class, repeating the above steps, continuing to acquire the field in the class, and so on until the acquired field type is the normal data type.

And the terminal equipment determines the hierarchical relationship according to each request field and all the subfields. For example, if the request field is User, and the subfields corresponding to the request field are Name and MobileNumber, the User is the first level, and the Name and MobileNumber are the second level. After the hierarchical relationship is determined, the field name and the field type of the request field and the field name and the field type of the sub-field of each hierarchy may be imported into a preset template according to the hierarchical relationship to generate an interface document.

If the field type of the request field is a list or an array, acquiring the actual type of the list or the array, and if the actual type belongs to the basic data type, directly importing the name and the actual type of the list or the array into a preset template to generate an interface document. If the actual type does not belong to the basic data type, the field included in the list or the array is acquired as the subfield, the field name and the field type of the subfield are acquired through a Java reflection mechanism, whether the field type of the subfield is a common data type or not is judged, and if the field type of the subfield is the common data type, the field name and the field type of the request field and the field name and the field type of the subfield are imported into a preset template according to a hierarchical relationship, so that the interface document is generated. If the field type of the sub-field is not the normal data type, determining the field included in the sub-field according to the field type of the sub-field, for example, if the field type of the sub-field is a class, acquiring the field included in the class, if the field type of the sub-field is an array or a list, repeating the above steps, and so on until the acquired field type is the normal data type.

And the terminal equipment determines the hierarchical relationship according to each request field and all the subfields. And then importing the field name and the field type of the request field and the field name and the field type of the sub-field of each hierarchy into a preset template according to the hierarchy relationship to generate the interface document.

For example, if the field type of the request field is List and List < String >, and the actual type of the List is String, which is the basic data type, the sub-fields of the List will not be continuously obtained, but the field names and the actual types of the List are directly imported into the preset template to generate the interface document. Assuming that the List is List < User >, the actual type of the List is User, which is not the basic data type, and therefore, the traversal is continued to determine the sub-fields in User and to determine the field names and field types of the sub-fields in User.

If the field type of the request field is generic or an entity class expressed in generic, the actual type of the declared generic can be obtained through a Java reflection mechanism. Specifically, the declared Actual Type of the parent class can be obtained by the get Actual Type definitions method of the parent class, and if the declared Actual Type of the parent class cannot be obtained, the Actual Type of the corresponding field is obtained from the class in the inheritance chain in a recursive manner. And after the actual type is obtained, judging whether the actual type belongs to the basic data type, and if the actual type belongs to the basic data type, directly importing the field name and the actual type of the request field into a preset template to generate an interface document. If the actual type does not belong to the basic data type, the field included in the entity class which is expressed by the generic type or the generic type is acquired as the sub-field, the field name and the field type of the sub-field are acquired through a Java reflection mechanism, whether the field type of the sub-field is the common data type or not is judged, if the field type is the common data type, the field name and the field type of the request field, and the field name and the field type of the sub-field are imported into a preset template according to the hierarchical relationship, and therefore the interface document is generated. If the field type of the sub-field is not the normal data type, determining the fields included in the sub-field according to the field type of the sub-field in the recursive manner, for example, determining the sub-field according to the foregoing manner according to the fact that the field type of the sub-field is a class, an array, a list, a generic type or a generic type, and repeating the above steps, and so on, until the obtained field type is the normal data type.

It should be noted that, when the field type of the request field is an Object type, the same processing manner as the generic type may be adopted, and details are not described here.

In addition, in the foregoing description, if the actual type of the corresponding field is still not obtained from the class in the inheritance chain in a recursive manner, prompt information is added to the description information of the interface document to remind the developer to supplement the actual type of the declaration generalization.

Further, for the return field, the field name and the field type of the return field are determined, and a manner of importing the field name and the field type into a preset template to generate an interface document is similar to that of the request field, and reference may be specifically made to the foregoing description, and details are not repeated in this embodiment of the application.

For example, as shown in table 1 below, the related information of the request field list ProtoFieldInfo in fig. 3, and table 2, the related information of the return field list ProtoFieldInfo in fig. 3.

TABLE 1

Field ID	Type of field	Name of field	Field description	Value range
					1	String	Token	Token	Non-empty, length 32

TABLE 2

As shown in table 1, if the request field acquired by the terminal device is Token and the field type is String, the field name Token and the field type String of the request field may be directly imported into the preset template.

As shown in table 2, the return fields obtained by the terminal device are User and cars, where the field type of User is Object, and the terminal device will continue to traverse the subfields in Object, such as Name and Mobile Number, and determine the field types of Name and Mobile Number according to the Java reflection mechanism, and because both the field types of Name and Mobile Number are String, the field names and field types of User, Name and Mobile Number will be imported into the preset template according to the hierarchical relationship. In addition, if the field type of the Cards is List, the terminal device will continue to traverse the sub-fields in the List, such as Bank Name and Card Number, and determine the field types of the Bank Name and the Card Number according to the Java reflection mechanism, and since the field types of the Bank Name and the Card Number are both String, the field names and the field types of the Cards, the Bank Name and the Card Number will be imported into the preset template according to the hierarchical relationship to generate the interface document.

It should be understood that the above-mentioned hierarchical relationship may be exhibited in the field IDs as shown in table 2, for example, the field IDs of User and Cards are 1 and 2, respectively, the field IDs of the sub-fields Name and Mobile Number corresponding to User are 1.1 and 1.2, respectively, and the field IDs of the sub-fields Bank Name and Card Number corresponding to Cards are 2.1 and 2.2, respectively.

In this embodiment, for any field in the request field and the return field, when the field type of the field is determined to be a common data type, the sub-field included in the field may be determined continuously according to the field type of the field to obtain the field name and the field type of the sub-field, and all the fields are submitted and traversed according to the method until the finally obtained field type is the basic data type, so that the interface document is generated according to the field name and the field type of the field and the field name and the field type of the sub-field, and therefore, when the field does not have the label information, the interface document may also be generated, thereby not only improving the flexibility and efficiency of generating the interface document, but also reducing the workload and the development difficulty of developers.

Further, the interface document corresponding to the target program code is generated by acquiring a preset template corresponding to the target program code, determining the hierarchical relationship among all the fields and the sub-fields, and then importing the field name and the field type of the fields and the field name and the field type of the sub-fields into the preset template according to the determined hierarchical relationship, so that the generation efficiency and the accuracy of the interface document can be improved.

In addition, for the convenience of the developer, the value range of some fields also needs to be defined in the interface document. Illustratively, if the field includes annotation information related to parameter verification, an attribute value in the annotation information related to parameter verification is acquired, the attribute value is determined as value description information of the field, and a corresponding relationship between the field and the value description information is added to the interface document.

Specifically, when the request field and the return field are traversed, if some field contains annotation information related to parameter verification, an attribute value of the annotation information is acquired, the attribute value is converted into description information, and the description information is added to the interface document. For example, the attribute value may be added to the description information of the value range in table 1 or table 2, such as that the value range corresponding to the User is non-empty, the value range corresponding to the Name is 2-10 in length, and the like.

In the method, if the field comprises the annotation information related to the parameter verification, the attribute value in the annotation information related to the parameter verification is obtained, the attribute value is determined as the value description information of the field, and the value description information is added into the interface document, so that the interface document is more complete, the use of developers is facilitated, and the user experience is improved.

In addition, since the @ Field is an annotation acting on a Field attribute, and description information of a Field identifier, a Field name and a Field is maintained in the @ Field annotation information, the @ Field annotation information on the Field can also be acquired during the process of passing the Field, if the @ Field annotation information exists in a certain Field, the description information of the Field is determined according to the @ Field annotation information, and the description information is imported into a preset template, for example, the description information corresponding to Token can be filled into the Field description in table 1 or table 2, and the description information corresponding to User can be a User.

As can be seen from the above description, in the embodiment of the present application, since the Java reflection mechanism is used, even though the attribute description annotation information is not labeled, it can be ensured that information such as the field type, the field name, and the value range is imported into the preset template, so as to generate the interface document.

Furthermore, in order to facilitate the calling of developers, when generating the interface document, the Java file corresponding to the POJO can be generated according to the request field and the return field, and the Java file corresponding to the POJO is sent to the cloud server.

Specifically, when the interface document is generated, the Java file corresponding to the POJO is generated according to the contents of the request field and the return field, and in the generation process, the original annotation information in the target program code is usually deleted, and the description information is modified into an annotation mode.

Further, the terminal device uploads the generated Java file and interface document corresponding to the POJO to the cloud server. In addition, a developer can provide a specific interface link for a user, so that the user can directly download the Java file corresponding to the POJO from the cloud server according to the interface link so as to apply the Java file to the code. Therefore, the unification of the interface document and the code can be realized, and the problem that the interface code in the software system development process cannot be kept consistent is solved.

In addition, because the uniform document description object is defined, local interface documents in various formats, such as local interface documents in Excel, Mardown, Html and the like, can be generated on the basis of the uniform document description object, so that the scheme for generating the interface documents can be switched gradually by developers conveniently.

According to the interface document generation method provided by the embodiment of the application, after a generation request for generating an interface document is received, an object program code is determined according to the generation request, then a request field and a return field are respectively determined according to the object program code, field names and field types corresponding to the request field and the return field are respectively obtained through a Java reflection mechanism, and then the interface document corresponding to the object program code is generated according to the field names and the field types corresponding to the request field and the return field. On one hand, the phenomenon that a user manually writes the interface document can be avoided, so that the generation efficiency of the interface document can be improved, and the development cost of a software system can be reduced. On the other hand, through a Java reflection mechanism, the field names and the field types corresponding to the request field and the return field can be obtained through deep traversal of the fields, and the generation of the interface document under various scenes such as extensive types, lists, object nesting and the like can be supported, so that the interface document can be generated even when annotation information does not exist in some fields, the manual intervention cost can be greatly reduced, and the phenomenon that the interface document needs to be strongly dependent on the annotation information when being generated is avoided.

Fig. 4 is a schematic structural diagram of an interface document generating apparatus 40 according to an embodiment of the present application, and for example, please refer to fig. 4, the interface document generating apparatus 40 may include:

a receiving unit 401, configured to receive a generation request for generating an interface document.

And the processing unit 402 is configured to determine an object program code according to the generation request, and determine a request field and a return field according to the object program code.

An obtaining unit 403, configured to obtain, through a Java reflection mechanism, a field name and a field type corresponding to each of the request field and the return field.

And a generating unit 404, configured to generate an interface document corresponding to the target program code according to the field name and the field type corresponding to each of the request field and the return field.

Optionally, the generating unit 404 is specifically configured to determine, for any one of the request field and the return field, whether the field type of the field is a normal data type, if the field type of the field is not a normal data type, determine a subfield included in the field according to the field type of the field, acquire a field name and a field type corresponding to the subfield, determine the subfield as a new field, and repeatedly perform this step until the field type of the field is a normal data type; and generating an interface document corresponding to the target program code according to the field name and the field type of the field and the field name and the field type of the subfield corresponding to the field.

Optionally, the generating unit 404 is specifically configured to obtain a preset template corresponding to the target program code; determining a hierarchical relationship between all fields and all subfields; and importing the field name and the field type of the field and the field name and the field type of the sub-field corresponding to the field into a preset template according to the hierarchical relationship to generate an interface document.

Optionally, the processing unit 402 is specifically configured to obtain multiple classes in the target program code; for each class, if the code annotation corresponding to the class comprises annotation information identified by the first identifier, and the class is determined to be the request class according to the annotation information identified by the first identifier, determining a field in the request class to be the request field.

Optionally, the processing unit 402 is further configured to determine whether the code annotations corresponding to each of the multiple classes include a preset method if the code annotations corresponding to each of the multiple classes do not include annotation information identified by the first identifier.

The obtaining unit 403 is further configured to, if there is a preset method included in the code annotation corresponding to the first class in the multiple classes, obtain annotation information identified by the second identifier in the preset method entry.

The processing unit 402 is further configured to determine a field in the annotation information identified by the second identifier as the request field.

Optionally, the processing unit 402 is specifically configured to obtain multiple classes in the target program code; judging whether the code annotation corresponding to the class comprises annotation information identified by the third identifier or not for each class; if the code annotation corresponding to the class comprises annotation information identified by the third identifier, judging whether a preset class exists in the annotation information identified by the third identifier; and if the preset class exists, determining the field in the preset class as a return field.

Optionally, the processing unit 402 is further configured to, if no preset class exists in the annotation information identified by all the third identifiers, match class names of all classes according to a preset rule; if the matching is successful, determining the fields in the successfully matched class as return fields; if the matching fails, acquiring a second class of the annotation information with the first identifier identification in all the classes, determining a request class in the second class according to the annotation information identified by the first identifier, acquiring an interface identification corresponding to the request class, determining an unsolicited class in the second class according to the annotation information identified by the first identifier, and determining a field in the unsolicited class, in which the interface identification corresponding to the unsolicited class is the same as the interface identification corresponding to the request class, as a return field.

Optionally, the obtaining unit 403 is further configured to obtain, according to the code annotation corresponding to the multiple classes in the target program code, interface information corresponding to the target program code, where the interface information includes at least one of an interface identifier, an interface name, and interface description information.

The processing unit 402 is further configured to add the interface information to the interface document.

Optionally, the obtaining unit 403 is further configured to obtain an attribute value in the annotation information related to parameter verification if the field includes annotation information related to parameter verification.

The processing unit 402 is further configured to determine the attribute value as value description information of the field, and add a corresponding relationship between the field and the value description information in the interface document.

Optionally, the interface document generating apparatus 40 further includes a sending unit 405.

The generating unit 404 is further configured to generate a Java file corresponding to the simple Java object POJO according to the request field and the return field.

A sending unit 405, configured to send the Java file corresponding to the POJO to the cloud server.

The interface document generation apparatus 40 provided in this embodiment of the present application may execute the technical solution of the interface document generation method in any embodiment described above, and the implementation principle and the beneficial effect of the interface document generation method are similar to those of the interface document generation method, which can be referred to as the implementation principle and the beneficial effect of the interface document generation method, and are not described herein again.

Fig. 5 is a schematic structural diagram of a terminal device 50 according to an embodiment of the present application, for example, please refer to fig. 5, where the terminal device may include a processor 501 and a memory 502; wherein the content of the first and second substances,

the memory 502 is used for storing computer programs.

The processor 501 is configured to read the computer program stored in the memory 502, and execute the technical solution of the interface document generating method in any of the embodiments according to the computer program in the memory 502.

Alternatively, the memory 502 may be separate or integrated with the processor 501. When the memory 502 is a device separate from the processor 501, the terminal device may further include: a bus for connecting the memory 502 and the processor 501.

Optionally, this embodiment further includes: a communication interface that may be connected to the processor 501 through a bus. The processor 501 may control the communication interface to implement the above-described functions of acquisition and transmission of the terminal device.

The terminal device shown in the embodiment of the present application may execute the technical solution of the interface document generation method in any embodiment, and the implementation principle and the beneficial effect of the terminal device are similar to those of the interface document generation method, which can be referred to as the implementation principle and the beneficial effect of the interface document generation method, and are not described herein again.

An embodiment of the present application further provides a computer-readable storage medium, where a computer execution instruction is stored in the computer-readable storage medium, and when a processor executes the computer execution instruction, the technical solution for implementing the interface document generation method in any of the above embodiments is implemented, and implementation principles and beneficial effects of the technical solution are similar to those of the interface document generation method, and reference may be made to the implementation principles and beneficial effects of the interface document generation method, which is not described herein again.

The embodiment of the present application further provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the technical solution of the interface document generation method in any of the above embodiments is implemented, and the implementation principle and the beneficial effect of the computer program are similar to those of the interface document generation method, which can be referred to as the implementation principle and the beneficial effect of the interface document generation method, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts shown as units may or may not be physical units, may be located in one position, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment. In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, or in a form of hardware plus a software functional unit.

The integrated module implemented in the form of a software functional module may be stored in a computer-readable storage medium. The software functional module is stored in a storage medium and includes several instructions to enable a computer device (which may be a personal computer, a server, or a network device) or a processor (processor) to execute some steps of the methods according to the embodiments of the present application.

It should be understood that the Processor may be a Central Processing Unit (CPU), other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in the incorporated application may be directly implemented by a hardware processor, or may be implemented by a combination of hardware and software modules in the processor.

The memory may comprise a high-speed RAM memory, and may further comprise a non-volatile storage NVM, such as at least one disk memory, and may also be a usb disk, a removable hard disk, a read-only memory, a magnetic or optical disk, etc.

The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended ISA (EISA) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, the buses in the figures of the present application are not limited to only one bus or one type of bus.

The computer-readable storage medium may be implemented by any type or combination of volatile or non-volatile memory devices, such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disks. A storage media may be any available media that can be accessed by a general purpose or special purpose computer.

Finally, it should be noted that: the above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for generating an interface document, comprising:

receiving a generation request for generating an interface document;

determining a target program code according to the generation request;

respectively determining a request field and a return field according to the target program code;

respectively acquiring field names and field types corresponding to the request fields and the return fields through a Java reflection mechanism;

2. The method according to claim 1, wherein the generating an interface document corresponding to the target program code according to the field name and the field type corresponding to each of the request field and the return field comprises:

judging whether the field type of the field is a common data type or not aiming at any field in the request field and the return field, if the field type of the field is not the common data type, determining a sub-field included in the field according to the field type of the field, acquiring a field name and a field type corresponding to the sub-field, determining the sub-field as a new field, and repeatedly executing the step until the field type of the field is the common data type;

3. The method according to claim 2, wherein generating the interface document corresponding to the object program code according to the field name and the field type of the field and the field name and the field type of the sub-field corresponding to the field comprises:

acquiring a preset template corresponding to the target program code;

determining a hierarchical relationship between all fields and all subfields;

4. The method of any of claims 1-3, wherein determining a request field from the object program code comprises:

acquiring a plurality of classes in the target program code;

5. The method of claim 4, further comprising:

if the code annotation corresponding to each of the plurality of classes does not include the annotation information identified by the first identifier, judging whether the code annotation corresponding to each of the classes includes a preset method;

if the code annotation corresponding to the first type in the multiple types comprises a preset method, acquiring annotation information of a second identifier in the reference of the preset method;

6. The method of any of claims 1-3, wherein determining a return field from the object program code comprises:

acquiring a plurality of classes in the target program code;

judging whether the code annotation corresponding to each class comprises annotation information identified by a third identifier or not;

if the code annotation corresponding to the class comprises annotation information identified by a third identifier, judging whether a preset class exists in the annotation information identified by the third identifier;

7. The method of claim 6, further comprising:

if the preset class does not exist in the annotation information identified by all the third identifiers, matching the class names of all the classes according to a preset rule;

if the matching is successful, determining the fields in the successfully matched class as the return fields;

8. The method according to any one of claims 1-3, further comprising:

acquiring interface information corresponding to the target program code according to the code annotations corresponding to the multiple classes in the target program code, wherein the interface information comprises at least one of an interface identifier, an interface name and interface description information;

and adding the interface information into the interface document.

9. A method according to claim 2 or 3, characterized in that the method further comprises:

if the field comprises annotation information related to parameter verification, acquiring an attribute value in the annotation information related to parameter verification;

10. The method according to any one of claims 1-3, further comprising:

generating a Java file corresponding to a simple Java object POJO according to the request field and the return field;

and sending the Java file corresponding to the POJO to a cloud server.

11. An interface document generation apparatus, comprising:

a receiving unit configured to receive a generation request for generating an interface document;

the processing unit is used for determining a target program code according to the generation request and respectively determining a request field and a return field according to the target program code;

an obtaining unit, configured to obtain, through a Java reflection mechanism, a field name and a field type corresponding to the request field and the return field, respectively;

12. A terminal device comprising a processor and a memory; wherein the content of the first and second substances,

the memory for storing a computer program;

the processor is configured to read the computer program stored in the memory, and execute the interface document generation method according to any one of claims 1 to 10 according to the computer program in the memory.

13. A computer-readable storage medium, wherein computer-executable instructions are stored in the computer-readable storage medium, and when executed by a processor, implement the interface document generation method according to any one of claims 1 to 10.

14. A computer program product comprising a computer program, characterized in that the computer program, when being executed by a processor, carries out the method for generating an interface document according to any one of the preceding claims 1 to 10.