Interface metadata processing method, system, device, client and storage medium
By integrating the target plug-in into the business system, automatically acquiring and converting interface metadata and uploading it to the interface document platform, the problem of time-consuming communication between the front-end and back-end is solved, and unified management and efficient R&D of interface documents are achieved.
Patent Information
- Application Number
- CN202510846379.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-24
- Publication Date
- 2025-09-12
- Estimated Expiration
- 2045-06-24
AI Technical Summary
In the development model with separated front-end and back-end, communication and docking between the front-end and back-end are time-consuming, resulting in low R&D efficiency. Especially when multiple business systems are developed in parallel, front-end developers and testers need to be familiar with the personalized data formats of each system, which increases the learning cost.
By integrating the target plug-in into the business system, the interface metadata is automatically acquired and converted into a format supported by the target interface document platform, and uploaded to a centralized interface document platform (such as the Blade Platform) to generate interface documents in a unified format, reducing front-end and back-end communication.
It improves R&D efficiency, simplifies the management and maintenance of interface documents, enhances the accuracy and consistency of interface documents, and reduces learning and communication costs.
Smart Images

Figure CN120371302B_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of Internet technology, and more specifically, to a method, system, device, client, and storage medium for processing interface metadata in the field of Internet technology. Background Art
[0002] The development of business systems often employs a separate front-end and back-end development approach. Specifically, the back-end is responsible for logic development, writing specific functional logic and providing corresponding functional interfaces for the front-end to call. For example, back-end developers design the interfaces, and front-end developers use these interfaces to complete page data interaction and design. However, defining APIs (Application Programming Interfaces) and communicating and integrating the front-end and back-end is often extremely time-consuming, resulting in significantly low development efficiency for both front-end and back-end developers. Consequently, improving development efficiency during the development process has become a pressing technical challenge. Summary of the Invention
[0003] The present application provides a method, system, device, client, and storage medium for processing interface metadata, which can improve R&D efficiency during the R&D process.
[0004] In a first aspect, a method for processing interface metadata is provided, the method comprising: obtaining interface metadata of a target interface of a business system, and converting the data format of the interface metadata to obtain interface metadata in a target format; wherein the target format is a format supported by a target interface document platform; uploading the interface metadata in the target format to the target interface document platform, so that the target interface document platform generates a target interface document according to the interface metadata in the target format and displays the target interface document.
[0005] The above technical solution completes the acquisition, format conversion and upload of interface metadata locally on the client in an automated manner, reducing the communication costs between the front-end and back-end and improving R&D efficiency. Front-end developers and testers can work directly based on the target interface documents generated on the target interface document platform without the need for frequent communication and confirmation with back-end developers. The data received by the target interface document platform are all in the target format supported by the platform itself, so that front-end developers and testers only need to be familiar with a standard format, namely the target format, without having to spend extra time to understand the personalized data format of each business system. By introducing the target interface document platform and combining it with the local automation of the client to acquire, convert and upload the interface metadata of the target interface, the high communication cost and steep learning curve problems existing in the traditional front-end and back-end docking are effectively solved. This solution not only improves R&D efficiency, but also enhances the accuracy and consistency of interface documents, providing strong support for the development of enterprise-level applications.
[0006] In combination with the first aspect, in some possible implementations, before obtaining the interface metadata of the target interface of the business system and converting the data format of the interface metadata to obtain the interface metadata in the target format, the method also includes: integrating the target plug-in into the business system; obtaining the interface metadata of the target interface of the business system and converting the data format of the interface metadata to obtain the interface metadata in the target format, including: after the application corresponding to the business system is started, obtaining the interface metadata of the target interface of the business system by loading the target plug-in, and converting the data format of the interface metadata to obtain the interface metadata in the target format.
[0007] The above technical solution integrates a specific target plug-in into the business system in advance. By loading the target plug-in locally in the business system, the interface metadata acquisition and format conversion can be completed in the client's local environment. The localized processing makes full use of the existing resources of the business system. There is no need to deploy additional dedicated servers or services to handle the acquisition and conversion of interface metadata. It not only simplifies the interface metadata acquisition and format conversion process, but also reduces the implementation cost and is more friendly to the target interface document platform.
[0008] In combination with the first aspect and the above-mentioned implementation methods, in some possible implementation methods, integrating the target plug-in in the business system includes: accessing the software package corresponding to the target plug-in in the business system; wherein the software package includes attributes to be configured; obtaining configuration information for the attributes to be configured; and configuring the software package based on the configuration information to integrate the target plug-in in the business system.
[0009] The above technical solution integrates the target plug-in into the business system by accessing the software package corresponding to the target plug-in, obtaining the configuration information of the properties to be configured in the software, and configuring the software package based on the configuration information. This allows the target plug-in's behavior to be flexibly adjusted to meet different business needs without modifying the core code. This facilitates efficient integration of the target plug-in into the business system and flexible configuration of its behavior based on actual needs. This approach not only simplifies the target plug-in access process but also improves the flexibility and maintainability of the target plug-in during use.
[0010] In combination with the first aspect and the above-mentioned implementation methods, in some possible implementation methods, the attributes to be configured include an effectiveness attribute for describing whether the target plug-in is allowed to take effect in the business system; after the application corresponding to the business system is started, the target plug-in is loaded to obtain the interface metadata of the target interface of the business system, and the data format of the interface metadata is converted to obtain the interface metadata in the target format, including: after the application corresponding to the business system is started, whether the target plug-in is effective in the business system according to the effectiveness attribute is identified; when the target plug-in is effective, the target plug-in is loaded to obtain the interface metadata of the target interface of the business system, and the data format of the interface metadata is converted to obtain the interface metadata in the target format.
[0011] The above technical solution, when the target plug-in is identified as valid through the validity attribute, indicates that the target plug-in has been explicitly enabled. Only then will the target plug-in be loaded, interface metadata for the target interface of the business system obtained, and the data format of the interface metadata is converted to obtain interface metadata in the target format, avoiding unnecessary resource consumption and potential conflicts. The target plug-in can be easily enabled or disabled through simple configuration, allowing developers to quickly and flexibly adjust the behavior of the target plug-in according to different deployment environments.
[0012] In combination with the first aspect and the above-mentioned implementation methods, in some possible implementation methods, the software package includes a target function group; before the application corresponding to the business system is started, the method also includes: initializing the target function group to configure the target function group to: scan the interface under the specified package path after the application is started to obtain the interface scanning result, store the interface scanning result in the target function group, and name the target function group as the target name; after the application corresponding to the business system is started, by loading the target plug-in, obtaining the interface metadata of the target interface of the business system, including: after the application corresponding to the business system is started, loading the target plug-in to obtain the interface resource set of the business system; obtaining the target function group with the target name from the interface resource set, and obtaining the interface metadata of the target interface of the business system from the target function group.
[0013] In the above implementation, the target function group, as an independent functional unit, can be initialized and configured before application startup. Simply adjusting the configuration parameters allows adaptation to different needs. If new scan paths need to be added or changed, only the implementation of the target function group needs to be modified, without requiring large-scale changes to the entire business system. Assigning a specific target name to the target function group facilitates subsequent rapid location and search of the function group with the target name within the interface resource collection, as well as the extraction of interface metadata. This simplifies the acquisition process for target interface metadata and improves acquisition efficiency.
[0014] In combination with the first aspect and the above-mentioned implementation methods, in some possible implementation methods, converting the data format of the interface metadata to obtain interface metadata in a target format includes: parsing the interface metadata to determine the difference information between the format of the interface metadata and the target format supported by the target interface document platform; and converting the data format of the interface metadata based on the difference information to obtain interface metadata in the target format.
[0015] In the second aspect, an interface metadata processing system is provided, including: a client and a target interface document platform; the client is used to obtain the interface metadata of the target interface of the business system, and convert the data format of the interface metadata to obtain the interface metadata in the target format, and upload the interface metadata in the target format to the target interface document platform; wherein the target format is a format supported by the target interface document platform; the target interface document platform is used to generate a target interface document according to the interface metadata in the target format and display the target interface document.
[0016] In a third aspect, a device for processing interface metadata is provided, the device comprising: a data processing module for acquiring interface metadata of a target interface of a business system, and converting the data format of the interface metadata to obtain interface metadata in a target format; wherein the target format is a format supported by a target interface document platform; an upload module for uploading the interface metadata in the target format to the target interface document platform, so that the target interface document platform generates a target interface document based on the interface metadata in the target format and displays the target interface document.
[0017] In combination with the third aspect, in some possible implementations, the interface metadata processing device also includes: a plug-in integration module for integrating the target plug-in in the business system; the data processing module is specifically used to: after the application corresponding to the business system is started, obtain the interface metadata of the target interface of the business system by loading the target plug-in, and convert the data format of the interface metadata to obtain interface metadata in the target format.
[0018] In combination with the third aspect and the above-mentioned implementation methods, in some possible implementation methods, the plug-in integration module is specifically used to: access the software package corresponding to the target plug-in in the business system; wherein the software package includes attributes to be configured; obtain configuration information for the attributes to be configured; and configure the software package based on the configuration information to integrate the target plug-in in the business system.
[0019] In combination with the third aspect and the above-mentioned implementation methods, in some possible implementation methods, the attributes to be configured include an effectiveness attribute for describing whether the target plug-in is allowed to take effect in the business system; the data processing module is specifically used to: after the application corresponding to the business system is started, identify whether the target plug-in is effective in the business system according to the effectiveness attribute; when the target plug-in is effective, obtain the interface metadata of the target interface of the business system by loading the target plug-in, and convert the data format of the interface metadata to obtain the interface metadata in the target format.
[0020] In combination with the third aspect and the above-mentioned implementation methods, in some possible implementation methods, the software package includes a target function group; the data processing module is specifically used to: initialize the target function group to configure the target function group to: scan the interface under the specified package path after the application is started to obtain the interface scanning result, store the interface scanning result in the target function group, and name the target function group as the target name; after the application corresponding to the business system is started, load the target plug-in to obtain the interface resource set of the business system; obtain the target function group with the target name from the interface resource set, and obtain the interface metadata of the target interface of the business system from the target function group.
[0021] In combination with the third aspect and the above-mentioned implementation methods, in some possible implementation methods, the data processing module is specifically used to: parse the interface metadata, determine the difference information between the format of the interface metadata and the target format supported by the target interface document platform; and convert the data format of the interface metadata according to the difference information to obtain interface metadata in the target format.
[0022] In a fourth aspect, a client is provided, which includes: a memory for storing executable program code; a processor for calling and running the executable program code from the memory, so that the client executes the method in the above-mentioned first aspect or any possible implementation of the first aspect.
[0023] In a fifth aspect, a computer program product is provided, which includes: computer program code, which, when running on a computer, enables the computer to execute the method in the above-mentioned first aspect or any possible implementation of the first aspect.
[0024] In a sixth aspect, a computer-readable storage medium is provided, which stores a computer program code. When the computer program code runs on a computer, the computer executes the method in the above-mentioned first aspect or any possible implementation of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS
[0025] Figure 1 This is a schematic diagram of an application scenario of a method for processing interface metadata provided by an embodiment of the present application;
[0026] Figure 2 This is a schematic flow chart of a method for processing interface metadata provided in an embodiment of the present application;
[0027] Figure 3 This is an interactive diagram of a method for processing interface metadata provided by an embodiment of the present application;
[0028] Figure 4 This is a schematic diagram of a display interface provided by a blade platform according to an embodiment of the present application;
[0029] Figure 5 is a schematic diagram of an interface metadata processing system provided in an embodiment of the present application;
[0030] Figure 6 This is a schematic diagram of the structure of an interface metadata processing device provided in an embodiment of the present application;
[0031] Figure 7 This is a schematic diagram of the structure of a client provided in an embodiment of the present application. DETAILED DESCRIPTION
[0032] The following will clearly and thoroughly describe the technical solutions in this application in conjunction with the accompanying drawings. In the description of the embodiments of this application, unless otherwise specified, " / " means or, for example, A / B can mean A or B: "and / or" in the text is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more than two.
[0033] In the following, the terms "first" and "second" are used for descriptive purposes only and should not be understood to imply or suggest relative importance or implicitly indicate the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features.
[0034] To facilitate understanding of the embodiments of the present application, the following first introduces the technical terms involved in the embodiments of the present application:
[0035] Interface documentation: Focusing on API documentation in the team collaborative development process can improve software development efficiency and ensure software quality.
[0036] API interface: Application programming interface is a set of predefined functions that aims to provide applications and developers with the ability to access a set of routines based on certain software or hardware without having to access the source code or understand the details of the internal working mechanism.
[0037] Swagger: An open source API documentation solution that automatically generates detailed API documentation based on comments or configuration files in the code. The API documentation includes information such as the request method, parameters, and response type of each API.
[0038] Blade Platform: It is mainly used to generate and manage API interface definitions of different branches or versions. It can generate interface documents in a specific format and is an interface document generation platform. It can help developers maintain multiple versions of API definitions in different development stages (such as development, testing, and production), and ensure that these definitions can accurately reflect the specific implementation of each version. Developers can access the Blade Platform through simple plug-ins without making intrusive modifications to existing code. The Blade Platform supports seamless integration with the deployment process of Aone (continuous integration and continuous delivery platform), and also supports local builds, and these build results will be synchronized to the Blade Platform in real time. This ensures that the status of the development environment and the Blade Platform are always consistent, which is convenient for debugging and verification.
[0039] Through research, this application has found that in the process of research and development of business systems, a development method with separated front-end and back-end is often adopted. Specifically, the back-end is responsible for logic development, writing specific functional logic, and providing corresponding functional interfaces for the front-end to call. For example, the back-end R&D personnel design the API interface and describe these interfaces through interface documents. The front-end R&D personnel need to perform data interaction and design of the page according to these interface documents. However, due to the lack of unified standards and tool support, the communication and docking between the front-end and back-end become very time-consuming, resulting in low overall R&D efficiency. In addition, in large-scale enterprise-level applications, there are usually multiple business systems developed in parallel, and each system has its own interface specifications and document formats. This decentralized management method increases the learning cost of front-end developers and testers because they need to be familiar with the personalized data format of each business system, which further affects the efficiency of development. Based on this, how to improve R&D efficiency during the R&D process has become a technical problem that needs to be solved urgently.
[0040] Considering that backend developers are generally very familiar with Swagger, and frontend developers are generally familiar with Blade Platform, Blade Platform can generate a lot of business code at the frontend interface level. Furthermore, Blade Platform may be connected to multiple business systems. If the interface documentation of different business systems can be centrally managed and maintained on Blade Platform, the efficiency of frontend and backend development will be greatly improved.
[0041] Based on this, an embodiment of the present application provides a method for processing interface metadata, including: a client obtaining interface metadata of a target interface from a business system; performing local format conversion on the obtained interface metadata, converting it into a target format supported by a target interface document platform (such as the Blade Platform); this format conversion is transparent and automated, reducing the possibility of manual intervention; and automatically uploading the converted interface metadata in the target format to the Blade Platform. As a centralized interface document management platform, the Blade Platform can receive interface metadata from different clients and generate target interface documents in a unified format. The Blade Platform automatically generates the target interface documents based on the received interface metadata and provides a user interface for front-end developers and testers to review and use. The Blade Platform can connect to multiple business systems, and all interface documents are centrally managed and maintained on the Blade Platform. This not only improves the consistency and accuracy of interface documents but also simplifies the workflow for front-end developers and testers. Even if the original interface metadata formats of different business systems vary, the converted interface documents displayed on the Blade Platform follow the same standardized format, lowering the learning and usage barriers and thus improving R&D efficiency.
[0042] Figure 1 This is a schematic diagram of an application scenario of a method for processing interface metadata provided in an embodiment of the present application.
[0043] For example, Figure 1 As shown, the application scenario includes a client 101 and a target interface document platform 102 .
[0044] Client 101 actually refers to the server or backend system, acting as a client to the target interface document platform 102. In a typical front-end / back-end separation architecture, the backend (server) is responsible for processing business logic, providing API interfaces, and generating interface metadata. The frontend then calls these API interfaces for data exchange and page display. To improve the efficiency of front-end / backend collaboration, this embodiment introduces the target interface document platform 102 as a unified interface document management tool.
[0045] The client 101 runs a business system, which is a specific business logic module or service collection running on the client 101. The business system implements specific API interfaces for front-end applications to call. Each API interface has corresponding metadata that describes its function and usage.
[0046] The target interface document platform 102 can be understood as a centralized interface document management platform, which is responsible for generating and displaying interface documents in a unified format. The target interface document platform 102 can be the aforementioned Blade platform.
[0047] Exemplarily, the client 101 includes n clients, where n is greater than or equal to 1, that is, the target interface document platform 102 can access multiple clients, and each client runs its own business system. Relative to the target interface document platform 102, these clients are all data providers. The target interface document platform 102 is a centralized interface document management platform for receiving interface metadata in a target format from each client and generating a target interface document in a unified format, so that the target interface document platform 102 can uniformly manage and maintain interface documents of multiple business systems. Each client can extract interface metadata from its internal business system, convert it into a format supported by the target interface document platform, and then upload it to the target interface document platform 102. In this way, the target interface document platform 102 can not only receive data from multiple clients, but also generate interface documents in a unified format, greatly improving the efficiency and quality of front-end and back-end collaboration.
[0048] Figure 2 This is a schematic flowchart of a method for processing interface metadata provided in an embodiment of the present application.
[0049] For example, Figure 2 As shown, the interface metadata processing method can be applied to Figure 1 For any one of the clients, the method includes:
[0050] Step 201: Acquire the interface metadata of the target interface of the business system, and convert the data format of the interface metadata to obtain the interface metadata in the target format; wherein the target format is a format supported by the target interface document platform.
[0051] Step 202: Upload the interface metadata in the target format to the target interface document platform, so that the target interface document platform generates a target interface document according to the interface metadata in the target format and displays the target interface document.
[0052] exist Figure 2In the embodiment shown, the acquisition, format conversion and upload of interface metadata are completed locally on the client in an automated manner, which reduces the communication cost between the front and back ends and improves R&D efficiency. Front-end developers and testers can work directly based on the target interface document generated on the target interface document platform without the need to frequently communicate and confirm with back-end developers. The format of the data received by the target interface document platform is the target format supported by itself, so that front-end developers and testers only need to be familiar with a standard format, namely the target format, without having to spend extra time to understand the personalized data format of each business system. This application effectively solves the problems of high communication cost and steep learning curve in traditional front-end and back-end docking by introducing the target interface document platform and combining it with the local automation of the client to acquire, convert and upload the interface metadata of the target interface. This solution not only improves R&D efficiency, but also enhances the accuracy and consistency of interface documents, providing strong support for the development of enterprise-level applications.
[0053] Below Figure 2 The specific implementation of each step in the embodiment is described below:
[0054] In step 201, the client first obtains the interface metadata of the target interface from its internal business system. The target interface is an API interface involved in front-end and back-end interaction. Specifically, it refers to an API interface designed specifically for front-end and back-end interaction. It is the functional point exposed by the back-end service to the outside world and the main entry point for the front-end application to call the back-end service.
[0055] It is understandable that in a business system, interfaces are not limited to target interfaces involving front-end and back-end interactions, and there are many other types of interfaces. These interfaces can be divided into different categories according to their purpose and usage scenarios, such as interfaces for exchanging data with other third-party systems or partners, interfaces for managing and monitoring business systems, which are usually used by operation and maintenance personnel or administrators, and interfaces designed specifically for testing purposes to verify system functions or performance, etc. Although there are many types of interfaces in a business system, this embodiment pays special attention to target interfaces designed specifically for front-end and back-end interactions. These interfaces are the core link for front-end and back-end collaboration, and are responsible for transferring data and functions between the two. The interface metadata of the target interface is obtained, and after format conversion, it is uploaded to the target interface document platform. Front-end and back-end developers do not need to communicate frequently to confirm interface details. The detailed interface metadata information of the target interface has been centrally displayed on the target interface document platform, which is conducive to improving the efficiency of front-end and back-end research and development.
[0056] The interface metadata of the target interface includes information such as the interface name, request path, request method, parameter type, and response format. The interface name is the unique identifier of the interface, usually a meaningful name given to the interface by the developer. The request path is the URL (Uniform Resource Locator) address of the interface, which is used to specify the access path of the interface. The request method refers to the HTTP method supported by the interface, such as GET, POST, PUT, DELETE, etc. The parameter type refers to the input parameters required by the interface and their data types (such as string, integer, Boolean value, etc.), as well as whether they are required. The response format is the data format returned by the interface, usually JSON or XML, including field names, field types, and their meanings. The error code and description refer to the error codes that may be returned by the interface and their corresponding meanings, which facilitate the front-end to handle abnormal situations.
[0057] In some embodiments, the interface metadata of an interface in a business system is Swagger interface metadata generated using a Swagger tool. Interface metadata refers to a detailed description of an API interface, including information such as the interface name, request path, request method, parameter types, and response format. Swagger interface metadata refers to interface metadata generated using a Swagger tool and expressed in JSON data format.
[0058] The Swagger tool can be integrated into the business system. The Swagger tool can automatically generate detailed Swagger interface documentation and describe the structure and functions of the API in a standardized format. The Swagger tool can be used to generate Swagger interface metadata for each interface in the business system. The Swagger tool can be understood as a Swagger native documentation service integrated into the business system, or as a Swagger native plug-in. The target plug-in in this embodiment can be understood as a new plug-in designed based on the Swagger native plug-in.
[0059] For example, a Swagger interface document typically contains interface metadata for multiple interfaces, but not all interfaces are target interfaces (i.e., interfaces involving front-end and back-end interaction). Therefore, obtaining the interface metadata for the target interface of the business system may include filtering the Swagger interface metadata for the target interface from the Swagger interface metadata for each interface generated by the Swagger tool.
[0060] In some embodiments, converting the data format of interface metadata to obtain interface metadata in a target format includes: parsing the interface metadata of the target interface to determine differences between the format of the interface metadata and a target format supported by the target interface documentation platform; and converting the data format of the interface metadata based on the differences to obtain interface metadata in the target format. In other words, the key to converting the interface metadata of the target interface to the data format of the target interface documentation platform (e.g., Blade Platform) lies in understanding the differences between the two formats and performing the conversion operation accordingly.
[0061] The following describes the data format conversion process using the Swagger interface metadata as an example and the Blade platform as the target interface document platform:
[0062] Specifically, the Swagger interface metadata is parsed to determine its structure and content. The format of the Swagger interface metadata is usually JSON format or YAML format that complies with the OpenAPI specification, which contains input and output parameter information at the interface level, but does not contain class original information and class relationships. The Blade Platform obtains data based on the reflection mechanism. The data objects in the beans and javadoc fields in the description file all contain interface class original information and description relationships of class inheritance / interface implementation. Then, the difference information between the format of the Swagger interface metadata and the target format supported by the target interface document platform is compared. Based on the above introduction to the format of the Swagger interface metadata and the introduction to the format supported by the target interface document platform, it can be seen that the determined difference information may include: whether there is class original information and class relationships. In the specific implementation, the difference information determined by comparison may also have differences in other dimensions. For example, the format supported by the target interface document platform contains target fields, while these target fields do not exist in the Swagger interface metadata. This embodiment does not specifically limit the final determined difference information.
[0063] After obtaining the difference information, the Swagger interface metadata is converted based on this difference information to conform to the format supported by the target interface documentation platform (such as the Blade Platform). For example, the Swagger interface metadata is parsed into JSON data format, converted into data for the target fields required by the Blade Platform (such as data, service, alias, etc.), and finally, all converted data is combined into a whole to form interface metadata in a format that can be directly used by the Blade Platform, namely, the target format. Converting the Swagger interface metadata into data for the target fields required by the Blade Platform can be understood as adjusting the data structure of the Swagger interface metadata to accommodate the data structure of the Blade Platform, thereby reorganizing interface-level data objects into data for target fields such as data, service, and alias. Because Swagger interface metadata lacks class primitives compared to the data formats supported by the Blade Platform, during the format conversion process, this class primitives and class relationships can be supplemented using predefined mapping rules or external configuration files, so that the converted interface metadata contains class primitives and class relationships.
[0064] In some embodiments, before step 201, the process further includes integrating the target plug-in into the business system. Based on this, step 201 can be implemented by loading the target plug-in after the application corresponding to the business system is started, obtaining interface metadata of the target interface of the business system, and converting the data format of the interface metadata to obtain interface metadata in the target format.
[0065] Specifically, a target plug-in can be pre-integrated into the business system connected to the target interface documentation platform. The main function of this target plug-in is to automatically complete the following tasks: the target plug-in can extract the interface metadata of the target interface from within the business system. For systems that integrate the Swagger tool, the target plug-in can directly read the API documentation generated by the Swagger tool and extract the interface metadata of the target interface. The target plug-in can also identify differences between the Swagger interface metadata and the format required by the target interface documentation platform and perform corresponding format conversion operations based on these differences. This includes but is not limited to supplementing the original class information, establishing class relationships, and adding detailed comments and instructions.
[0066] For example, each business system has its own corresponding application, where an application refers to a software program that carries business logic and provides service functions. The application corresponding to a business system can be understood as a specific software entity that directly implements business logic and service functions. It can be a standalone program or a collection of collaborative microservices. When the application is started, it automatically loads the pre-configured target plug-in, obtains the interface metadata of the target interface of the business system, and converts the data format of the interface metadata to obtain the interface metadata in the target format.
[0067] The above implementation method integrates a specific target plug-in in the business system in advance. By loading the target plug-in locally in the business system, the interface metadata acquisition and format conversion can be completed in the client's local environment. The localization processing makes full use of the existing resources of the business system. There is no need to deploy additional dedicated servers or services to handle the acquisition and conversion of the interface metadata of the target interface. It not only simplifies the interface metadata acquisition and format conversion process, but also reduces the implementation cost and is more friendly to the target interface document platform.
[0068] In some embodiments, integrating a target plug-in into a business system includes the following steps S11 to S13:
[0069] S11: Connecting a software package corresponding to the target plug-in to the business system; wherein the software package includes properties to be configured.
[0070] Specifically, you can first create a software package corresponding to the target plug-in. This package encapsulates the software logic required to implement the target plug-in's functionality. This package can include the target plug-in's core code, dependent libraries, and default values or placeholders for properties to be configured. After the target plug-in's software package is created, it is connected to the business system. If the business system is developed in Java, this package can be a Maven package, which can be added to the business system's project file.
[0071] For example, a component package corresponding to the target plug-in can be created based on Swagger. The properties to be configured in this component package may include: an enable property (denoted as Swagger.doc.enable) that describes whether the target plug-in is allowed to take effect in the business system; an affiliation property (denoted as Swagger.doc.groupId) that describes the organization or project group to which the target plug-in belongs; an identification property (denoted as Swagger.doc.artifactId) that describes the target plug-in itself; a version property (denoted as Swagger.doc.version) that describes the target plug-in's version; a branch property (denoted as Swagger.doc.branch) that describes the target plug-in's associated code branch; a name property (denoted as Swagger.doc.appName) that describes the application corresponding to the business system integrated with the target plug-in; an environment property (denoted as Swagger.doc.scmProject) that describes the development environment corresponding to the target plug-in; and a path property (denoted as Swagger.doc.apiPackages) that describes the specified package path scanned by the target plug-in. The artifactId is typically the name of the target plug-in, uniquely identifying it and ensuring that the target plug-in is not confused with other plug-ins under the same groupId.
[0072] S12: Obtain configuration information of the configuration attribute.
[0073] Exemplarily, the configuration information of each attribute to be configured can be determined according to actual business needs. That is, the specific configuration value of each attribute to be configured can be determined according to actual business needs. For example, if the target plug-in is currently required to take effect in the business system, the above-mentioned effective attribute can be set to effective (denoted as True). If the target plug-in is not currently needed, the above-mentioned effective attribute can be set to ineffective (denoted as False). Taking into account the need to obtain the interface metadata of the target interface and convert its data format in this embodiment, in order to quickly and accurately obtain the interface metadata of the target interface through the target plug-in later, the path attribute Swagger.doc.apiPackages can be configured as the specific package path where the target interface is located to ensure that the target plug-in can accurately scan the required interface metadata of the target interface.
[0074] For example, the configuration information of each attribute to be configured can be found in Table 1 below:
[0075] Table 1
[0076]
[0077] It should be noted that the configuration information of the attributes to be configured in Table 1 is only an example for ease of understanding and is not limited to this in specific implementations. In addition, the configuration information of each attribute to be configured can also be adjusted according to actual needs, thereby enhancing the flexibility of the target plug-in during use.
[0078] S13: Configuring the software package based on the configuration information to integrate the target plug-in into the business system.
[0079] Read and parse the above configuration information in the business system, initialize the target plug-in according to the parsed configuration information, and ensure that the plug-in runs according to the expected behavior.
[0080] This implementation integrates the target plug-in into the business system by accessing the software package corresponding to the target plug-in, obtaining the configuration information for the properties to be configured in the software, and configuring the software package based on this configuration information. This allows the target plug-in's behavior to be flexibly adjusted to meet different business needs without modifying the core code. This facilitates efficient integration of the target plug-in into the business system and allows for flexible configuration of its behavior based on actual needs. This approach not only simplifies the target plug-in's access process but also improves the flexibility and maintainability of the target plug-in during use.
[0081] In some embodiments, the attributes to be configured include an effectiveness attribute used to describe whether the target plug-in is allowed to take effect in the business system; the above-mentioned method, after the application corresponding to the business system is started, obtains the interface metadata of the target interface of the business system by loading the target plug-in, and converts the data format of the interface metadata to obtain the interface metadata in the target format, including: after the application corresponding to the business system is started, identifies whether the target plug-in is effective in the business system according to the effectiveness attribute; when the target plug-in is effective, obtains the interface metadata of the target interface of the business system by loading the target plug-in, and converts the data format of the interface metadata to obtain the interface metadata in the target format.
[0082] In this embodiment, the attributes to be configured include an effectiveness attribute (such as the aforementioned Swagger.doc.enable) for describing whether the target plug-in is allowed to take effect in the business system. The effectiveness attribute determines whether the target plug-in will be loaded and executed after the application corresponding to the business system is started. After the application corresponding to the business system is started, the configuration information of the effectiveness attribute can be read, and based on the configuration information of the effectiveness attribute, it is determined whether the target plug-in is effective in the business system. If the configuration information of the effectiveness attribute is true, indicating that it is effective, it is determined that the target plug-in is effective in the business system. If the configuration information of the effectiveness attribute is false, indicating that it is not effective, it is determined that the target plug-in is not effective in the business system. Then, when it is determined that the target plug-in is effective, the interface metadata of the target interface of the business system is obtained by loading the target plug-in, and the data format of the interface metadata is converted to obtain the interface metadata in the target format. If it is determined that the target plug-in is not effective, the target plug-in will not be loaded.
[0083] In the above implementation, when the target plug-in is identified as effective through the effectiveness attribute, it means that the target plug-in is explicitly enabled. Only then will the target plug-in be loaded, the interface metadata of the target interface of the business system be obtained, and the data format of the interface metadata is converted to obtain the interface metadata in the target format, avoiding unnecessary resource consumption and potential conflicts. In the case that the target plug-in is not effective, it means that the target plug-in is explicitly disabled, and related resources (such as memory, CPU, etc.) will not be occupied, thereby ensuring that the business system can run other critical tasks more efficiently. The target plug-in can be easily enabled or disabled through simple configuration, which allows developers to quickly adjust the behavior of the target plug-in according to different deployment environments (such as development, testing, and production).
[0084] In some embodiments, the above-mentioned software package includes a target function group, which is used to scan various classes under the specified package path, and the attributes to be configured include path attributes for configuring the specified package path; before the application corresponding to the business system is started, it also includes: initializing the target function group to configure the target function group to: scan the interface under the specified package path after the application is started to obtain the interface scanning result, store the interface scanning result in the target function group, and name the target function group as the target name; the above-mentioned after the application corresponding to the business system is started, by loading the target plug-in, obtain the interface metadata of the target interface of the business system, including: after the application corresponding to the business system is started, load the target plug-in to obtain the interface resource collection of the business system; obtain the target function group with the target name from the interface resource collection, and obtain the interface metadata of the target interface of the business system from the target function group.
[0085] Exemplarily, by loading the target plug-in, obtaining the interface metadata of the target interface of the business system includes the following S21 to S23:
[0086] S21: Initialize the target function group to configure the target function group to: scan the interface under the specified package path after the application is started to obtain the interface scanning result, store the interface scanning result in the target function group, and name the target function group as the target name.
[0087] The software package provides a default target function group, which is initialized to configure the scanning behavior of the target plug-in and store the scanning results in the target function group. The target function group is named the target name, and the scanning result is the above-mentioned interface scanning interface.
[0088] Specifically, initializing the target function group involves configuring it so that when the corresponding business system application starts, it automatically scans all classes under the specified package path based on the configured path attributes. During the scan, all interface information with API annotations is extracted and stored as the interface scan results in the target function group. Finally, the target function group is named the target name to facilitate subsequent references.
[0089] For example, if the software package is based on Swagger, the target functional group can be called the Swagger interface scanning document functional group. After initializing the Swagger interface scanning document functional group, it automatically scans all classes under the configured path attribute (for example, the Swagger.doc.apiPackages package) after the application starts, obtains the interface scanning results, and stores them in the target functional group. The target functional group is named the target name (for example, SwaggerDocPlus).
[0090] S22: After the application corresponding to the business system is started, the target plug-in is loaded to obtain the interface resource set of the business system.
[0091] Specifically, when the application corresponding to the business system is started, the target plugin is automatically loaded and a collection of interface resources, namely, a collection of SwaggerResources, is obtained. Loading the target plugin activates its functionality, enabling it to access and manipulate the internal structure of the business system, thereby identifying and extracting interface resources. The interface resource collection includes several interface resources in the business system. Different interfaces correspond to different interface resources. For example, when accessing website A, it has different interfaces, and different interfaces correspond to different resources.
[0092] As described above, the target function group is configured to scan the interfaces under the specified package path after the business system's corresponding application starts, obtain interface scan results, store the interface scan results in the target function group, and name the target function group the target name. In other words, after the application starts, the target function group automatically scans the specified package path and collects relevant interface information. This interface information (i.e., interface metadata) is organized and stored in the target function group. Therefore, the business system's interface resource collection includes the target function group with the target name. It is understandable that the business system also integrates the Swagger native documentation service. Therefore, after the business system's corresponding application starts, the Swagger native documentation service also scans all interfaces in the business system and generates corresponding interface metadata. This interface metadata generated by the Swagger native documentation service is also integrated into the interface resource collection. In other words, the business system's interface resource collection includes the target function group with the target name and the interface metadata for each interface generated by the Swagger native documentation service.
[0093] S23: Acquire a target function group with a target name from the interface resource collection, and acquire interface metadata of a target interface of the business system from the target function group.
[0094] As mentioned above, the interface resource collection includes a target function group with a target name and the interface metadata of each interface generated by the Swagger native document service. Based on this, the target function group with a target name can be obtained from the interface resource collection, and the corresponding interface metadata can be obtained from the target function group. The interface metadata in the target function group is the interface metadata of the target interface.
[0095] Specifically, the target name can be used as an identifier to search for the corresponding target function group in the interface resource collection. Once a matching function group is found, detailed interface metadata can be obtained from it as the interface metadata of the target interface.
[0096] For example, in combination with the above example, the interface resource collection is the SwaggerResource collection. The function group named SwaggerDocPlus is obtained from the SwaggerResource collection, and the Swagger interface metadata in the function group named SwaggerDocPlus is obtained as the interface metadata of the target interface, so as to prepare the data for subsequent conversion into the metadata format supported by the Blade Platform.
[0097] In the above example, the target function group, as an independent functional unit, can be initialized and configured before the application starts. Simply adjusting the configuration parameters allows adaptation to different needs. If new scan paths need to be added or changed, only the implementation of the target function group needs to be modified, without requiring large-scale changes to the entire business system. Assigning a specific target name to the target function group facilitates subsequent rapid location and search of the function group with the target name within the interface resource collection, as well as the extraction of interface metadata. This simplifies the acquisition of interface metadata for the target interface and improves acquisition efficiency.
[0098] In step 202, the client pushes the converted interface metadata in the target format to the target interface documentation platform, so that the target interface documentation platform generates and displays the target interface documentation based on the target interface metadata. For example, the target interface metadata can be uploaded to the target interface documentation platform via an HTTP POST request. Alternatively, the target interface metadata can be saved as a file (such as Swagger.json or Swagger.yaml) and then pushed to the target interface documentation platform via file upload.
[0099] After receiving the uploaded interface metadata, the target interface documentation platform parses it, for example, verifying that the interface metadata format complies with specifications and parsing information such as paths, methods, parameters, and responses. The target interface documentation platform then generates the target interface documentation based on the parsed interface metadata. The target interface documentation platform can provide a visual interface on which the target interface documentation is displayed. In a specific implementation, the generated target interface documentation can be displayed as a webpage, accessible to developers and testers via a browser.
[0100] Exemplarily, the target interface document platform may have a preset display template, and the target interface document may be obtained by filling the parsed interface metadata into the preset display template.
[0101] Figure 3 This is an interactive diagram of a method for processing interface metadata provided in an embodiment of the present application.
[0102] Exemplarily, as shown in 3, the method for processing the interface metadata includes:
[0103] Step 301: The client detects that an application is started.
[0104] The above applications can be understood as applications corresponding to the business systems running on the client.
[0105] Step 302: Identify that the target plug-in is effective.
[0106] Step 303: Initialize the target plug-in.
[0107] Step 304: Generate interface metadata in Swagger format.
[0108] Among them, the interface metadata in Swagger format can be generated based on the Swagger tool, which can be understood as Figure 3 The Swagger native documentation service in .
[0109] Step 305: Load the target plug-in.
[0110] Step 306: Obtain the interface metadata of the target interface in the Swagger format.
[0111] Step 307: Convert the interface metadata in the Swagger format into interface metadata in the target format.
[0112] Step 308: Push the interface metadata in the target format to the target interface document platform.
[0113] Among them, steps 301 to 308 are executed on the client side, and steps 309 and 310 are executed on the target interface document platform.
[0114] Step 309: Store the interface metadata in the target format in the target interface document platform through the data storage service.
[0115] The target interface document platform provides a data storage service to store the interface metadata in the target format on the target interface document platform through the data storage service. The target interface document platform generates a target interface document based on the received interface metadata in the target format.
[0116] Step 310: Read the target interface document through the data reading service.
[0117] The target interface documentation platform also provides a data access service, allowing front-end developers and testers to view the target interface documentation. This allows both front-end and back-end developers to communicate and develop based on the target interface documentation, improving R&D efficiency and reducing communication and R&D costs. Figure 3 The centralized interface document service can be understood as the general term for services provided by the target interface document platform. The centralized interface document service can include the above-mentioned data storage service and data reading service.
[0118] In the above example, by pre-integrating the target plug-in into the business system, the interface metadata is automatically acquired, formatted, and uploaded to the target interface documentation platform. This not only simplifies the logic and reduces costs, but also enhances the compatibility and user experience of the target interface documentation platform. This provides an efficient, accurate, and flexible solution for front-end and back-end collaboration, helping to improve the development efficiency and quality of the entire project.
[0119] To further facilitate understanding of the embodiments of the present application, the following uses an electronic signature management backend application as an example to demonstrate how to access a target plug-in and generate a target interface document on the Blade platform:
[0120] Step 1: In the application project for the e-Signature Management backend, add the target plugin's corresponding package, which can be a Maven package. This package contains all the necessary components for collecting, converting, and pushing Swagger interface metadata. Integrating this package into the project dependencies provides the technical foundation for subsequent steps.
[0121] Step 2: Obtain the configuration information of the target plug-in, and configure the software package based on the configuration information to integrate the target plug-in into the business system. The configuration information can be found in Table 1 above.
[0122] Step 3: After the e-Signature Management backend application is launched and the target plugin is enabled, it automatically retrieves the Swagger interface metadata for the target interface, converts it into Blade Platform-centralized metadata (i.e., interface metadata in the target format), and pushes it to the Blade Platform for integration. The Blade Platform then generates and displays the centralized interface documentation. The Blade Platform receives and parses this interface metadata, generates intuitive and easy-to-use target interface documentation, and provides users with access to it. Front-end and back-end developers can communicate and collaborate based on this target interface documentation, significantly improving R&D efficiency and reducing communication costs and errors caused by inconsistent understanding of the interface.
[0123] Figure 4 This is a schematic diagram of a display interface provided by a blade platform provided in an embodiment of the present application.
[0124] For example, Figure 4 As shown, the display interface includes: a first display area 401 , a second display area 402 and a third display area 403 .
[0125] The first display area 401 is used to display the application name of the business system (illustrated in the figure as "E-Signature Management Backend Application"). The second display area 402 is used to display a list 4021 corresponding to the target interface and a search box 4022. List 4021 includes a list of interface names corresponding to the target interface and a list of data types.
[0126] When a user (developer or tester) scrolls through list 4021 and selects an interface name, third display area 403 is controlled to display the detailed interface metadata corresponding to the selected interface name. When a user enters an interface keyword in search box 4022, third display area 403 is controlled to display the detailed interface metadata corresponding to the interface keyword. When a user enters a data type keyword in search box 4022, third display area 403 is controlled to display the descriptive information corresponding to the data type keyword.
[0127] For example, Figure 4 As shown, the third display area 403 displays detailed interface metadata, including the interface name (illustrated as createBasic in the figure), interface description information (illustrated as basic information added in the figure), interface input parameters, and data view. The interface input parameters include the name (illustrated as createBasicReqDTO in the figure) and the type (illustrated as TypeScript in the figure). The data view can be a JSON view, and the content of the data view is used to describe the type and corresponding description of each field related to createBasicReqDTO, so that users can understand the meaning of each field.
[0128] Figure 5 This is a schematic diagram of an interface metadata processing system provided in an embodiment of the present application.
[0129] For example, Figure 5 As shown, the interface metadata processing system includes: a client 101 and a target interface document platform 102;
[0130] Client 101 is used to obtain the interface metadata of the target interface of the business system, convert the data format of the interface metadata, obtain the interface metadata in the target format, and upload the interface metadata in the target format to the target interface document platform; wherein the target format is the format supported by the target interface document platform.
[0131] The target interface document platform 102 is used to generate a target interface document according to the interface metadata in the target format and display the target interface document.
[0132] In one possible implementation, the client 101 is specifically used to integrate a target plug-in into the business system. After the application corresponding to the business system is started, the target plug-in is loaded to obtain the interface metadata of the target interface of the business system, and the data format of the interface metadata is converted to obtain interface metadata in the target format.
[0133] In one possible implementation, the client 101 is specifically used to access the software package corresponding to the target plug-in in the business system; wherein the software package includes attributes to be configured; obtain configuration information for the attributes to be configured; and configure the software package based on the configuration information to integrate the target plug-in in the business system.
[0134] In one possible implementation, the attributes to be configured include an effectiveness attribute for describing whether the target plug-in is allowed to take effect in the business system. The client 101 is specifically used to initialize the target function group before the application corresponding to the business system is started, so as to configure the target function group as follows: after the application is started, scan the interface under the specified package path to obtain the interface scanning result, store the interface scanning result in the target function group, and name the target function group as the target name; after the application corresponding to the business system is started, load the target plug-in to obtain the interface resource set of the business system; obtain the target function group with the target name from the interface resource set, and obtain the interface metadata of the target interface of the business system from the target function group.
[0135] In one possible implementation, the software package includes a target function group, and the client 101 is used to initialize the target function group so that the target function group scans the interface under the specified package path to obtain an interface scanning result, stores the interface scanning result in the target function group, and names the target function group as the target name; loads the target plug-in to obtain the interface resource set of the business system; obtains the target function group with the target name from the interface resource set to obtain the interface metadata of the target interface of the business system.
[0136] In one possible implementation, the client 101 is specifically used to parse the interface metadata, determine the difference information between the format of the interface metadata and the target format supported by the target interface document platform; and convert the data format of the interface metadata based on the difference information to obtain interface metadata in the target format.
[0137] Figure 6 This is a structural diagram of an interface metadata processing device provided in an embodiment of the present application.
[0138] For example, Figure 6As shown, the interface metadata processing device 600 includes: a data processing module 601, used to obtain the interface metadata of the target interface of the business system, and convert the data format of the interface metadata to obtain interface metadata in a target format; wherein the target format is a format supported by the target interface document platform; an uploading module 602, used to upload the interface metadata in the target format to the target interface document platform, so that the target interface document platform generates a target interface document according to the interface metadata in the target format and displays the target interface document.
[0139] In one possible implementation, the interface metadata processing device also includes: a plug-in integration module for integrating the target plug-in in the business system; the data processing module 601 is specifically used to: after the application corresponding to the business system is started, obtain the interface metadata of the target interface of the business system by loading the target plug-in, and convert the data format of the interface metadata to obtain interface metadata in the target format.
[0140] In one possible implementation, the plug-in integration module is specifically used to: access the software package corresponding to the target plug-in in the business system; wherein the software package includes attributes to be configured; obtain configuration information for the attributes to be configured; and configure the software package based on the configuration information to integrate the target plug-in in the business system.
[0141] In one possible implementation, the attributes to be configured include an effectiveness attribute for describing whether the target plug-in is allowed to take effect in the business system; the data processing module 601 is specifically used to: after the application corresponding to the business system is started, identify whether the target plug-in is effective in the business system according to the effectiveness attribute; when the target plug-in is effective, obtain the interface metadata of the target interface of the business system by loading the target plug-in, and convert the data format of the interface metadata to obtain the interface metadata in the target format.
[0142] In one possible implementation, the software package includes a target function group, which is used to scan various classes under a specified package path, and the attributes to be configured include path attributes for configuring the specified package path; the data processing module 601 is specifically used to: before the application corresponding to the business system is started, initialize the target function group to configure the target function group to: after the application is started, scan the interface under the specified package path to obtain an interface scanning result, store the interface scanning result in the target function group, and name the target function group as a target name; after the application corresponding to the business system is started, load the target plug-in to obtain the interface resource set of the business system; obtain the target function group with the target name from the interface resource set, and obtain the interface metadata of the target interface of the business system from the target function group.
[0143] In one possible implementation, the data processing module 601 is specifically used to: parse the interface metadata, determine the difference information between the format of the interface metadata and the target format supported by the target interface document platform; and convert the data format of the interface metadata based on the difference information to obtain interface metadata in the target format.
[0144] Figure 7 This is a schematic diagram of the structure of a client provided in an embodiment of the present application.
[0145] For example, Figure 7 As shown, the client 101 includes: a memory 701 and a processor 702, wherein the memory 701 stores an executable program code 7011, and the processor 702 is used to call and execute the executable program code 7011 to perform a method for processing interface metadata.
[0146] In addition, an embodiment of the present application also protects a device, which may include a memory and a processor, wherein the memory stores executable program code, and the processor is used to call and execute the executable program code to perform an interface metadata processing method provided by an embodiment of the present application.
[0147] In this embodiment, the device can be divided into functional modules based on the above-described method examples. For example, each functional module can be mapped to a specific functional module, or two or more functions can be integrated into a single processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and represents only a logical functional division. In actual implementation, other division methods may be used.
[0148] In the case of dividing each functional module into corresponding functional modules, the device may further include a data processing module, an upload module, etc. It should be noted that all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module and will not be repeated here.
[0149] It should be understood that the apparatus provided in this embodiment is used to execute the above-mentioned method for processing interface metadata, and thus can achieve the same effect as the above-mentioned implementation method.
[0150] In the case of an integrated unit, the device may include a processing module and a storage module. When the device is applied to a client, the processing module may be used to control and manage the actions of the client. The storage module may be used to support the client in executing relevant program codes, etc.
[0151] The processing module may be a processor or controller that implements or executes the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure herein. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a digital signal processing (DSP) and a microprocessor, and the like. The storage module may be a memory.
[0152] In addition, the device provided in the embodiments of the present application can specifically be a chip, component or module, and the chip may include a connected processor and memory; wherein the memory is used to store instructions, and when the processor calls and executes the instructions, the chip can execute an interface metadata processing method provided in the above embodiment.
[0153] This embodiment also provides a computer-readable storage medium, which stores computer program code. When the computer program code runs on a computer, the computer executes the above-mentioned related method steps to implement an interface metadata processing method provided by the above embodiment.
[0154] This embodiment further provides a computer program product. When the computer program product is run on a computer, the computer is caused to execute the above-mentioned related steps to implement the method for processing interface metadata provided by the above embodiment.
[0155] Among them, the device, computer-readable storage medium, computer program product or chip provided in this embodiment are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above, and will not be repeated here.
[0156] Through the description of the above implementation methods, technical personnel in the relevant field can understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.
[0157] In the embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.
[0158] The above content is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.
Claims
1. A method for processing interface metadata, characterized in that: The method comprises: Integrate a target plug-in into the business system running on the client, where the software package corresponding to the target plug-in includes a target function group, and the target plug-in is different from the Swagger native plug-in integrated into the business system; Initializing the target function group to configure the target function group to: scan the interface under the specified package path after the application corresponding to the business system is started to obtain an interface scanning result, store the interface scanning result in the target function group, and name the target function group as the target name; After the application corresponding to the business system is started, the target plug-in is loaded to obtain an interface resource set of the business system, where the interface resource set includes a target function group with the target name and interface metadata of each interface generated by the Swagger native plug-in; Obtaining a target function group with the target name from the interface resource set, obtaining interface metadata of a target interface of the business system from the target function group, and converting the data format of the interface metadata to obtain interface metadata in a target format; wherein the target format is a format supported by a target interface document platform, and the target interface refers to an API interface for front-end and back-end interaction; The interface metadata in the target format is uploaded to the target interface document platform, so that the target interface document platform generates a target interface document according to the interface metadata in the target format and displays the target interface document.
2. The method according to claim 1, characterized in that The target plug-in integrated into the business system running on the client includes: Integrating a software package corresponding to the target plug-in into the business system running on the client; wherein the software package includes properties to be configured; Obtaining configuration information for the attribute to be configured; The software package is configured based on the configuration information to integrate the target plug-in into the business system.
3. The method according to claim 2, characterized in that The attributes to be configured include an effectiveness attribute for describing whether the target plug-in is allowed to take effect in the business system; After the application corresponding to the business system is started, the target plug-in is loaded to obtain the interface metadata of the target interface of the business system, and the data format of the interface metadata is converted to obtain the interface metadata in the target format, including: After the business system is started, identifying whether the target plug-in is effective in the business system according to the effectiveness attribute; When the target plug-in is effective, the target plug-in is loaded to obtain the interface metadata of the target interface of the business system, and the data format of the interface metadata is converted to obtain the interface metadata in the target format.
4. The method according to claim 1, wherein The converting the data format of the interface metadata to obtain the interface metadata in a target format includes: Parsing the interface metadata to determine difference information between a format of the interface metadata and the target format supported by the target interface document platform; The data format of the interface metadata is converted according to the difference information to obtain interface metadata in a target format.
5. A system for processing interface metadata, characterized in that: include: Client and target interface documentation platform; A target plug-in is integrated into the business system run by the client, the software package corresponding to the target plug-in includes a target function group, and the target plug-in is different from the Swagger native plug-in integrated in the business system; The client is used to initialize the target function group to configure the target function group as follows: after the application corresponding to the business system is started, scan the interface under the specified package path to obtain the interface scanning result, store the interface scanning result in the target function group, and name the target function group as the target name; after the application corresponding to the business system is started, load the target plug-in, obtain the interface resource set of the business system, the interface resource set includes the target function group with the target name and the interface metadata of each interface generated by the Swagger native plug-in; obtain the target function group with the target name from the interface resource set, obtain the interface metadata of the target interface of the business system from the target function group, convert the data format of the interface metadata to obtain the interface metadata in the target format, and upload the interface metadata in the target format to the target interface document platform; wherein, the target format is a format supported by the target interface document platform, and the target interface refers to the API interface used for front-end and back-end interaction; The target interface document platform is used to generate a target interface document according to the interface metadata in the target format and display the target interface document.
6. A device for processing interface metadata, characterized in that: The device comprises: A plug-in integration module is used to integrate a target plug-in into the business system running on the client. The software package corresponding to the target plug-in includes a target function group. The target plug-in is different from the Swagger native plug-in integrated in the business system. A data processing module is used to initialize the target function group to configure the target function group as follows: after the application corresponding to the business system is started, the interface under the specified package path is scanned to obtain an interface scan result, the interface scan result is stored in the target function group, and the name of the target function group is named as the target name; after the application corresponding to the business system is started, the target plug-in is loaded to obtain the interface resource set of the business system, the interface resource set includes the target function group with the target name and the interface metadata of each interface generated by the Swagger native plug-in; the target function group with the target name is obtained from the interface resource set, and the interface metadata of the target interface of the business system is obtained from the target function group, and the data format of the interface metadata is converted to obtain the interface metadata in the target format; wherein, the target format is a format supported by the target interface document platform, and the target interface refers to the API interface used for front-end and back-end interaction; The uploading module is used to upload the interface metadata in the target format to the target interface document platform, so that the target interface document platform generates a target interface document according to the interface metadata in the target format and displays the target interface document.
7. A client, characterized in that: The client includes: a memory for storing executable program code; A processor, configured to call and run the executable program code from the memory, so that the client executes the method according to any one of claims 1 to 4.
8. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed, the method according to any one of claims 1 to 4 is implemented.
Citation Information
Patent Citations
Back-end interface document generation method and device, electronic equipment and storage medium
CN119829123A