Collection and service method and system based on OAS centralized document

Abstract

The invention discloses a collection and service method and system based on OAS centralized documents. The invention relates to the technical field of software development. And the system loads a configuration file which comprises a time interval of API document collection, authentication information of a report interface and a document storage path. Initializing database connection to ensure that the database storing the API document can be accessed; starting a background service which is responsible for collecting API documents from the configured applications regularly or in real time; through centralized management and standardization of the API document, a developer can quickly find and understand the required API, so that the time for searching and reading the document is shortened, and the development efficiency is improved. The document updated in real time ensures that a developer always uses the API of the latest version, and errors and rework caused by using an outdated document are avoided. A unified document management platform promotes information sharing and cooperation among team members, and communication cost is reduced.

Description

Technical Field

[0001] The present invention relates to the technical field of software development, in particular to an API document display method, and more particularly to an OAS-based centralized document collection and service method and system. Background Art

[0002] In the current technology ecosystem, Swagger UI is a mature solution widely adopted for displaying API documentation within a single application. Its core technology relies on automatically performing a thorough scan of annotations and comments in the source code upon application startup, dynamically constructing structured API documentation based on this information, and displaying it externally in accordance with the industry standard OpenAPI Specification (OAS), ensuring consistency and accessibility.

[0003] However, in complex and changing enterprise-level application scenarios, the API documentation display method of a single application (such as Figure 2 As shown in the figure, the limitations of API documentation are gradually emerging. In the real world, enterprises often deploy and maintain numerous independent but collaborative applications, which directly leads to the fragmentation of API documentation. Specifically:

[0004] (1) Document fragmentation limits development efficiency: Frequent cross-application API documentation consultation has become an unavoidable task in the daily work of front-end engineers. Since the documentation is stored in a decentralized manner across various applications, engineers have to constantly switch between multiple application interfaces. This process is not only tedious and time-consuming, but also seriously hinders the improvement of development efficiency. The inconvenience of document fragmentation has become a key factor restricting rapid iteration and efficient development.

[0005] (2) Management challenges due to a lack of a holistic perspective: For those responsible for management, fragmented documentation systems cannot provide a comprehensive, unified perspective on the entire enterprise's API ecosystem. For example, even a simple count of APIs requires accessing each application one by one and manually aggregating the information. This process is time-consuming and error-prone, significantly hindering the effective management and strategic planning of API resources.

[0006] (3) Challenges of stability and availability: During the application lifecycle, iterative upgrades of business functions are the norm. However, since the display of API documentation is often regarded as an additional function of the application, when the application is restarted or upgraded due to business needs, the availability of API documentation is often affected, resulting in temporary inaccessibility. This instability not only affects the developer's user experience, but may also interfere with downstream work that relies on API documentation for debugging, testing, or integration, thereby affecting the smooth progress of the entire development process.

[0007] In summary, the existing single-application API document display method based on Swagger UI faces significant challenges in efficiency, management, and stability when addressing the document management needs of enterprise-level multi-application environments. To this end, the present invention proposes a centralized document collection and service method and system based on OAS. Summary of the Invention

[0008] In view of this, the present invention aims to provide a centralized document collection and service method and system based on OAS to solve or alleviate the technical problems existing in the prior art, namely, the document dispersion that limits development efficiency, the management difficulties caused by the lack of an overall perspective, and the challenges of stability and usability, and to provide at least a beneficial alternative. The technical solution of the present invention is achieved as follows:

[0009] First, the collection and service method based on OAS centralized documents:

[0010] (1) Overview:

[0011] The present invention aims to build an efficient and centralized API document management system, which realizes the collection, parsing, storage, display and interactive functions of API documents through automated and standardized means. The system first loads the configuration, including the collection time interval, authentication information, storage path, etc., and initializes the database connection. Then, API documents that comply with the OAS specification are collected from the configured applications regularly or in real time through the background service, and an interface is provided to allow applications to directly report documents. After parsing and verification, the collected documents are stored in the database, and indexed and classified for subsequent search and display. The system also provides a user interface with integrated Swagger UI to facilitate users to test, call, search, browse and compare versions of APIs. The entire solution aims to improve the management efficiency of API documents, ensure the accuracy and real-time nature of the documents, while reducing development and maintenance costs, and provide developers with more convenient and efficient API document services.

[0012] (2) Technical solution:

[0013] To achieve the above technical objectives, the present invention chooses to perform the following operating steps.

[0014] 2.1 Step S1, initialization and configuration loading and starting document collection service:

[0015] The system loads the configuration file, including the interval for collecting API documents, the authentication information of the reporting interface, and the document storage path. Initialize the database connection to ensure that the database storing the API documents can be accessed;

[0016] Start a background service that is responsible for collecting API documentation from configured applications periodically or in real time.

[0017] The background service includes sending requests to various applications at the same time according to the time interval or trigger conditions specified in the configuration file, and the requests include providing API documents of the OAS specification.

[0018] 2.1.1 Step S100, load the configuration file:

[0019] Locate the preset configuration file path; open the configuration file and read the configuration information line by line or item by item; the configuration information includes the time interval for collecting API documents (such as hourly, daily, etc.), the authentication information of the reporting interface (such as API key, username and password, etc.), and the document storage path (database connection information or file system path).

[0020] 2.1.2 Step S101, verify configuration information:

[0021] Verify the read configuration information to check whether the time interval is a valid value, whether the authentication information conforms to the expected format, and whether the storage path is accessible.

[0022] 2.1.3 Step S102, initialize database connection:

[0023] Extract database connection information from the configuration file, including database type (such as MySQL, PostgreSQL, etc.), host name, port number, database name, username, and password.

[0024] Use the extracted connection information to try to establish a connection to the database; if the connection fails, record the error log and try to reconnect or perform failure recovery based on the configuration.

[0025] 2.1.4 Step S103: Configure background service parameters:

[0026] Set the background service's operating parameters based on the time interval or trigger conditions specified in the configuration file. If configured for real-time collection, set up an event listener or polling mechanism.

[0027] 2.1.5 Step S104, initializing service components:

[0028] Load and initialize all components required by the background service, including the HTTP client, request builder, and response handler. Start the background service as a daemon or background task. Ensure that the service continues to run and automatically recovers even after a system reboot or crash.

[0029] 2.1.6 Step S105, perform the collection task:

[0030] Based on the configured time interval or trigger condition, the background service begins sending requests to the configured application periodically or in real time to collect API documentation. The request should include an instruction to provide the OAS specification so that the application can return API documentation that meets the specification.

[0031] 2.2 Step S2, document collection and analysis:

[0032] When the application receives a request and returns its API document (JSON or YAML format), it receives and parses these documents to see if they comply with the OAS specification, and then stores the parsed document data in the database.

[0033] 2.2.1 Step S200: Receive API documentation:

[0034] Continuously listen for responses from the application, which contain the API documents returned by the application; when a response is received, extract the API document data (presented in JSON or YAML format).

[0035] Record the metadata information of the time and source of the document received for subsequent tracking and auditing.

[0036] 2.2.2 Step S201: Parse the API document:

[0037] Based on the API document format (JSON or YAML), select the appropriate parser to parse the document content. Use the parser to parse the document layer by layer to extract the API endpoints, parameters, request methods, and response formats.

[0038] 2.2.3 Step S202: Verify OAS compliance:

[0039] Check whether the document structure, field naming, data type, etc. comply with OAS standards; if errors are found during parsing or verification, record the error information, including error type, location, and repair suggestions.

[0040] 2.2.4 Step S203: Generate an analysis report:

[0041] Based on the parsing results, a parsing report is generated to summarize the parsing status of the document, including whether it complies with the OAS specification, any errors and warnings, etc.

[0042] 2.2.5 Step S204: Storing parsed data:

[0043] Store the parsed document data (including API information and parsing reports) in the database. Ensure that the stored data is clearly structured and easy to query and retrieve.

[0044] Update the API document's status in the database, marking it as "resolved" or "pending review" for subsequent processing. If automatic review or notification mechanisms are configured, the document's status triggers the corresponding subsequent processes, such as notifying the document owner for review or automatically fixing errors.

[0045] 2.3 Step S3: Receiving directly reported documents:

[0046] An OAS-compliant interface is provided to the application, allowing it to directly report its API documentation. When the application has a new version of the API documentation, the document is reported to this interface through the plug-in during the compilation phase. The reported document is received and parsed, and is also verified and stored.

[0047] At the same time, the stored API documents are indexed and classified, including the API name, path, description, version and other information.

[0048] 2.3.1 Step S300: Providing the OAS Standard Interface:

[0049] The interface should support receiving API documents in JSON or YAML format and define clear request and response structures; the interface documentation should include the interface URL, request method, request parameters, and response format details.

[0050] 2.3.2 Step S301: Configure the authentication mechanism:

[0051] Configure API keys and OAuth2 mechanisms for the interface to ensure that only authorized applications can report documents.

[0052] 2.3.3 Step S302: Application reports API documentation:

[0053] When the application has a new version of the API document, the compilation phase plug-in automatically triggers the reporting operation and sends the document to the interface provided in step S300; after the interface receives the reported API document data, it uses the same parser as in step S201 to parse the reported API document and extract the key information of the API endpoint, parameters, request method and response format.

[0054] 2.3.4 Step S303: Verify OAS compliance:

[0055] Perform OAS specification verification on the parsed document content to ensure that the document complies with the OpenAPI standard requirements. Store the parsed and verified API document data in the database and manage it together with the document data collected through other means;

[0056] At the same time, the stored API documents are indexed. The index should include the name, path, description and version of the API. The documents are classified and managed according to the attributes of the API (application and function classification), so that users can browse and find APIs by category.

[0057] Update the status of the reported API document in the database, marking it as "received", "parsed", or "verified". Configure a notification mechanism to notify relevant parties (such as document owners, reviewers, etc.) based on changes in document status.

[0058] 2.4 Step S4, document display and interaction:

[0059] Provides a user interface integrated with Swagger UI to display collected API documentation. This interface helps users test APIs, call APIs, search, browse, and / or compare versions.

[0060] (3) Mechanisms for resolving technical issues:

[0061] 3.1 Solve the problem of document dispersion:

[0062] This invention centrally stores all API documentation in a single system, eliminating the difficulty of finding and sharing documents scattered across different locations. Developers can quickly find the required documentation through a unified interface, improving work efficiency. The OAS specification is used as the standard format for API documentation, ensuring consistency and readability. This helps developers understand and use APIs more quickly, reducing misunderstandings and errors caused by inconsistent formats.

[0063] 3.2 Solve the management problem of lack of overall perspective and improve stability and availability:

[0064] The system automatically tracks document change history and provides version control. Developers can easily view, compare, and restore previous versions, ensuring full control over API documentation changes.

[0065] The system supports real-time documentation updates and provides an open feedback channel. Developers can promptly report issues and make improvement suggestions, promoting the continuous optimization and improvement of documentation.

[0066] Integrate automated testing tools to monitor and test APIs in real time, helping to promptly identify and fix potential issues and ensure API stability and availability.

[0067] Secondly, based on the OAS centralized document collection and service system:

[0068] like Figure 4As shown, the system is used to implement the above-mentioned OAS-based centralized document collection and service method and system, which includes:

[0069] (1) Processor module: Responsible for loading and parsing configuration files, including the interval for collecting API documents, authentication information for reporting interfaces, and the document storage path. It initializes the relevant parameters for database connections and works with the database module to ensure stable access to the database storing API documents. It also starts and manages the background service process, which is responsible for collecting API documents from applications periodically or in real time, depending on the configuration.

[0070] (2) Storage Module: Temporarily stores configuration files for quick access by the processor module. Provides sufficient storage space to support the database module to store large amounts of API document data.

[0071] (3) Network communication module: Under the control of the background service, it sends requests to the configured applications to collect API documents. It works in conjunction with the database module to ensure stable data transmission and storage.

[0072] (4) Database module: Responds to the initialization request of the processor module and establishes a database connection. Prepares to receive and store the parsed API document data.

[0073] (5) User interface module: Integrates Swagger UI to provide a friendly user interface for users to interact with API documents.

[0074] Compared with the prior art, the present invention has the following beneficial effects:

[0075] 1. Improved Development Efficiency: By centrally managing and standardizing API documentation, developers can quickly find and understand the APIs they need, reducing the time spent searching and reading documentation and thus improving development efficiency. Real-time documentation updates ensure that developers always use the latest version of the API, avoiding errors and rework caused by using outdated documentation. A unified document management platform facilitates information sharing and collaboration among team members, reducing communication costs. A permissions management mechanism ensures document security and consistency, avoiding confusion and conflicts caused by multiple editors.

[0076] Optimize API Management: Version control makes API change history clear and traceable, facilitating management and maintenance. By monitoring and analyzing APIs from a holistic perspective, potential issues can be identified and resolved promptly, improving API stability and availability.

[0077] 3. Improved User Experience: The user interface, integrated with tools like Swagger UI, provides a user-friendly API testing, calling, and browsing experience, lowering the barrier to entry for users. Detailed API documentation and sample code help users understand and use the API more quickly, improving the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0078] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0079] Figure 1 Schematic diagram of the method flow of the present invention;

[0080] Figure 2 A schematic diagram for traditional document access scattered across multiple sources;

[0081] Figure 3 A schematic diagram of the present invention providing centralized access services after collecting documents;

[0082] Figure 4 Schematic diagram of the system composition of the present invention. DETAILED DESCRIPTION

[0083] To make the above-mentioned objects, features, and advantages of the present invention more clearly understood, the following detailed description of the specific embodiments of the present invention is given in conjunction with the accompanying drawings. The following description sets forth many specific details to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways than those described herein, and those skilled in the art can make similar improvements without violating the scope of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0084] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Reference can be made to the common and similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the method description.

[0085] Explanation of relevant terms:

[0086] (1) OAS: An open API documentation specification. Swagger is the early name of this specification.

[0087] (2) Swagger UI: A web interface that displays the API documentation of a single application based on the OAS specification.

[0088] (3) Collection: Collect the API documents scattered across several single applications within the organization through automatic periodic collection or manual proactive reporting.

[0089] (4) Centralized service: Collect all API documents within the organization, reorganize and display them in a centralized manner so that users can view the API documents within the organization and managers can understand the overall situation.

[0090] (5) Time interval: refers to the time interval at which the system regularly collects API documents, that is, how often the system automatically obtains API documents from the application.

[0091] (6) Authentication information of the reporting interface: The authentication information required when the application reports the API document to the system, such as API key, user name and password, is used to ensure the security of the reporting operation.

[0092] (7) Document storage path: The physical or logical path where the system stores API documents, which specifies the storage location of the documents in the database or file system.

[0093] (8) OAS specification: OpenAPI Specification is a standard specification for defining and describing RESTful APIs. The system collects, parses and displays API documents based on this specification.

[0094] (9) Database: A system used to store and manage API documents and related information, providing persistent storage and efficient retrieval of data.

[0095] (10) Compilation-phase plug-ins: tools or codes integrated during the application compilation process, used to automatically generate API documentation and report it to the system, so as to achieve synchronous updating of documentation and code.

[0096] (11) Testing API: In the user interface or development environment, the API function is verified by simulating API requests. It is usually used in the development and debugging stages.

[0097] (12) Calling API: In actual application scenarios, the process of obtaining data or performing operations by sending requests to API endpoints is the main way to use API.

[0098] Example 1: Figure 1 and Figure 3As shown, this embodiment will disclose the application of the OAS-based centralized document collection and service method in the online car-hailing platform. In order to effectively manage and maintain various documents provided by drivers (such as driver's licenses, vehicle registration certificates, ID cards, etc.), a collection and service method solution based on OAS (OpenAPI Specification) centralized documents is adopted. It can automatically collect, parse, store, classify and display these documents, improve management efficiency and ensure the security and compliance of documents.

[0099] In this embodiment, regarding step S1: initialization and configuration loading and starting document collection service:

[0100] Step S100: Load the configuration file. The system locates the ride-hailing platform configuration file directory, opens "driver_doc_collection_config.json," and reads the configuration information, including the document collection interval (e.g., 3:00 AM daily), the authentication information for the reporting interface (e.g., the API key "abc123"), and the document storage path (connection information pointing to the MySQL database).

[0101] Step S101: Verify the configuration information. Check whether the time interval is a valid value (such as not a negative number or an illegal format), whether the authentication information complies with the format requirements of the API key, and whether the database connection information of the storage path is complete and accessible.

[0102] Step S102: Initialize the database connection. Use the configured MySQL connection information (host name "db.rideshare.com", port number "3306", database name "driver_docs", username "admin", password "securepwd") to attempt to establish a connection. If the connection fails, log an error and attempt to reconnect or send an alert to the administrator.

[0103] Step S103: Configure the background service parameters. According to the configuration, set the background service to automatically trigger the document collection task at 3:00 am every day.

[0104] Step S104: Initialize the service components. Load the HTTP client library, request builder, and response handler, and start the background service as a daemon process to ensure automatic recovery after a system restart or crash.

[0105] Step S105: Execute the collection task. The backend service sends a request to the driver management system of the online ride-hailing platform at a specified time, requesting the driver document information that complies with the OAS specification.

[0106] In this embodiment, regarding step S2: document collection and analysis:

[0107] Step S200: Receive API documents. Monitor responses from the driver management system, extract driver document data (presented in JSON format), and record the receipt time and source application (such as "driver management system").

[0108] Step S201: Parse the API document. Use a JSON parser to parse the document layer by layer and extract key fields such as the driver's name, driver's license number, vehicle registration information, and ID card information.

[0109] Step S202: Verify OAS compliance. Check whether the document structure, field naming, data types, etc. comply with OAS standards. If any non-compliance is found, record the error information and provide repair suggestions.

[0110] Step S203: Generate a parsing report that summarizes the parsing status of the document, including whether it complies with the OAS specification, any errors and warnings, etc., and stores it in the database.

[0111] Step S204: Store the parsed data. The parsed driver document data is stored in the MySQL database and the document status is updated to "Parsed." At the same time, a notification mechanism is triggered to notify the document reviewer for subsequent review.

[0112] In this embodiment, regarding step S3: receiving directly reported documents:

[0113] Step S300: Provide an OAS standard interface. Open an interface (e.g., " / api / v1 / driver_docs / upload") in the ride-hailing platform to receive driver documents in JSON format and define clear request and response structures.

[0114] Step S301: Configure the authentication mechanism. Configure API key authentication for the interface to ensure that only legitimate drivers or administrators can submit documents.

[0115] Step S302: Application submits API documentation. The driver or administrator uploads the new version of the driver documentation to the aforementioned API via the ride-hailing platform's client or management backend. After receiving the data, the API parses it using the same parser as in step S201.

[0116] Step S303: Verify OAS compliance and store. The parsed document content is verified against the OAS specification to ensure compliance. Once verified, the document data is stored in the database and indexed and categorized, such as by driver's name and document type (driver's license, vehicle registration certificate, etc.). The document status is updated to "Received" or "Verified," and the relevant parties are notified.

[0117] In this embodiment, regarding step S4: Document Display and Interaction: a user interface integrated with Swagger UI is provided to display the collected driver documents in the ride-hailing platform's management backend. The interface should support functions such as search, browsing, and version comparison. Users can directly test the API through the interface (e.g., query a driver's document information), call the API to perform document management operations (e.g., download and update documents), and search, browse, and compare versions of documents.

[0118] The technical solution provided in this embodiment significantly improves management efficiency and reduces manual intervention and errors by automating the collection, parsing, and storage of driver documents. It ensures that all collected documents comply with OAS specifications, improving document consistency and readability. By configuring authentication mechanisms and permission control, only authorized users can access and modify documents, ensuring document security. The integrated Swagger UI makes document display and interaction more intuitive and convenient, enhancing the user experience.

[0119] Example 2: Based on Example 1, this example further provides a Python execution program for this solution:

[0120]

[0121]

[0122]

[0123]

[0124]

[0125]

[0126] The principle of the above procedure is:

[0127] (1) Configuration loading (S100-S101): When the program starts, it first loads the configuration file driver_doc_collection_config.json and reads the configuration information such as the API key, database connection information, and document collection interval. The configuration information is verified to ensure its validity.

[0128] (2) Database initialization (S102): Use the database connection information in the configuration file to try to establish a MySQL database connection. If the connection fails, the program should record an error log and try to reconnect or send an alert.

[0129] (3) Service component initialization (S104): A simple HTTP server is initialized using the Flask framework to receive directly reported documents and provide a Swagger UI interface.

[0130] Document collection task (S105 & collect_documents function): Start the document collection task in a separate thread. This task regularly sends requests to the driver management system of the online car-hailing platform at configured time intervals to obtain driver documents.

[0131] The received document is processed by the process_document function.

[0132] (3) Document processing (common functions in S2 & S3):

[0133] The process_document function is responsible for parsing the document, verifying OAS specification compliance, storing the parsed data, and triggering the notification mechanism.

[0134] The extract_driver_info function extracts driver information from a document.

[0135] The validate_document function verifies the validity of the document.

[0136] The store_document function stores the parsed driver information in the database.

[0137] (4) Directly report document interface (S300-S303):

[0138] Provides the / api / v1 / driver_docs / upload interface, allowing drivers or administrators to directly submit documents.

[0139] After the interface receives the document, it calls the process_document function to process it.

[0140] (5) Document display and interaction (S4):

[0141] Integrate Swagger UI to provide a user interface to display collected driver documents and support functions such as search, browsing, and version comparison.

[0142] Users can directly test the API and perform document management operations through the interface.

[0143] All of the above embodiments merely represent implementation methods of the present invention in practical applications. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art could make various modifications and improvements without departing from the scope of the present invention, all of which fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the appended claims.

[0144] For those skilled in the art, it can be further appreciated that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0145] At the same time, those skilled in the art will understand that all or part of the processes in all the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media provided in this application and used in the embodiments may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double-speed data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

Claims

1. The collection and service method based on OAS centralized documents is characterized by: The following steps are included: S1, load the configuration file, including the interval for collecting API documents, authentication information for the reporting interface, and the document storage path; initialize the database connection; and start a background service responsible for collecting API documents from the configured applications periodically or in real time; S2, after receiving the request and returning its API documents, the application receives and parses these documents to see if they comply with the OAS specification, and then stores the parsed document data in the database; S3 provides an OAS-compliant interface to applications, allowing them to directly report their API documentation. S4 provides a user interface integrated with Swagger UI to display the collected API documents; it helps users test APIs, call APIs, search, browse, and / or compare versions through the interface.

2. The collection and service method according to claim 1, characterized in that: In S1, the background service includes sending requests to various applications at the same time according to the time interval or trigger condition specified in the configuration file, and the sending request includes providing the API document of the OAS specification.

3. The collection and service method according to claim 2, characterized in that: The execution process of S1 includes: S100, locate the preset configuration file path; open the configuration file and read the configuration information line by line or item by item; the configuration information includes the time interval for collecting API documents, the authentication information of the reporting interface, and the document storage path; S101, verifying the read configuration information to check whether the time interval is a valid value, whether the authentication information conforms to the expected format, and whether the storage path is accessible; S102, extracting database connection information from the configuration file, including database type, host name, port number, database name, user name, and password; using the extracted connection information, attempting to establish a connection with the database; S103, setting the operating parameters of the background service according to the time interval or trigger condition specified in the configuration file; if the configuration is real-time collection, setting an event listener or polling mechanism; S104, load and initialize all components required for the background service, including the HTTP client, request builder, and response processor; S105 , according to the configured time interval or trigger condition, the background service starts to send requests to the configured application periodically or in real time to collect API documents.

4. The collection and service method according to claim 1, characterized in that: The execution process of S2 includes: S200, continuously monitoring the response from the application; S201, using a parser to parse the document layer by layer to extract the API endpoints, parameters, request methods, and response formats; S202, if an error is found during the parsing or verification process, record the error information, including the error type, location, and repair suggestions; S203, generating an analysis report based on the analysis results; S204: Store the parsed document data into a database.

5. The collection and service method according to claim 4, characterized in that: In the S3, the stored API documents are indexed and classified, including the name, path, description and version information of the API.

6. The collection and service method according to claim 4, characterized in that: In the S3, when an application has a new version of the API document, the document is reported to this interface through a plug-in in the compilation phase; the reported document is received and parsed, and is also verified and stored.

7. The collection and service method according to claim 5, characterized in that: The execution process of S3 includes: S300, the interface receives API documents in JSON or YAML format; S301, the interface is configured with an API key and OAuth2 mechanism to ensure that only authorized applications can report documents; S302: When the application has a new version of the API document, the compilation phase plug-in automatically triggers the reporting operation and sends the document to the interface provided in S300. After the interface receives the reported API document data, it uses the same parser as in S201 to parse the reported API document and extract the API endpoint, parameters, request method and response format.

8. The collection and service method according to claim 7, characterized in that: In the S3, the API document data that has been parsed and verified is also stored in the database; At the same time, the stored API documents are indexed. The index should include the API name, path, description, and version. The documents are categorized and managed according to the API attributes to facilitate users to browse and find APIs by category. Update the status of the reported API document in the database, marking it as "received", "parsed" or "verified".

9. A system for implementing the collection and service method according to any one of claims 1 to 8, characterized in that: The system comprises: Processor module: responsible for loading and parsing configuration files, including the time interval for collecting API documents, authentication information of the reporting interface, and document storage path; Network communication module: under the control of the background service, sends requests to the configured application to collect API documents; Database module: responds to the initialization request of the processor module, establishes a database connection; receives and stores the parsed API document data.

10. The system according to claim 9, characterized in that: The system also includes a user interface module: integrating Swagger UI to provide a user interface for users to interact with API documents.

Images