Method and system for integrating third-party interface

Abstract

The invention relates to the technical field of digital data processing, and discloses a method and a system for integrating third-party interfaces, and the method for integrating the third-party interfaces realizes integration and aggregation of a plurality of third-party interfaces by constructing a unified interlayer architecture. The core is to establish an interface adaptation layer, carry out standardized packaging on protocol formats and parameter rules of different interfaces, and eliminate the compatibility problem caused by interface differences. Meanwhile, a data conversion engine is established, and automatic mapping of third-party return data and system internal formats is completed. And the middle layer also has the functions of routing request, load balancing and exception handling, can dynamically call different interface resources according to service requirements, and aggregates dispersed return results into unified output. According to the mode, the development complexity of direct butt joint of multiple interfaces can be reduced, and the management efficiency and expansibility of the system on the third-party service can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to a method and system for integrating third-party interfaces, belonging to the technical field of digital data processing. BACKGROUND

[0002] In the practice of integrating third-party interfaces, although the existing aggregation technology has simplified the integration process to a certain extent, it still has many systematic network layer common defects in the three key dimensions of reusability, change isolation and management expansion due to design ideas and architecture bottlenecks. These defects seriously restrict the efficient operation and flexible response of the system.

[0003] Specific defects include: The reusability of the existing technology is obviously limited, and it is difficult to reuse across manufacturers, protocols and versions for "single interface" or "similar protocol" scenarios.

[0004] After the third-party interface is changed, the existing technology still needs to modify the configuration / code of the intermediate layer or dependent system, and has not realized "external change and internal invariance". Minor adjustments to the third-party interface may cause the intermediate layer and the internal system to be incompatible.

[0005] The existing technology is difficult to balance "efficient management" and "rapid expansion". Either the architecture is too heavy to expand, or the function is simple and the management is weak. A heavy architecture like ESB can manage interfaces uniformly, but its expansion process is complicated, and the addition of new interfaces requires multi-link approval and development, which takes 2-3 weeks and is difficult to respond to temporary needs.

[0006] Therefore, it is necessary to propose a method and system for integrating third-party interfaces to solve the problem that the existing integration of third-party interfaces is prone to systematic network collapse. SUMMARY

[0007] The present application provides a method and system for integrating third-party interfaces, which can solve the problem that the existing integration of third-party interfaces is prone to systematic network collapse.

[0008] The method for integrating third-party interfaces provided by the present application comprises: Receiving the calling instruction of the third-party interface caller.

[0009] Analyzing the calling instruction to obtain the utilization instruction of the interface plug-in.

[0010] Feedback the utilization instruction of the interface plug-in to the interface plug-in module.

[0011] Receiving the data information of the third-party database transmitted by the interface plug-in module.

[0012] Based on the command, the management module is invoked to connect to the local database. This connection enables the storage of data from the third-party database.

[0013] Use the command information to connect to the local database to call the local database.

[0014] Based on the storage location table and the index path of the third-party database, the cylinder algorithm is applied to divide the data to be stored into blocks in order to calculate the amount of data to be stored.

[0015] Based on the amount of data to be stored, and combined with the instructions, the request parameter details of the third-party interface caller are parsed out; the request parameter details include data format, field type, and business rule information.

[0016] By using the request parameter details, the amount of data to be stored is calibrated, and the calibrated amount of data is encrypted and verified using an encryption algorithm to generate the actual amount of data to be stored.

[0017] Based on the actual amount of stored data, the storage resources of the local database are invoked. After the local database storage resources are allocated, an input information communication interface for the local database is established. A secure communication connection is established between the input information communication interface and the third-party interface caller. Through the secure communication connection, the third-party interface caller accesses the data information of the local database.

[0018] Based on the call command, data information from the local database and / or third-party databases is fed back to the third-party interface caller.

[0019] Specifically, the core logic of integrating third-party interfaces is plug-in encapsulation, visual adaptation, and decoupling of internal and external interfaces.

[0020] Understandably, the platform encapsulates some third-party interfaces into standardized plugins. Each plugin exists as a JAR file, containing the core logic for protocol parsing, parameter validation, encryption, and decryption for that type of interface, and supports flexible expansion. When adding a new interface of the same type, only differentiated configurations need to be added based on the plugin template, without the need to repeatedly develop basic functions.

[0021] Furthermore, the storage location table is parsed to obtain the initial physical address set of the target data in the third-party database. Simultaneously, the index path of the third-party database is parsed to obtain the logical hierarchy sequence for accessing the target data.

[0022] Based on the aforementioned logical hierarchy sequence, a virtual data block cylinder model is constructed. Specifically, the logical hierarchy sequence is mapped to the height dimension of the cylinder, and the initial physical address set is mapped to the circular base region of the cylinder.

[0023] Along the height dimension of the cylinder, i.e. according to the logical hierarchy sequence, the virtual data block cylinder is divided into equal-volume or non-equal-volume segments according to preset rules, thereby dividing the data to be stored into several continuous data block units.

[0024] Each data block unit is processed sequentially. Based on its radial and angular position coordinates in the cylindrical model, its specific storage segment size in the third-party database is calculated. The storage segment sizes corresponding to all data block units are summarized to generate the amount of data to be stored.

[0025] Furthermore, the request parameter details are read, and the data format specifications, field type definitions, and valid data load indications in the business rule information are extracted.

[0026] The amount of data to be stored is compared with the effective data load indication to obtain the calibrated data amount.

[0027] The calibrated data volume is used as input plaintext to generate a corresponding encrypted verification value for the data volume.

[0028] The calibrated data volume is bound and combined with the encrypted verification value of the data volume to form the final generated data volume of the actual stored data that has been protected for integrity.

[0029] At the data management level, the method for integrating third-party interfaces utilizes interface and management modules. The interface module, as the core execution layer for the platform to access and transform third-party interfaces, needs robust interface plugin integration capabilities. This module requires a standardized plugin integration framework capable of seamlessly supporting various third-party interface plugins, encapsulated as JAR files. Each plugin must have built-in complete processing logic for the corresponding third-party interface, including but not limited to automatic parsing of diverse protocols, intelligent verification of parameters across multiple scenarios, encryption and decryption processing for different encryption methods, and an autonomous fault-tolerance mechanism for anomalies. Through this pluggable design, the interface module can quickly adapt to different types and manufacturers of third-party interfaces. When a new third-party interface is added, only the corresponding plugin needs to be integrated to complete the connection, without modifying the underlying module architecture. This provides solid technical support for subsequent conversion from external to internal interfaces, ensuring the platform can flexibly and quickly integrate with various third-party systems to meet diverse business integration needs of enterprises. The management module, as the platform's central control layer, needs to encompass multiple fully functional sub-modules to achieve comprehensive and refined management of interfaces and plugins.

[0030] Furthermore, the storage location table is parsed to obtain the initial physical address set of the target data in the third-party database. Simultaneously, the index path of the third-party database is parsed to obtain the logical hierarchy sequence for accessing the target data.

[0031] Based on the aforementioned logical hierarchy sequence, a virtual data block cylinder model is constructed. Specifically, the logical hierarchy sequence is mapped to the height dimension of the cylinder, and the initial physical address set is mapped to the circular base region of the cylinder.

[0032] Along the height dimension of the cylinder, i.e. according to the logical hierarchy sequence, the virtual data block cylinder is divided into equal-volume or non-equal-volume segments according to preset rules, thereby dividing the data to be stored into several continuous data block units.

[0033] Each data block unit is processed sequentially. Based on its radial and angular position coordinates in the cylindrical model, its specific storage segment size in the third-party database is calculated. The storage segment sizes corresponding to all data block units are summarized to generate the amount of data to be stored.

[0034] Furthermore, the request parameter details are read, and the data format specifications, field type definitions, and valid data load indications in the business rule information are extracted.

[0035] The amount of data to be stored is compared with the effective data load indication to obtain the calibrated data amount.

[0036] The calibrated data volume is used as input plaintext to generate a corresponding encrypted verification value for the data volume.

[0037] The calibrated data volume is bound and combined with the encrypted verification value of the data volume to form the final generated data volume of the actual stored data that has been protected for integrity.

[0038] Furthermore, establish internal standardized interfaces and external interface interfaces.

[0039] Incorporate internal standardized interfaces into the periodic management section of the management module.

[0040] External interfaces are incorporated into the periodic management section of the management module.

[0041] Receive invocation instructions from third-party API callers.

[0042] Determine whether the calling instruction is an instruction that calls an internal standardized interface.

[0043] If the instruction is to invoke an internal standardized interface, then the parsing script of the internal standardized interface will be invoked based on the internal standardized interface.

[0044] If the calling instruction is an instruction of an external interface, then the parsing script of the external interface will be called based on the external interface.

[0045] Specifically, the Interface Management submodule is the lifecycle management division of the Management module. This division receives and manages both internal standardized interfaces and external interface interfaces. The Interface Management submodule is responsible for the full lifecycle management of both internal standardized interfaces and external interface interfaces. For internal interfaces, it must support creation categorized by business domain and function type, defining unified interface specifications, including fixed parameter names, data formats, calling protocols, and return code rules. It should also provide automatic generation and version management of interface documentation. For external interfaces, it must implement association mapping with third-party interfaces, supporting operations such as interface creation, editing, enabling, disabling, and decommissioning, while recording the interface's change history for easy traceability and rollback. The lifecycle management division possesses real-time and comprehensive monitoring capabilities, enabling real-time tracking of interface call status, including detailed information such as the initiation time, response time, call result (success / failure), and error reason for each call. By setting multi-dimensional monitoring metrics (such as API call success rate, average response time, peak concurrency, etc.), when the metrics exceed the preset threshold, an alarm mechanism (such as SMS, email, system pop-up, etc.) can be automatically triggered to promptly notify relevant operations and maintenance personnel, ensuring that abnormal situations during the API call process can be quickly detected and handled, and guaranteeing the stability of API calls and business continuity.

[0046] Furthermore, it saves the calling instructions from third-party interface callers.

[0047] Select a calling instruction from a third-party API caller.

[0048] Determine whether the timestamp of the selected call instruction matches the system time.

[0049] If the timestamp of the selected call instruction matches the system time, then return to the step of receiving the call instruction from the third-party interface caller, and return to the step of selecting a call instruction from a third-party interface caller, until all call instructions have been selected.

[0050] If the timestamp of the selected call instruction does not match the system time, the call instruction from the selected third-party interface caller will be included in the interface data monitoring folder.

[0051] Specifically, the Interface Data Monitoring folder belongs to the Interface Statistics submodule, which requires multi-dimensional and in-depth statistical analysis of interface call data. It can statistically analyze interface call frequency and data traffic (input / output data volume) by time dimension (e.g., hourly, daily, weekly, monthly). It can also statistically analyze interface calls from different internal systems by caller dimension. Furthermore, it can statistically analyze success rates, exception rates, and other indicators for various interface types. By generating intuitive statistical reports (e.g., bar charts, line charts, pie charts), it provides platform administrators with a basis for interface performance analysis and business popularity assessment, helping to optimize interface resource allocation and improve performance.

[0052] Based on the interface monitoring submodule and the timestamp of the call command, the server has real-time and comprehensive monitoring capabilities, and can track the call status of the interface in real time, including detailed information such as the initiation time, response time, call result (success / failure), and error reason for each call.

[0053] Further, select a call command from the interface data monitoring folder.

[0054] By utilizing the data information from the call command, one or more of the following can be determined: the server model, IP address, request parameter details, status code returned by the interface, response data, and call duration of the third-party interface caller.

[0055] Include the IP address, request parameter details, API return status code, and response data in the API call log.

[0056] Return to the selected interface data monitoring folder and select one of the call commands until all call commands in the interface data monitoring folder have been selected.

[0057] Specifically, the operation of the interface execution engine begins with the triggering of the internal interface entry point. This entry point acts as the "start button" for the entire process, bearing the important responsibility of receiving external requests and initiating subsequent processing. Once the engine intervenes at this entry point, its primary task is to accurately determine whether any plugins exist. This step acts as a "gatekeeper" in the process, quickly identifying whether there are any callable plugin components in the system by scanning specified paths or configuration information through a preset detection mechanism.

[0058] If a plugin is detected, the engine will initiate the reading process for the corresponding JAR file. During this process, the engine will locate the target JAR file's storage location based on the plugin's registration information or path index. Then, it will load the bytecode data from the JAR file into memory using file streams or other methods, preparing for subsequent class loading. Next, the engine will focus on loading the InterfaceList class within the JAR file. This step requires the class loader to parse the bytecode data into a Class object that can run in the JVM, ensuring that the structure and methods of the InterfaceList class can be correctly recognized by the engine.

[0059] After class loading is complete, the engine will call the getMethod method to retrieve the specific method required in the InterfaceList class. The getMethod method will perform a precise match in the method collection of the InterfaceList class based on key information such as the method name and parameter types, and finally return the corresponding Method object. This object acts as a "bridge" to build a channel for subsequent method calls.

[0060] Once the target method is obtained, the engine will actually access the interface encapsulated in that class through the `invoke` method. During the execution of the `invoke` method, the engine will pass the corresponding input data according to the parameter requirements defined in the method, triggering the business logic processing inside the interface, such as data querying, calculation, and transformation operations. After the interface completes all processing and generates return data, the `invoke` method will return this data to the engine. At this point, the entire interface call process is considered complete, and the engine can further pass the returned data to the requester or perform subsequent processing operations as needed.

[0061] Furthermore, based on the project data structure of the local database, core files for internal standardized interfaces are established.

[0062] The project data structure calls the local database, and the core files for establishing external interfaces are created.

[0063] The core files of the internal standardized interfaces and the core files of the external interface are incorporated into the management module.

[0064] The management module is used to perform key authentication on the core files of the internal standardized interfaces and the core files of the external interface.

[0065] Obtain the management module with key management permissions.

[0066] Specifically, management modules typically have key management permissions, which generally belong to the server itself. Management modules with key management permissions ensure that when calling an API, the key is the core credential for ensuring communication security; its generation and use are indispensable parts of the API call process. Only by generating the key through a standardized process and correctly including it during the call can the system verify and successfully access the API.

[0067] The generation of keys must adhere to strict security standards: the system automatically generates unique keys based on high-strength encryption algorithms (such as SHA-256), typically no less than 16 characters in length, containing uppercase and lowercase letters, numbers, and special characters to ensure randomness and complexity, preventing easy cracking. After generation, the key is bound to the caller's identity and associated with specific interface access permissions (such as allowing only query interfaces or limiting the number of daily calls), forming a precise "one key, one permission" control.

[0068] During the actual call, the caller must include the key in the API request in a specified manner (such as in the request header or encrypted fields of the request parameters). Upon receiving the request, the server will first verify the key's validity: checking if the key is active (not expired, not frozen), if it matches the caller's identity, and if the caller has the necessary permissions to access the target API. Only after all verifications pass will the server process the API request and return the result. If the key is missing, invalid, or lacks sufficient permissions, the system will directly reject the call and return an error message (such as "Key verification failed" or "No access permission").

[0069] This "key-first" mechanism can effectively intercept unauthorized malicious calls, prevent the interface from being illegally accessed or abused, and at the same time, by binding keys with permissions, it can achieve fine-grained control over interface calls, building the first line of security for interface communication.

[0070] Furthermore, by utilizing the key management permission class in the management module, the core files of the internal standardized interface or the core files of the external interface can be called.

[0071] Generate decoding scripts based on the core files of internal standardized interfaces or external interface core files.

[0072] Use a decoding script to parse the call instructions.

[0073] Obtain the core file configuration format for internal standardized interfaces or the core file configuration format for external interface interfaces.

[0074] Configure the format using core files.

[0075] Determine the parameters and configuration information of the API plugin's usage instructions.

[0076] Based on the parameters and configuration information of the exploit command, the exploit command for the interface plugin is obtained.

[0077] Specifically, a class is an encoded structure for algorithmic data. Using the key management and permission class in the management module, one can call the core files of internal standardized interfaces or the core files of external interface interfaces.

[0078] In API status management, setting the public nature of an API is a crucial aspect of ensuring system security and controllable access. Developers can flexibly choose the public status of an API during the API creation or configuration phase based on business needs: setting APIs intended for external system calls to "public" allows them to be invoked externally through a standardized authorization process.

[0079] The automatic detection mechanism for interface availability provides real-time monitoring and assurance for system stability. This mechanism continuously monitors the response status of the interface through preset detection rules (such as sending probe requests at regular intervals), including whether the response time is within the threshold range and whether the returned status code meets expectations (such as 200 series success codes).

[0080] When an anomalies are detected (such as timeouts or frequent 5xx errors), the system automatically triggers an alarm mechanism, notifying operations and maintenance personnel via email and other channels, and simultaneously recording log information such as the anomaly time, error type, and scope of impact. Combined with historical monitoring data, availability trend reports can also be generated, intuitively presenting the stability performance of the interface, providing data support for performance optimization and troubleshooting, and ultimately achieving a monitoring upgrade from passive response to proactive prevention.

[0081] Furthermore, the interface plugin module is initialized based on the usage instructions.

[0082] Obtain the interface plugin module with basic configuration.

[0083] Load the connection configuration file for the interface plugin module.

[0084] Parse the connection configuration file of the interface plugin module to enable the interface plugin module to complete the startup process.

[0085] Based on the usage instructions, a request instruction is sent to the interface plugin module.

[0086] Obtain access to third-party databases via third-party interfaces.

[0087] Specifically, plugin lifecycle management is a crucial mechanism to ensure that plugins are correctly loaded, run, and unloaded throughout their usage. In the initialization phase, the plugin is created and loads its basic configuration, performs necessary environment checks, and registers necessary system hooks and listeners. In the configuration phase, the interfaceConfig.yml configuration file is loaded and parsed, the integrity and validity of the configuration are verified, and connections with external systems are initialized. In the startup phase, background threads or scheduled tasks are started, externally provided interface services are registered, and plugin readiness events are published. In the runtime phase, external requests and events are processed, connection states with external systems are maintained, and periodic tasks and data synchronization are executed. In the pause phase, new requests are stopped, periodic tasks are paused, and the current state is maintained without performing new operations. In the resume phase, request acceptance resumes, periodic tasks are resumed, and connections with external systems are restored. In the destruction phase, all background threads and tasks are stopped, all occupied system resources are released, and all registered services and listeners are unregistered.

[0088] Furthermore, based on one of the access-type third-party interfaces, the registration information and index path of the third-party database are determined.

[0089] By utilizing the registration information of a third-party database, the storage block location of the third-party database can be determined.

[0090] Based on the index path and storage block location of the third-party database, a table showing the storage location of the target data information for receiving the call instruction is generated.

[0091] Define the storage location table as the data information of a third-party database.

[0092] Receive data from third-party databases.

[0093] Specifically, access-type third-party interfaces can enable data communication connections between the server and third-party databases.

[0094] The management module provides comprehensive control over interfaces through a visual console, comprising six sub-modules that collaboratively support full lifecycle management of interfaces. The plugin management sub-module is responsible for uploading, version control, dependency management, and permission allocation of interface plugins, serving as the core entry point for plugin lifecycle management. The interface management sub-module focuses on interface-level control, including interface metadata maintenance, status switches, routing configuration, and permission binding, enabling fine-grained interface management. The interface monitoring sub-module collects real-time interface call metrics (such as QPS, response time, and success rate), tracks anomalies, and triggers alarms to ensure interface stability. The interface statistics sub-module performs multi-dimensional analysis based on historical data, generating statistical reports to support decision-making. The tag configuration sub-module builds a multi-level tag system, enabling interface classification, association, and rapid retrieval, improving interface management efficiency. The key configuration sub-module manages the generation, permission binding, and rotation of interface call keys, ensuring interface call security through key authentication.

[0095] Furthermore, the amount of data to be stored is determined by using the storage location table and the index path of the third-party database.

[0096] Based on the instructions, the request parameter details of the third-party interface caller are determined.

[0097] Use the request parameter details to determine the actual amount of data to be stored.

[0098] The local database is invoked based on the actual amount of data stored.

[0099] Establish an input-type information communication interface for the local database.

[0100] Establish a communication connection between the input-type information communication interface and the third-party interface caller.

[0101] Specifically, the input-type information communication interface is used for data communication connections between the server itself and the local database.

[0102] Understandably, during the upload trigger phase, after logging into the system, the operator accesses the dedicated plugin management module. The user clicks a button to open a local file selection window, from which they select the completed plugin JAR file (ensuring the JAR file is in the correct format, undamaged, and contains all resources required for the plugin to run). After selection, the system automatically verifies the file type (only .jar format is allowed). If it does not meet the requirements, a prompt will appear and the upload will be terminated. If it does meet the requirements, the upload process will begin, with the interface displaying the upload progress in real time (e.g., percentage, progress bar) to allow the user to monitor the status.

[0103] During the file storage phase, after the upload is complete, the system automatically saves the plugin JAR file to a designated directory on the server according to preset rules. This directory is typically well-planned, with robust access control (e.g., only system services can read and write, preventing unauthorized access or tampering) and a clear directory structure (e.g., categorized by plugin type, version number, etc., facilitating later management and retrieval). Simultaneously, the system performs integrity verification on the saved JAR file (e.g., calculating the file hash value and comparing it with the hash value used during upload) to ensure the file has not been damaged or tampered with during transmission and storage. If verification fails, the system automatically deletes the erroneous file and prompts the user to re-upload.

[0104] During the configuration file reading phase, the system automatically identifies and decompresses the saved plugin JAR package (or directly reads the file at a specified path within the JAR package), locating the interfaceConfig.yml configuration file. This configuration file is crucial for the plugin's interaction with the system and typically contains basic plugin information (such as name, version, developer, and description), interface definitions (such as interface name, request method, parameter format, and return value type), dependency information (such as required system services and other plugin versions), and runtime parameters (such as timeout and resource limits). The system reads this configuration file using a specialized parsing tool (such as a YAML-compatible parsing library). If the file is missing, has an incorrect format, or is missing critical information, the system will log an error and provide feedback to the user regarding the specific problem (such as "interfaceConfig.yml file not found" or "plugin name field missing in configuration file"), pausing the deployment process.

[0105] During the database write phase, after successfully reading the interfaceConfig.yml configuration file, the system performs structured processing on the information within, mapping the data to the corresponding table structures in the database. For example: The plugin basic information table stores the plugin name, version, developer, description, upload time, and storage path. The interface information table records the interface name, request method, parameter list, and return value definition. The dependency table associates the plugin with required system services and other plugins. During the write process, the system initiates a database transaction to ensure that all related data is either written successfully or fails and rolls back (to avoid data inconsistency). If database connection errors or primary key conflicts occur during the write process (such as duplicate uploads of the same plugin and version), the transaction is rolled back, and the user is notified. Simultaneously, any saved JAR files are deleted (or marked as invalid).

[0106] This invention also provides a system for integrating third-party interfaces, comprising: A server for executing the method of integrating third-party interfaces.

[0107] The memory is connected in communication with the server.

[0108] Specifically, the system integrates third-party interfaces and utilizes a server to build a fully functional, efficient, and stable third-party interface aggregation platform. Its core requirements revolve around the collaborative operation of the interface module and the management module. Through systematic design and implementation, it achieves efficient aggregation, secure invocation, flexible control, and full lifecycle management of third-party interfaces. The storage and server communicate with each other, completely solving the problems of low reusability, large impact of changes, and complex management in the traditional interface docking mode.

[0109] As the core execution layer for the platform to access and convert third-party interfaces, the interface module must possess robust interface plugin module integration capabilities. This module needs to build a standardized plugin integration framework capable of seamlessly supporting various third-party interface plugins (encapsulated as JAR files). Each plugin must have built-in complete processing logic for the corresponding third-party interface, including but not limited to automatic parsing of diverse protocols (such as HTTP, TCP, MQTT, etc.), intelligent validation of multi-scenario parameters (required / optional, format validation, etc.), encryption and decryption processing of different encryption methods (such as MD5, SHA256, RSA, etc.), and autonomous fault tolerance mechanisms for abnormal situations (such as timeouts, connection failures, etc.). Through this pluggable design, the interface module can quickly adapt to third-party interfaces of different types and manufacturers. When adding a new third-party interface, only the corresponding plugin needs to be integrated to complete the connection, without modifying the underlying architecture of the module. This provides solid technical support for subsequent conversion from external interfaces to internal interfaces, ensuring that the platform can flexibly and quickly integrate with various third-party systems to meet the diverse business integration needs of enterprises. As the central control layer of the platform, the management module needs to include multiple fully functional sub-modules to achieve comprehensive and refined management of interfaces and plugins.

[0110] The beneficial effects of this invention are: The method for integrating third-party interfaces achieves integration and aggregation of multiple third-party interfaces by constructing a unified middleware architecture. The core is to build an interface adaptation layer, which standardizes and encapsulates the protocol formats and parameter rules of different interfaces, eliminating compatibility issues caused by interface differences. Simultaneously, a data conversion engine is established to automatically map third-party returned data to the system's internal format. The middleware layer also handles request routing, load balancing, and exception handling, dynamically invoking different interface resources according to business needs and aggregating scattered return results into a unified output. This approach reduces the development complexity of directly connecting to multiple interfaces while improving the system's management efficiency and scalability for third-party services.

[0111] Based on the interface module, it receives call instructions from third-party interface callers, parses these instructions, and obtains usage instructions for the interface plugin. Based on these usage instructions, the same version of the interface can be integrated into different projects. Later, the development and maintenance teams can use the same interface documentation to write identical parameter validation and protocol parsing logic. The interface and its protocol can be consistent, and developers from different projects can use the calling code, simplifying the programming logic for later maintenance. This improves the development efficiency of code and programs integrating third-party interfaces, especially during intensive project periods, where a small number of people can maintain this repetitive work, allowing specialized technical teams to focus on core business. Interfaces with consistent coding logic will not cause the collapse of the entire middleware architecture or cascading network accidents when changed or when interface devices are maintained, resulting in high network system stability based on the middleware architecture. Changes to third-party interfaces are common, such as manufacturers upgrading interface versions, adjusting field names, or protocol formats. Even minor adjustments to external interfaces, such as changing a field from required to optional, can cause the calling logic of internal systems to malfunction, requiring line-by-line investigation and code modification. Using the plugin module can solve the problem of multiple internal systems simultaneously calling the same interface, such as ERP and MES systems sharing a device status query interface. Before and after an interface change, it is not necessary to modify the interface code of all systems simultaneously. This greatly reduces the modification cycle. Especially in a production environment, interface changes can be reused across vendors, protocols, and versions, which is beneficial to business continuity.

[0112] The server, based on the usage command, calls the management module to connect to the local database to store data from the third-party database. By using the command to connect to the local database, and utilizing the received data from the third-party database and the managed local database, the data from the third-party database is stored, reducing interface heterogeneity, lowering management complexity, and improving scalability. Feeding the usage command of the interface plugin to the interface plugin module allows for the use of different third-party vendors' interface protocols and data formats, enabling unified use of interface rules at the data level across different product lines from the same vendor. The development team can simplify the writing of a unified parsing module for each interface, reducing development time for adapting different protocols. The interface plugin module has globally controlled interface management status, such as configuring call permissions and timeouts for a particular vendor's interface separately in different projects. When adding a third-party system, the plugin module can be used to redevelop the entire logic from protocol parsing to business adaptation, allowing the plugin module to quickly respond to business needs. Attached Figure Description

[0113] Figure 1 This is a flowchart illustrating a method for integrating third-party interfaces according to an embodiment of the present invention.

[0114] Figure 2This is a schematic diagram of the structure of a system integrating a third-party interface, as provided in an embodiment of the present invention.

[0115] Figure label: 100 - Server; 200 - Storage. Detailed Implementation

[0116] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0117] like Figure 1 As shown, the present invention provides a method for integrating third-party interfaces, comprising: S100 receives call instructions from third-party interface callers.

[0118] Specifically, S111 establishes internal standardized interfaces and external interface interfaces.

[0119] S112 incorporates the internal standardized interface into the periodic management section of the management module.

[0120] S113 incorporates external interface interfaces into the periodic management section of the management module.

[0121] S114 receives the invocation instructions from the third-party interface caller.

[0122] S115, determine whether the call instruction is an instruction that calls an internal standardized interface.

[0123] S116a, if the calling instruction is an instruction to call the internal standardized interface, then the parsing script of the internal standardized interface is called based on the internal standardized interface.

[0124] S1116b: If the calling instruction is an instruction of the external interface, then the parsing script of the external interface is called based on the external interface.

[0125] S121, save the calling instructions from the third-party interface caller.

[0126] S122, Select a calling instruction from a third-party interface caller.

[0127] S123, determine whether the timestamp of the selected call instruction matches the system time.

[0128] S124a, if the timestamp of the selected call instruction matches the system time, then return to the step of receiving the call instruction from the third-party interface caller, and return to the step of selecting a call instruction from the third-party interface caller, until all call instructions have been selected.

[0129] S124b: If the timestamp of the selected call instruction does not match the system time, the call instruction of the selected third-party interface caller will be included in the interface data monitoring folder.

[0130] S131, Select a call command from the interface data monitoring folder.

[0131] S132 uses the data information from the call instruction to determine one or more of the following: the server model, IP address, request parameter details, status code returned by the interface, response data, and call duration of the third-party interface caller.

[0132] S133, the IP address, request parameter details, interface returned status code, and response data are included in the interface call log.

[0133] S134, return to one of the call instructions in the selected interface data monitoring folder, until all call instructions in the interface data monitoring folder have been selected.

[0134] Understandably, the plugin management submodule is responsible for the entire lifecycle management of plugins, providing convenient functions such as plugin upload, installation, version update, and uninstallation. It supports plugin version control, recording plugin version information and update logs for easy tracking of plugin iterations. It also has plugin dependency management capabilities; when a plugin needs updating or uninstallation, it can automatically detect and prompt its associated interfaces and dependent components, preventing interface call anomalies due to improper plugin operations. Furthermore, it needs to support plugin canary releases and test environment deployments to ensure the security and stability of the plugin update process. By setting multi-dimensional tags for interfaces or plugins (such as the business line to which the interface belongs, the third-party vendors the plugin adapts to, and the importance level of the interface), it enables rapid classification, retrieval, and filtering of interfaces and plugins. Users can quickly locate the required interfaces or plugins through tag combinations, improving management efficiency, especially when the number of interfaces and plugins is large, significantly reducing management complexity.

[0135] The key configuration submodule focuses on ensuring the security of interface communication, and is responsible for the centralized management of various key information (such as API keys, encryption keys, authentication tokens, etc.) involved in the interface call process. It supports key generation, storage, updating, and revocation operations, employs encrypted storage to ensure key information security, and strictly controls key access permissions. Only authorized personnel can perform key-related operations, preventing security risks caused by key leakage and providing a solid guarantee for secure interface calls.

[0136] S200 parses the call instructions to obtain the usage instructions for the interface plugin.

[0137] Specifically, S211 is the core file for establishing internal standardized interfaces based on the project data structure of the local database.

[0138] S212 is the core file for calling the project data structure of the local database and establishing the external interface.

[0139] S213 incorporates the core files of internal standardized interfaces and the core files of external interface into the management module.

[0140] S214 utilizes the management module to perform key authentication on the core files of the internal standardized interfaces and the core files of the external interface. S215, obtain the management module with key management permissions.

[0141] S221 utilizes the key management permission class in the management module to call the core files of the internal standardized interface or the core files of the external interface.

[0142] S222 generates a decoding script based on the core file of the internal standardized interface or the core file of the external interface.

[0143] S223 uses a decoding script to parse the call instruction.

[0144] S224, obtain the core file configuration format of the internal standardized interface or the core file configuration format of the external interface.

[0145] S225 utilizes the core file configuration format.

[0146] S226, determine the parameters and configuration information of the interface plugin's exploitation instructions.

[0147] S227, based on the parameters and configuration information of the application instruction, obtain the application instruction for the interface plugin.

[0148] Understandably, the plugin management system provides users with a convenient and efficient plugin upload experience through an intuitive and user-friendly visual interface. Users do not need complex technical backgrounds; they can complete the plugin file upload process with simple clicks. The system automatically performs format verification and compatibility checks on uploaded plugins to ensure they function correctly.

[0149] Regarding parameter default settings, the interface design is simple and clear, with various parameters logically categorized and displayed. Users can flexibly configure the plugin's parameters and set default values ​​according to their actual needs. These default values ​​will automatically take effect when the plugin runs, reducing tedious repetitive settings and improving work efficiency. The system also provides parameter descriptions and examples to help users better understand and set the various parameters.

[0150] To ensure the availability of plugin interfaces, the system includes a built-in online testing function. Users can directly initiate interface test requests through the interface. The system will simulate a real-world operating environment, comprehensively testing the interface's response speed, data accuracy, and other aspects, and returning the test results in real time. The test results are displayed in text format, including detailed information such as request status, response time, and error messages, allowing users to quickly locate and resolve problems. Through online testing, users can promptly identify and fix potential interface issues before the plugin is officially deployed, ensuring the plugin's stable operation.

[0151] In addition, the system supports the management of uploaded plugins, including viewing plugin information, modifying parameter settings, updating plugin versions, and deleting useless plugins. All operations can be completed through a visual interface, making the process simple and intuitive, greatly reducing the difficulty of plugin management and improving the user experience.

[0152] During the integration of the API and plugin API, a systematic configuration mechanism is required to achieve bidirectional connectivity. First, basic integration parameters are set through a visual configuration interface: the request type is clearly defined based on business scenario requirements, covering common methods such as GET and POST, ensuring that the data interaction method matches the communication specifications of the plugin API; suitable functional plugins are selected from a pre-defined plugin library, taking into account the plugin's functional characteristics, version compatibility, and performance metrics for comprehensive selection; and basic attributes such as plugin activation status and priority are also configured.

[0153] The system provides flexible custom configuration capabilities for the parameters required for plugin operation: it supports assigning fixed values ​​to required parameters and also allows associating input parameters or context data of the main interface through variable mapping, so as to meet the dynamic adaptation needs of plugins in different business scenarios.

[0154] After completing the above configuration, the interface's metadata will be fully saved to the database. This metadata includes key information such as interface identifier, request type, target plugin information, and parameter mapping rules, forming a traceable configuration file. Through this series of configuration and storage operations, the automatic conversion from the main interface to the plugin interface is ultimately achieved, enabling the main interface to seamlessly call the plugin's functional modules.

[0155] S300 feeds back the usage instructions of the interface plugin to the interface plugin module.

[0156] Specifically, S310 initializes the interface plug-in module based on the usage instructions.

[0157] S320, obtains an interface plug-in module with basic configuration.

[0158] S330, loads the connection configuration file for the interface plugin module.

[0159] S340 parses the connection configuration file of the interface plugin module to enable the interface plugin module to complete the startup program.

[0160] S350 sends a request command to the interface plug-in module according to the utilization command.

[0161] S360 provides access to third-party interfaces for third-party databases.

[0162] Understandably, a visual configuration interface allows plugin interfaces to be efficiently converted into internal call interfaces. This process eliminates the need for complex code development, significantly lowering the technical barrier. The interface employs intuitive interaction and a modular configuration area. Developers or operations personnel can complete the conversion in just a few visual steps. The system automatically loads the plugin's basic information (such as interface name, request method, parameter structure, etc.), as shown below.

[0163] S400 receives data information from a third-party database transmitted by the interface plug-in module.

[0164] Specifically, S410, based on one of the access-type third-party interfaces, determines the registration information and index path of the third-party database.

[0165] S420 uses the registration information of a third-party database to locate the storage block of the third-party database.

[0166] S430 receives a table of the storage location of the target data information for the call command based on the index path and storage block location of the third-party database.

[0167] S440 defines the storage location table as data information from a third-party database.

[0168] S450 receives data from a third-party database.

[0169] Understandably, after a successful database write, the system determines that the plugin upload and deployment are complete, automatically updating the plugin management module's interface display and marking the plugin's status as "deployed" or "pending activation" (depending on system rules, some plugins may require manual activation). Simultaneously, the system generates a deployment log, recording the entire plugin deployment process (including upload time, storage path, configuration information summary, database write results, etc.), facilitating later troubleshooting and auditing. Users can view detailed information about newly deployed plugins in the plugin management interface and perform subsequent operations as needed (such as enabling, disabling, updating, uninstalling, etc.).

[0170] In addition, to improve reliability, some systems will perform simple initialization checks after deployment (such as loading the plugin's base class and verifying the existence of serious runtime errors). If the checks pass, the deployment is confirmed to be successful; if errors exist, the plugin status is marked as "deployment failed" and the user is prompted to check plugin compatibility.

[0171] Through the above process, the entire process of plugin upload and deployment is automated, which not only ensures the convenience of operation, but also ensures the accuracy of data and the stability of the system through multiple verifications and transaction control.

[0172] The S500 uses commands to call the management module to connect to the local database.

[0173] The S600 uses the command information to connect to the local database and then calls the local database.

[0174] The S710, based on the storage location table and the index path of the third-party database, applies the cylinder algorithm to divide the data to be stored into blocks in order to calculate the amount of data to be stored.

[0175] Specifically, in step S711, the storage location table is parsed to obtain the initial physical address set of the target data in the third-party database. Simultaneously, the index path of the third-party database is parsed to obtain the logical hierarchy sequence for accessing the target data.

[0176] S712, based on the logical hierarchy sequence, construct a virtual data block cylinder model. Specifically, the logical hierarchy sequence is mapped to the height dimension of the cylinder, and the initial physical address set is mapped to the circular area at the base of the cylinder.

[0177] S713, along the height dimension of the cylinder, that is, according to the logical hierarchy sequence, the virtual data block cylinder is divided into equal-volume or non-equal-volume segments according to preset rules, so as to divide the data to be stored into several continuous data block units.

[0178] S714 processes each data block unit sequentially, calculates its specific storage segment size in the third-party database based on its radial and angular position coordinates in the cylindrical model, summarizes the storage segment sizes corresponding to all data block units, and generates the amount of data to be stored.

[0179] The S720, based on the amount of data to be stored and combined with the instructions, parses out the request parameter details of the third-party interface caller; the request parameter details include data format, field type and business rule information.

[0180] The S730 uses the request parameter details to calibrate the amount of data to be stored, and uses an encryption algorithm to encrypt and verify the calibrated amount of data to generate the actual amount of data to be stored.

[0181] Specifically, in step S731, the request parameter details are read, and the data format specifications, field type definitions, and valid data load indications in the business rule information are extracted.

[0182] S732 compares the amount of data to be stored with the valid data load indication to obtain the calibrated data amount.

[0183] S733, the calibrated data volume is used as input plaintext to generate a corresponding encrypted verification value for the data volume.

[0184] S734, the calibrated data volume and the encrypted verification value of the data volume are bound together and combined to form the final generated data volume of the actual stored data that has been protected by integrity.

[0185] S740: Based on the actual amount of data to be stored, the storage resources of the local database are invoked. After the local database storage resources are allocated, an input communication interface for the local database is established. A secure communication connection is established between the input communication interface and the third-party interface caller. Through the secure communication connection, the third-party interface caller accesses the data information of the local database. Specifically, S751: Using the storage location table and the index path of the third-party database, the amount of data to be stored is determined.

[0186] S752, based on the exploit instruction, determines the request parameter details of the third-party interface caller.

[0187] S753 uses the request parameter details to determine the actual amount of data to be stored.

[0188] S754 calls the local database based on the actual amount of data stored.

[0189] S755 is an input-type information communication interface for establishing a local database.

[0190] S756 establishes a communication connection between the input information communication interface and the third-party interface caller.

[0191] Understandably, to ensure the stable operation and efficient maintenance of system interfaces, it is necessary to build a comprehensive interface monitoring system to track the entire chain of interface calls in real time.

[0192] At the interface call monitoring level, it is necessary to record key information of each interface call in real time, including call initiation time, caller identification (such as service name, IP address), request parameter details, interface return status code and response data, call time and other core indicators. Through a visual dashboard, the call frequency trend, success rate fluctuation, average response time change and other data of the interface can be dynamically displayed to help operation and maintenance personnel intuitively grasp the interface's operating load and health status.

[0193] The presentation of API call logs must balance completeness and traceability. Log content should include timestamps accurate to milliseconds, unique identifiers for the caller and callee, complete request and response messages (sensitive information must be anonymized), and details such as exception stack traces generated during the call. It should also support multi-dimensional filtering and retrieval of logs by time range, API name, call status, and caller, facilitating quick location of specific call records and providing raw data support for troubleshooting.

[0194] Interface availability testing requires establishing a routine monitoring mechanism. This involves periodically sending simulated requests to the interface (covering request parameters for both normal and edge scenarios) to verify key metrics in real time, such as the interface's response status (e.g., whether the HTTP status code is 200, whether the business status code meets expectations), response time (whether it is within preset thresholds), and response data format (whether it is consistent with the interface documentation). When anomalies such as timeouts, error responses, or excessively long response times are detected, an alarm mechanism must be triggered immediately, recording the time of occurrence, duration, and type of the anomaly. This ensures that operations and maintenance personnel can intervene promptly and guarantee the continuous availability of the interface service.

[0195] To thoroughly analyze the call patterns and load characteristics of APIs, it is necessary to conduct accurate statistics on the number of API calls across multiple time dimensions and use diverse visualization charts to intuitively present the data trends.

[0196] At the time-based statistical level, a multi-level statistical system covering years, months, days, and hours needs to be constructed. When calculating annual statistics, the total number of API calls for each calendar year needs to be accumulated, and the distribution of call volume in each quarter of each year needs to be recorded. This reflects the long-term growth or fluctuation trend of API calls, providing data support for system expansion planning and business development forecasting. Monthly statistics need to be refined to the number of calls for each calendar month. By comparing the call data for the same month in different years, seasonal fluctuation patterns can be clearly identified.

[0197] Daily statistics need to be accurate to the number of calls per calendar day. Combining this with the attribute classification analysis of weekdays and rest days can effectively uncover the correlation between API calls and business operation rhythm. For example, the number of API calls on weekdays is usually higher than on rest days. Hourly statistics are the core of real-time monitoring. They need to accumulate the number of calls hourly to accurately capture peak traffic periods (such as 9 am to 11 am and 7 pm to 9 pm) and off-peak periods within the day, providing real-time reference for dynamic resource scheduling and peak stress testing.

[0198] The choice of visualization charts should match the statistical dimensions and analysis objectives. Annual and monthly statistical data are suitable for display using line charts, which clearly present the annual growth curve of call volume or the month-on-month change trend through continuous lines. Key nodes (such as interface version updates, business activity promotions, etc.) can be marked in the chart to facilitate correlation analysis of factors affecting call volume.

[0199] Daily statistics can be presented using bar charts, generating independent bars for each day. The height of the bars visually compares the differences in call volume across different days. Weekly aggregation is also supported, allowing for quick identification of call volume patterns for each workday within a week. Hourly statistics can be presented using heatmaps and line charts. Heatmaps use 24 hours as the horizontal axis and date as the vertical axis, visually representing the distribution of call volume across different hourly segments through color depth. Line charts can track the dynamic changes in call volume every hour of the day in real time, and any abnormal fluctuations exceeding a threshold can be immediately flagged for monitoring.

[0200] In addition, all visualization charts must support interactive operations, such as clicking on a data node to view specific values, dragging the timeline to filter data for a specific period, and switching between different interfaces for comparative analysis.

[0201] S800, based on the call command, feeds back data information from the local database and / or third-party database to the third-party interface caller.

[0202] Specifically, in the practice of integrating third-party interfaces, the methods for integrating third-party interfaces demonstrate efficient operation and flexible response capabilities across three key dimensions: reusability, change isolation, and management extension. Breakthroughs in reusability have achieved over 90% logic reuse across cross-vendor, cross-protocol, and cross-version interfaces, improving development efficiency for similar interfaces by over 60%, and enabling global sharing of reusable components, reducing duplicate code. Interfaces from different vendors with similar functions may differ significantly in protocols, parameters, and encryption methods. For example, vendor A might use HTTP protocol, JSON format, and MD5 encryption for device status queries, while vendor B might use TCP protocol, binary format, and SHA256 encryption for the same function. Existing technologies require separate development of adaptation modules, making unified reuse impossible. When dealing with cross-protocol issues, upstream might use WebSocket for push, while downstream might require MQTT reception or FTP transmission, necessitating the development of dedicated modules for each protocol, making business logic difficult to reuse. After an interface version upgrade, such as changing the identifier from "userId" to "userCode," existing technologies need to be readjusted, and a compatibility layer cannot achieve reuse of the same core logic across multiple versions. The change isolation is quite thorough. When third-party interfaces change, the internal system adjustment rate drops to 0%, configuration adjustment complexity is reduced by 80%, and implicit development costs are reduced by 90%. Even minor adjustments to third-party interfaces can trigger a chain reaction in the middleware and internal systems. For example, if the logistics API changes the "recipient's phone number" field from "phone" to "mobile," SDK-based solutions need to modify the SDK code, and dependent systems need to be retested; the API gateway needs to modify the conversion plugin, and if it is not compatible, the internal system also needs to modify the database or front-end. Some technologies claim to isolate changes through configuration, but configuration adjustments are complex. For example, adding a new field requires reconfiguring the mapping, and if the internal system depends on the field, the business logic still needs to be modified, and the change propagation chain remains unbroken. The interface expansion cycle has been compressed from "days" to "minutes," while achieving 100% call monitoring and 100% key control, satisfying both rapid business iteration and ensuring system security and controllability in complex scenarios. Heavyweight architectures like ESBs, while capable of unified interface management, suffer from cumbersome expansion processes. Adding a new interface requires multiple approval and development stages, taking 2-3 weeks and making it difficult to respond to ad-hoc needs. Lightweight technologies such as basic API gateways and low-code platforms, while offering rapid expansion, lack global control. For example, the absence of call frequency statistics makes them susceptible to third-party rate limiting, fragmented permission management presents security vulnerabilities, and monitoring interface health is difficult. In complex scenarios, they fail to balance rigorous management with flexible expansion.

[0203] like Figure 2 As shown, the system for integrating third-party interfaces provided by the present invention includes: Server 100 is used to execute the method of integrating third-party interfaces.

[0204] The memory 200 is communicatively connected to the server 100.

[0205] Specifically, Server 100 uses commands to call the management module to connect to the local database, thereby storing data from the third-party database. By using these commands to access the local database, and utilizing the received data from the third-party database alongside the managed local database, the system stores the data, reducing interface heterogeneity, simplifying management, and improving scalability. Feeding the interface plugin's usage commands back to the interface plugin module allows for the use of different third-party vendors' interface protocols and data formats, ensuring unified data usage across different product lines from the same vendor. The development team can simplify the development of a unified parsing module for each interface, reducing development time for adapting different protocols. The interface plugin module provides globally controlled interface management, allowing for separate configuration of call permissions and timeouts for specific vendors' interfaces in different projects. When adding a third-party system, the plugin module can be used to redevelop the entire logic from protocol parsing to business adaptation, enabling rapid response to business needs.

[0206] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0207] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A method for integrating third-party interfaces, characterized in that, include: Receive invocation instructions from third-party API callers; Parse the call instructions to obtain the usage instructions for the interface plugin; Feedback the usage instructions of the interface plugin to the interface plugin module; Receive data information from a third-party database transmitted by the interface plugin module; Based on the command, the management module is invoked to connect to the local database; Use the command information to connect to the local database to call the local database; Based on the storage location table and the index path of the third-party database, the cylinder algorithm is applied to divide the data to be stored into blocks in order to calculate the amount of data to be stored. Based on the amount of data to be stored, and combined with the instructions, the request parameter details of the third-party interface caller are parsed out. The request parameter details include data format, field type, and business rule information; Using the request parameter details, the amount of data to be stored is calibrated, and the calibrated amount of data is encrypted and verified using an encryption algorithm to generate the actual amount of data to be stored. Based on the actual amount of stored data, the storage resources of the local database are called. After the local database storage resources are allocated, an input information communication interface for the local database is established. A secure communication connection is established between the input information communication interface and the third-party interface caller. Through the secure communication connection, the third-party interface caller accesses the data information of the local database. Based on the call command, data information from the local database and / or third-party databases is fed back to the third-party interface caller.

2. The method for integrating third-party interfaces according to claim 1, characterized in that, Based on the storage location table and the index path of the third-party database, the cylinder algorithm is applied to divide the data to be stored into blocks to calculate the amount of data to be stored, including: Parse the storage location table to obtain the initial physical address set of the target data in the third-party database; simultaneously, parse the index path of the third-party database to obtain the logical hierarchy sequence for accessing the target data; Based on the logical hierarchy sequence, a virtual data block cylinder model is constructed; wherein, the logical hierarchy sequence is mapped to the height dimension of the cylinder, and the initial physical address set is mapped to the bottom circular area of ​​the cylinder; Along the height dimension of the cylinder, that is, according to the logical hierarchy sequence, the virtual data block cylinder is divided into equal-volume or non-equal-volume segments according to preset rules, dividing the data to be stored into several continuous data block units. Each data block unit is processed sequentially. Based on its radial and angular position coordinates in the cylindrical model, its specific storage segment size in the third-party database is calculated. The storage segment sizes corresponding to all data block units are summarized to generate the amount of data to be stored.

3. The method for integrating third-party interfaces according to claim 2, characterized in that, Using the request parameter details, the amount of data to be stored is calibrated, and the calibrated data amount is encrypted and verified using an encryption algorithm to generate the actual amount of data to be stored, including: Read the request parameter details and extract the data format specifications, field type definitions, and valid data load indicators from the business rule information. The amount of data to be stored is compared with the effective data load indication to obtain the calibrated data amount; The calibrated data volume is used as input plaintext to generate a corresponding encrypted data volume verification value. The calibrated data volume is bound and combined with the encrypted verification value of the data volume to form the final generated data volume of the actual stored data that has been protected for integrity.

4. The method for integrating third-party interfaces according to claim 3, characterized in that, The process of receiving the invocation instruction from the third-party interface caller includes: Establish standardized internal interfaces and external interface connections; Incorporate internal standardized interfaces into the periodic management section of the management module; Incorporate external interfaces into the periodic management section of the management module; Receive invocation instructions from third-party API callers; Determine whether the calling instruction is an instruction that calls an internal standardized interface; If the instruction is to invoke the internal standardized interface, then the parsing script of the internal standardized interface will be invoked based on the internal standardized interface. If the calling instruction is an instruction of an external interface, then the parsing script of the external interface will be called based on the external interface.

5. The method for integrating third-party interfaces according to claim 4, characterized in that, The method of receiving the invocation instruction from the third-party interface caller also includes: Save the calling instructions from third-party API callers; Select a calling instruction from a third-party API caller; Determine if the timestamp of the selected call instruction matches the system time; If the timestamp of the selected call instruction matches the system time, then return to the step of receiving the call instruction from the third-party interface caller, and return to the step of selecting a call instruction from a third-party interface caller, until all call instructions have been selected; If the timestamp of the selected call instruction does not match the system time, the call instruction from the selected third-party interface caller will be included in the interface data monitoring folder.

6. The method for integrating third-party interfaces according to claim 5, characterized in that, The method of receiving the invocation instruction from the third-party interface caller also includes: Select a call command from the interface data monitoring folder; By using the data information in the call command, determine one or more of the following: the server model, IP address, request parameter details, status code returned by the interface, response data, and call duration of the third-party interface caller. Include the IP address, request parameter details, API return status code, and response data in the API call log; Return to the selected interface data monitoring folder and select one of the call commands until all call commands in the interface data monitoring folder have been selected.

7. The method for integrating third-party interfaces according to claim 6, characterized in that, The parsing of the call instructions to obtain the usage instructions for the interface plugin includes: Based on the project data structure of the local database, establish the core files for the internal standardized interface; The project data structure that calls the local database is used to create the core files for external interface interfaces; The core files of the internal standardized interfaces and the core files of the external interface are incorporated into the management module; The management module is used to perform key authentication on the core files of the internal standardized interfaces and the core files of the external interface. Obtain the management module with key management permissions.

8. The method for integrating third-party interfaces according to claim 7, characterized in that, The process of parsing the call instructions to obtain the usage instructions for the interface plugin also includes: The key management permission class in the management module is used to call the core files of the internal standardized interface or the core files of the external interface. Generate decoding scripts based on core files of internal standardized interfaces or core files of external interface interfaces; Use a decoding script to parse the call instructions; Obtain the core file configuration format of the internal standardized interface or the core file configuration format of the external interface; Configure the format using core files; Determine the parameters and configuration information of the API plugin's usage instructions; Based on the parameters and configuration information of the exploit command, the exploit command for the interface plugin is obtained.

9. The method for integrating third-party interfaces according to claim 8, characterized in that, The step of feeding back the usage instructions of the interface plugin to the interface plugin module includes: The interface plugin module is initialized based on the instructions used. Obtain an interface plugin module with basic configuration; Load the connection configuration file for the interface plugin module; Parse the connection configuration file of the interface plugin module to enable the interface plugin module to complete the startup program; Based on the usage instructions, send a request instruction to the interface plugin module; Obtain access to third-party databases via third-party interfaces.

10. A system integrating third-party interfaces, characterized in that, include: A server for performing the method of integrating third-party interfaces as described in any one of claims 1 to 9; The memory is connected in communication with the server.

Images