API open integration methods, devices, equipment, storage media, and program products

Abstract

This application discloses an API open integration method, apparatus, device, storage medium, and program product, relating to the field of big data technology. The method includes: constructing a layered API gateway open architecture, comprising an API tool layer, an API protocol access layer, and an API governance layer; deploying microservice components with corresponding functions in the API tool layer, API protocol access layer, and API governance layer, respectively; identifying the microservice components deployed in the API gateway open architecture and establishing logical relationships; establishing an API gateway internal and external interface list, defining multiple component external interfaces and component internal interfaces in the API gateway internal and external interface list; and defining the API gateway core data model of the API gateway open architecture based on the API gateway open architecture and the definitions of multiple component external and component internal interfaces, forming an API gateway integration development platform, which supports API open integration. According to the embodiments of this application, the scalability and security of the API gateway can be fully guaranteed.

Description

Technical Field

[0001] This application belongs to the field of big data technology, and in particular relates to an API open integration method, apparatus, device, storage medium and program product. Background Technology

[0002] With the rapid development of information and communication technologies such as the Internet, the Internet of Things, and cloud computing, most enterprises are already on the path of digital transformation. APIs (Application Programming Interfaces) have become the core carrier for connecting business operations and have generated huge profit potential. The rapidly growing scale and volume of API calls present more challenges to enterprise IT in terms of architecture and business models. As the overall trend of API development moves towards simplicity, integration, and standardization, more system boundary components are emerging. Against the backdrop of the trillion-dollar API economy, API gateways have come into being.

[0003] An API gateway built on Zuul's API open architecture technology is responsible for managing all tasks, involving accepting and processing tens of thousands of concurrent API calls, including traffic management, authorization and access control, monitoring, and API version management. Existing API gateway open technologies experience a gradual decline in performance and system scalability as the Groovy filter grows in size. The classic model of a typical thread pool with synchronous blocking threads is ineffective in handling high-concurrency scenarios.

[0004] Therefore, the industry still urgently needs a new API open integration solution to effectively ensure the scalability and security of API gateways. Summary of the Invention

[0005] This application provides an API open integration method, apparatus, device, storage medium, and program product, which can effectively ensure the scalability and security of the API gateway.

[0006] In a first aspect, embodiments of this application provide an API open integration method, which includes:

[0007] Construct a layered API gateway open architecture, which includes an API tool layer, an API protocol access layer, and an API governance layer;

[0008] Deploy corresponding microservice components at the API tool layer, API protocol access layer, and API governance layer respectively;

[0009] Identify the microservice components deployed in the API gateway's open architecture and establish logical relationships;

[0010] Establish an API gateway internal and external interface list, which defines multiple component external interfaces and component internal interfaces.

[0011] Based on the API gateway open architecture and the definitions of multiple component external and internal interfaces, the API gateway core data model of the API gateway open architecture is defined, forming the API gateway integration development platform. The API gateway integration open platform supports API open integration.

[0012] In some possible implementations, the API tool layer is used to provide API design, metadata definition, API development, API orchestration, and API testing capabilities;

[0013] The API protocol access layer is used to implement unified multi-protocol access, API authentication, and API authorization for APIs.

[0014] The API governance layer is used to implement online governance, lifecycle management, and operation and maintenance of APIs.

[0015] In some possible implementations, the API tool layer deploys: the APIDesign microservice component responsible for API design, metadata definition, and API compliance checks; the APIBuild microservice component responsible for online API development, testing, and release; and the APIOrchestration microservice component responsible for API business logic orchestration, supporting multiple orchestration forms.

[0016] The API protocol access layer is deployed with the API Access microservice component, which is used for unified multi-protocol access to APIs, API authentication, and authorization.

[0017] The API governance layer is deployed with APIGovernance microservice components for online governance, lifecycle management, and operation and maintenance of APIs.

[0018] In some possible implementations, the microservice components in the API Gateway Open Architecture communicate with the APIPortal in the API Gateway Open Architecture using a Restful API communication mode.

[0019] APIPortal provides an API interaction interface, supporting the publishing, subscription, and deployment of APIs.

[0020] In some possible implementations, the microservice components deployed in the API gateway open architecture are identified and logical relationships are established, including:

[0021] The API gateway open architecture adopts a microservice architecture. The front-end access of the API gateway open architecture uses Nginx for load balancing, the API Access microservice component is responsible for protocol access and conversion, and then the APIOrchestration microservice component is polled on a session basis.

[0022] The API Governance microservice component is used to deploy and upgrade APIs. It notifies the API Access microservice component via NATS messages, and the API Access microservice component pulls the APIs that need to be deployed and upgraded from the API Governance microservice component.

[0023] In some possible implementations, when the API Governance microservice component starts, it connects to the database DB and Nats and provides a RESTful interface for the API Access microservice component and APIPortal to use.

[0024] When the API Access microservice component starts, it loads API information into memory either by actively pulling from API Governance or by subscribing to Nats messages.

[0025] Among the possible implementations, a layered API gateway open architecture is constructed, including:

[0026] An open architecture for an API gateway is built using a distributed microservice framework based on asynchronous non-blocking NIO communication.

[0027] In some possible implementations, based on the API gateway open architecture and the definitions of multiple component external and internal interfaces, the core data model of the API gateway open architecture is defined, including:

[0028] Based on the open architecture of the API gateway and the definition of multiple external and internal interfaces of components, we construct the conceptual model, logical data objects, and physical storage model related to APIs, and define the data model for API-related business.

[0029] The data model includes at least one of the following: user data model, API asset data model, and API subscription and usage information data model.

[0030] In some possible implementations, the API gateway integration development platform is used to communicate and connect with business systems and third-party systems respectively; after obtaining the API gateway integration development platform, this API open integration method also includes:

[0031] The API gateway integration development platform responds to requests from third-party systems for inbound APIs, providing internal services of the business system to the third-party system for invocation;

[0032] And / or, the API gateway integrates with the open platform to respond to requests from business systems for outbound APIs and provide the interfaces of third-party systems to the business systems for invocation.

[0033] Based on the same inventive concept, in a second aspect, embodiments of this application provide an API open integration device, which includes:

[0034] The first building module is used to build a layered API gateway open architecture, which includes an API tool layer, an API protocol access layer, and an API governance layer.

[0035] The first deployment module is used to deploy microservice components with corresponding functions in the API tool layer, the API protocol access layer and the API governance layer respectively;

[0036] The first module is used to identify the microservice components deployed in the API gateway open architecture and establish logical relationships.

[0037] The second module is used to establish a list of internal and external interfaces of the API gateway, which defines multiple external interfaces and internal interfaces of components.

[0038] The first definition module is used to define the API gateway core data model of the API gateway open architecture based on the API gateway open architecture and the definitions of the multiple component external interfaces and component internal interfaces, forming an API gateway integration development platform, which supports API open integration.

[0039] Thirdly, embodiments of this application provide an API open integration device, which includes:

[0040] Processor and memory storing computer program instructions;

[0041] When the processor executes the computer program instructions, it implements the API open integration method provided in any of the embodiments of this application described above.

[0042] Fourthly, embodiments of this application provide a computer storage medium storing computer program instructions, which, when executed by a processor, implement the API open integration method provided in any of the embodiments of this application described above.

[0043] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform the API open integration method provided in any of the embodiments of this application described above.

[0044] As described above, the API open integration method, apparatus, device, storage medium, and program product of this application embodiment constructs a three-layer architecture including an API tool layer, an API protocol access layer, and an API governance layer, deploying microservice components and establishing logical relationships in different functional layers. Secondly, by establishing internal and external interfaces for the architecture to ensure effective system access to the API gateway, and defining the API gateway's core data model for the open architecture, the data analysis and processing capabilities of the API gateway are fully guaranteed. Thus, based on the above architecture, an API gateway integration open platform supporting API open integration is ultimately formed. Compared to existing technologies, the API open integration method, apparatus, device, storage medium, and program product of this application embodiment, by designing the API protocol access layer and API orchestration layer to be decoupled, supports independent deployment of each, improving the flexibility of actual API orchestration. Simultaneously, it achieves mutual isolation between API protocol access and API orchestration logic, resulting in more flexible and lightweight networking, thereby effectively ensuring the scalability and security of the API gateway. Attached Figure Description

[0045] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0046] Figure 1 This is a schematic diagram of the processing architecture of an existing API gateway system provided in an embodiment of this application;

[0047] Figure 2 This is a flowchart illustrating an API open integration method provided in an embodiment of this application;

[0048] Figure 3 This is a schematic diagram of a three-layered architecture for an API gateway open architecture provided in one embodiment of this application;

[0049] Figure 4 This is a schematic diagram of the key technical framework provided in an embodiment of this application;

[0050] Figure 5 This is a schematic diagram of a business scenario provided in an embodiment of this application;

[0051] Figure 6This is a design diagram of the implementation architecture of the API gateway open architecture provided in one embodiment of this application;

[0052] Figure 7 This is a schematic diagram of a protocol access and conversion scenario provided in an embodiment of this application;

[0053] Figure 8 This is a schematic diagram of the API online development architecture provided in one embodiment of this application;

[0054] Figure 9 This is a schematic diagram of the API online development process provided in one embodiment of this application;

[0055] Figure 10 This is a schematic diagram of the architecture for online API testing provided in one embodiment of this application;

[0056] Figure 11 This is a schematic diagram of the API online testing process provided in one embodiment of this application;

[0057] Figure 12 This is a schematic diagram of the structure of an API open integration device provided in an embodiment of this application;

[0058] Figure 13 This is a schematic diagram of the structure of an API open integration device provided in an embodiment of this application. Detailed Implementation

[0059] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0060] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0061] As described in the background section, with the development of digital transformation, API gateways are playing an increasingly important role in enterprises. Built on Zuul's open architecture, API gateways are responsible for managing and handling a large number of concurrent API calls, including functions such as traffic management, authorization and access control, monitoring, and API version management.

[0062] Specifically, such as Figure 1 As shown, the core of the existing processing architecture is a series of filters that can perform a series of operations during the routing of HTTP (Hypertext Transfer Protocol) requests and responses. These filters can be dynamically read, compiled, and run. Filters can perform a series of operations during the routing of HTTP requests and responses. The request first enters the pre-filter, and after the filter completes its execution, the request continues to the route filter, and then is routed to the specific service.

[0063] However, existing API gateways have some issues. As the size of the Groovy filter increases, performance gradually declines, and the system's scalability becomes poor. The typical thread pool + synchronous blocking thread model cannot effectively handle high-concurrency scenarios. Furthermore, this architecture is primarily based on Groovy filters; for synchronous API calls, abnormal Groovy events may render the entire API gateway unusable. If all custom APIs run on the same API gateway instance, it can easily lead to memory bloat, performance degradation, and a series of other problems.

[0064] In view of the above, in order to solve the problems of the prior art, embodiments of this application provide an API open integration method, apparatus, device, storage medium, and program product. It should be noted that the embodiments provided in this application are not intended to limit the scope of this application.

[0065] The API open integration method provided in the embodiments of this application will be introduced first below.

[0066] Figure 2 A flowchart illustrating an embodiment of the API open integration method provided in this application is shown. This API open integration method is applied to an electronic device, which may include a server or a user terminal, etc. Figure 2 As shown, this API open integration method includes the following steps:

[0067] S210, construct a layered API gateway open architecture, which includes an API tool layer, an API protocol access layer, and an API governance layer;

[0068] S220 deploys microservice components with corresponding functions in the API tool layer, API protocol access layer, and API governance layer, respectively;

[0069] S230 identifies the microservice components deployed in the API gateway open architecture and establishes logical relationships;

[0070] S240, Establish the list of internal and external interfaces of the API gateway. The list of internal and external interfaces of the API gateway defines multiple external interfaces and internal interfaces of components.

[0071] S250, based on the API gateway open architecture and the definition of multiple component external and internal interfaces, defines the API gateway core data model of the API gateway open architecture, forming an API gateway integration development platform. The API gateway integration open platform supports API open integration.

[0072] As described above, the API open integration method of this application embodiment constructs a three-layer architecture including an API tool layer, an API protocol access layer, and an API governance layer, deploying microservice components and establishing logical relationships in different functional layers. Secondly, it establishes internal and external interfaces for the architecture to ensure effective system access to the API gateway, and defines the API gateway's core data model within the open architecture to fully guarantee the API gateway's data analysis and processing capabilities. Thus, based on the above architecture, an API gateway integration open platform supporting API open integration is ultimately formed. Compared to existing technologies, the API open integration method of this application embodiment, by designing the API protocol access layer and API orchestration layer to be decoupled, supports independent deployment of each, improving the flexibility of actual API orchestration. Simultaneously, it achieves mutual isolation between API protocol access and API orchestration logic, resulting in more flexible and lightweight networking, thereby effectively ensuring the scalability and security of the API gateway.

[0073] The specific implementation methods of steps 210 to 250 above are described in detail below.

[0074] In S210, a layered API gateway open architecture is constructed, which includes an API tool layer, an API protocol access layer, and an API governance layer.

[0075] In this embodiment, based on the core concept of API layering, the unified API protocol access layer and the API orchestration layer are separated, eliminating the need to place protocol access and API orchestration in the same layer of the API gateway. This decoupling of the API protocol access layer and API orchestration layer allows for independent deployment, improving the flexibility of API orchestration. Simultaneously, it achieves mutual isolation between API protocol access and API orchestration logic, resulting in a more flexible and lightweight network. Furthermore, it facilitates the orchestration of multiple protocols, as the orchestration function is independent of protocol access capabilities, making API gateway protocol access more independent and transparent.

[0076] According to some embodiments of this application, regarding the specific functional positioning of the API tool layer, API protocol access layer and API governance layer described above, optionally, the API tool layer is used to provide API design, metadata definition, API development, API orchestration and API testing functions.

[0077] The API protocol access layer is used to implement unified multi-protocol access, API authentication, and API authorization for APIs.

[0078] The API governance layer is used to implement online governance, lifecycle management, and operation and maintenance of APIs.

[0079] In other words, the aforementioned API tool layer is equivalent to an API toolset, providing online API metadata definitions, as well as configurable and coded API definitions with bidirectional synchronization; it automatically generates skeleton code, test code, and synchronized online API documentation, API examples, and API descriptions based on the API metadata definitions, mainly including Designer (research tool), Builder (development tool), and Tester (testing tool).

[0080] API Protocol Access Layer: Access is responsible for unified protocol access, high performance, multi-protocol support, and scalability. It supports access, outgoing, authentication, authorization, message routing, and flow control for protocols such as REST (Representational State Transfer), HTTP (Hypertext Transfer Protocol), SOAP (Simple Object Access Protocol), and DSF (Distributed Service Framework).

[0081] API governance layer: Provides capabilities for dynamic management of API lifecycle, application management, subscription management (APP (Application) subscribes to API), northbound access management (authentication, flow control), and southbound fault management.

[0082] Among some possible implementations, the above-mentioned layered API gateway open architecture includes:

[0083] An open architecture for an API gateway is built using a distributed microservice framework based on asynchronous non-blocking NIO communication.

[0084] Therefore, building an API gateway architecture based on a distributed microservice framework using an asynchronous non-blocking NIO communication framework is beneficial for realizing the asynchronous non-blocking architecture of the subsequent protocol stack and asynchronous calls of the script orchestration layer.

[0085] In S220, when implementing the functions of the API gateway open architecture, including the API tool layer, API protocol access layer, and API governance layer, microservice components with corresponding functions are deployed in the API tool layer, API protocol access layer, and API governance layer, respectively.

[0086] According to some embodiments of this application, optionally, the API tool layer deploys: an APIDesign microservice component responsible for API design, metadata definition, and API compliance checks; an APIBuild microservice component responsible for online API development, testing, and release; and an APIOrchestration microservice component responsible for the business logic orchestration of APIs, supporting multiple orchestration forms.

[0087] The API protocol access layer is deployed with the following: API Access microservice component for unified multi-protocol access, API authentication, and authorization;

[0088] The API governance layer is deployed with APIGovernance microservice components for online governance, lifecycle management, and operation and maintenance of APIs.

[0089] According to some embodiments of this application, optionally, the microservice components in the API gateway open architecture and the APIPortal in the API gateway open architecture adopt a Restful API communication mode.

[0090] APIPortal provides an API interface that supports publishing, subscribing to, and launching APIs.

[0091] The API gateway open architecture in this embodiment is based on a microservice framework to deploy microservices to achieve API integration. It constructs a core of 5 microservice components + 1 Portal, and the communication mode between the microservice components and the Portal adopts the RESTful API.

[0092] Furthermore, the API gateway open architecture established in this application based on the three-tier architecture model, which includes API governance service, API engine service, publish / subscribe service, API definition service, API development service, API testing service, asset catalog service, developer service, user management service, caching service, message queue, authentication and authorization, database, registration center, and unified proxy, can effectively support multiple protocol access and conversion methods, fully guaranteeing the flexible functional design of fully online API development and the effective management capabilities of efficient API testing.

[0093] In S230, in specific implementation, after deploying the required microservice components in the above-mentioned layered architecture, the microservice components deployed in the API gateway open architecture are identified and logical relationships are established.

[0094] According to some embodiments of this application, optionally, identifying microservice components deployed in the API gateway open architecture and establishing logical relationships includes:

[0095] The API gateway open architecture adopts a microservice architecture. The front-end access of the API gateway open architecture uses Nginx for load balancing, the API Access microservice component is responsible for protocol access and conversion, and then the APIOrchestration microservice component is polled on a session basis.

[0096] The API Governance microservice component is used to deploy and upgrade APIs. It notifies the API Access microservice component via NATS messages, and the API Access microservice component pulls the APIs that need to be deployed and upgraded from the API Governance microservice component.

[0097] According to some embodiments of this application, optionally, when the API Governance microservice component starts, the API Governance microservice component starts connecting to the DB (database) and Nats (Native Advanced Technology Services), and provides a RESTful interface for use by the API Access microservice component and APIPortal;

[0098] When the API Access microservice component starts, it loads API information into memory either by actively pulling from API Governance or by subscribing to Nats messages.

[0099] In S240, during the specific implementation, an API gateway internal and external interface list is established, which defines multiple component external interfaces and component internal interfaces.

[0100] In S250, the core data model of the API gateway is defined based on the API gateway open architecture and the definitions of multiple external and internal interfaces of components. Thus, the aforementioned architecture ultimately forms an API gateway integration development platform, which can fully support the integration of various APIs.

[0101] More specifically, based on the API gateway open architecture and the definitions of multiple component external and internal interfaces, the core data model of the API gateway open architecture is defined, including:

[0102] Based on the open architecture of the API gateway and the definition of multiple external and internal interfaces of components, we construct the conceptual model, logical data objects, and physical storage model related to APIs, and define the data model for API-related business.

[0103] The aforementioned data model includes at least one of the following: user data model, API asset data model, and API subscription and usage information data model.

[0104] The aforementioned user data model can be used to store tenant, user, and permission data on the API gateway integration development platform through the platform's physical database; user behavior data, including login records, API development / archiving / publishing, API subscription, and SLA (Service Level Agreement) modification behavior data, are carried through the corresponding physical database.

[0105] The aforementioned API asset data model can be used to manage and store APIs, API status, and API packages through an asset catalog, stored via a file system; API policies, API Proxy, and Endpoint configurations are stored and managed through the governance service's database; and API asset statistics, including API categories, the number of APIs owned per user, the number of API calls, the number of API modifications / subscriptions, and API activity, are carried by the corresponding physical database.

[0106] The aforementioned API subscription usage information data model can be used to define the registration of subscription apps and the SLA of subscription APIs, managed through the API Governance governance service and stored in a physical database; it can also be used to synchronize with the API Engine through API Governance for API access control. The API Engine performs local snapshot storage and refreshes when changes occur, enhancing the platform's reliability and preventing the spread of failures.

[0107] According to some embodiments of this application, optionally, considering actual API interface call scenarios, the aforementioned API gateway integration development platform is used to communicate and connect with business systems and third-party systems respectively; after obtaining the API gateway integration development platform, the API open integration method further includes:

[0108] The API gateway integration development platform responds to requests from third-party systems for inbound APIs, providing internal services of the business system to the third-party system for invocation;

[0109] And / or, the API gateway integrates with the open platform to respond to requests from business systems for outbound APIs and provide the interfaces of third-party systems to the business systems for invocation.

[0110] In this embodiment, based on business needs, in an open scenario, internal services of the business system can be exposed to third-party calls through the API gateway's inbound API; in an integrated scenario, internal services of the system can call the interfaces of third-party systems through the API gateway (outbound API).

[0111] As middleware and API providers, API gateway integration development platforms cater to various industries, including telecom operators, internet companies, and others. After developing APIs, these platforms encapsulate cloud platform and product suite capabilities into standardized, service-oriented APIs for direct use by third parties such as telecom operators and OTT providers. Furthermore, application integration is based on these open API interfaces, enabling flexible orchestration and multi-protocol access conversion, effectively supporting adaptation, integration, and interfacing with third-party systems.

[0112] To facilitate understanding of the API open integration method provided in the above embodiments, the following describes the method using a specific scenario embodiment.

[0113] Specifically, this application's embodiments are based on the core concept of API layering, separating the unified protocol access layer and the API orchestration layer, and no longer placing both protocol access and API orchestration in the API gateway. The new API open architecture after layering is as follows: Figure 2 As shown:

[0114] API Tools Layer: API toolset, providing online API metadata definition, offering both configurable and coded API definitions with bidirectional synchronization; automatically generating skeleton code, test code, and synchronized online API documentation, API examples, and API descriptions based on API metadata definitions, mainly including Designer (research tool), Builder (development tool), and Tester (testing tool).

[0115] API Protocol Access Layer: Access is responsible for unified protocol access, high performance, multi-protocol support, scalability, and supports access, outgoing, authentication, authorization, message routing, and flow control for protocols such as REST, HTTP, SOAP, and DSF.

[0116] API governance layer: Provides capabilities for dynamic management of API lifecycle, application management, subscription management (APP subscribes to API), northbound access management (authentication, flow control), and southbound fault management.

[0117] In this embodiment, the API gateway adopts an asynchronous non-blocking architecture to achieve asynchronous calls between the protocol stack and the script orchestration layer. Specifically, the asynchronous non-blocking architecture of the protocol stack is built based on Netty, an asynchronous non-blocking NIO communication framework in Java. Based on Netty's asynchronous non-blocking model, one NIO thread can handle tens of thousands of client connections. Since network read and write operations are non-blocking, the reliability of communication is greatly improved.

[0118] The implementation steps of the API open integration method based on cloud service gateway technology in this scenario embodiment are as follows:

[0119] Step 1: Architecture Pattern and Technology Selection: When building the open architecture of the API gateway, the Netty communication framework is used, along with a distributed service framework, cluster deployment, and unified logging, tracing, and fault tolerance. Different component modules communicate with each other using microservice interfaces (Restful API) + NATS notification mechanism.

[0120] The key technical framework used includes, for example: Figure 4 As shown, Figure 4 This is a schematic diagram of the key technical framework provided in an embodiment of this application. For example... Figure 4 As shown, the core service is divided into 5 microservice components + 1 API Portal. The microservice components and the API Portal communicate using a RESTful API. The 5 microservice components include:

[0121] APIDesign: Responsible for API design, metadata definition, API compliance checks, etc.

[0122] API Build: Responsible for online API development, testing, and deployment.

[0123] API Access: Unified multi-protocol access for APIs, including API authentication and authorization.

[0124] API Orchestration: The business logic orchestration of APIs, supporting various orchestration methods, such as JS script orchestration and graphical orchestration.

[0125] API Governance: Online governance and lifecycle management of APIs, as well as their operation and maintenance.

[0126] More specifically, when implementing the functionality of microservice components, the core technical components can be implemented as follows:

[0127] API metadata definition: Based on Swagger extension, supports Swagger specification, self-developed, and describes API metadata in JSON or YAML format.

[0128] API multi-protocol access: Implemented based on Netty 4.X extensions, supporting asynchronous non-blocking I / O communication with excellent performance.

[0129] API orchestration: The graphical orchestration is based on BPMN and online flowcharts, and the JS script orchestration uses the Nashorn engine built into the JDK to execute JS scripts.

[0130] Unified data access layer: Based on MyBatis, it shields heterogeneous data at the underlying level and supports multiple databases such as Oracle and MySQL. You only need to switch the JDBC engine.

[0131] Distributed configuration service: Two implementation strategies. Cluster-level and node-level configuration are implemented using DF's configuration service, based on ZooKeeper. API-level configuration is implemented using NATS + database.

[0132] Step Two: Implementing the Software System Architecture Design: Please refer to [link / reference needed] Figure 5 , Figure 5 This is a schematic diagram of a business scenario provided by an embodiment of this application. For example... Figure 5 As shown, based on business needs, in an open scenario, internal services of the business system can be exposed to third parties for inbound API calls through the API gateway; in an integrated scenario, internal services of the business system can call the interfaces of third-party systems through the API gateway (outbound API).

[0133] As middleware and API providers, API gateway integration development platforms cater to various industries, including telecom operators, internet companies, and others. After developing APIs, these platforms encapsulate cloud platform and product suite capabilities into standardized, service-oriented APIs for direct use by third parties such as telecom operators and OTT providers. Furthermore, application integration is based on these open API interfaces, enabling flexible orchestration and multi-protocol access conversion, effectively supporting adaptation, integration, and interfacing with third-party systems.

[0134] Therefore, the following can be seen Figure 6 , Figure 6 This is a design diagram of the implementation architecture of the API gateway open architecture provided in one embodiment of this application. For example... Figure 6 As shown, in the specific implementation architecture:

[0135] 1) Design the API gateway:

[0136] APIs should be managed as assets, requiring full lifecycle management, including planning, design, implementation, packaging, operation, version management, maintenance, and decommissioning. The APIPlatform application architecture should cover the entire API lifecycle (creation, implementation, operation, and governance).

[0137] The API platform capability model has three layers: API Gateway (request processing, access control) -> API Management solution (infrastructure, lifecycle management tools, developer management) -> API platform (lifecycle management, creation, implementation, operation, governance tools).

[0138] 2) Design Management Domain:

[0139] As a service component, the API gateway leverages the management domain of a platform or product, such as SaaS OPS, to manage the installation and operation of services.

[0140] 3) Implement an API gateway:

[0141] API Fabric (API Gateway) is an integrated and open cloud service that enables DSVs and ISVs to connect and develop systems based on APIs, facilitating API integration and API capability openness. It also provides API specifications, repositories, governance, access and development tools, enabling one-stop completion of interface research, development, testing, statistics and monitoring.

[0142] Please see Figure 7 , Figure 7 This is a schematic diagram of a protocol access and conversion scenario provided in an embodiment of this application. For example... Figure 7As shown, the API gateway supports access and conversion of multiple protocols. In northbound access scenarios, API Access supports the HTTP+XML (Extensible Markup Language) protocol.

[0143] Please see Figure 8 , Figure 8 This is a schematic diagram of the architecture for online API development provided in one embodiment of this application. For example... Figure 8 As shown, the API supports fully online development. The API gateway integrated development platform provides API development tools that support online, scripted, and graphical development methods, enabling API providers to develop APIs through interface configuration and scripting, lowering the technical threshold and thus improving development efficiency.

[0144] The overall process of API development is as follows: Figure 9 As shown, Figure 9 This is a schematic diagram of the API online development process provided in one embodiment of this application. By utilizing the microservice components in the API gateway integrated development platform to create APIs, orchestrate processes, deploy APIs, and export APIs, online automated API development can be achieved.

[0145] Please see below. Figure 10 , Figure 10 This is a schematic diagram of the architecture for online API testing provided in one embodiment of this application. Figure 10 In this context, API testing tools automatically, online, and visually generate interface test results and success rates based on the input API interface definition file, test cases, and test stubs. Furthermore, users can effectively manage test cases using these tools.

[0146] The overall process of testing using API testing tools is as follows: Figure 11 As shown, Figure 11 This is a schematic diagram of the API online testing process provided in one embodiment of this application. Figure 11 In this process, by utilizing the relevant microservice components in the API Gateway integrated development platform, projects, interfaces, test cases, test cases are created, and test results are executed, thus effectively achieving API testing.

[0147] Step 3: Identify relevant components in the API gateway open architecture and establish logical relationships: The API gateway open architecture adopts a microservice architecture. Front-end access is load balanced through Nginx / LB, API Access is responsible for protocol access and conversion, and then APIOrchestration orchestrates services by polling by session.

[0148] API Governance is used to deploy and upgrade APIs. It notifies API Access via NATS messages, and then API Access pulls the APIs to be deployed and upgraded from API Governance. API Governance startup: connects to the database and NATS, and provides a RESTful interface for API Access and APIPortal. API Access startup: loads API information into memory by actively pulling from API Governance or subscribing to NATS messages. APIPortal provides an API interaction interface, allowing users to publish, subscribe to, and launch APIs.

[0149] Step 4: Establish a list of internal and external API gateway interfaces: Define the external and internal interfaces of the components, and define the security of the interfaces. Specific interfaces can be flexibly configured based on actual business scenarios and service functions; this embodiment does not impose strict limitations.

[0150] For example, external interfaces may include authentication and authorization interfaces, operation management interfaces, data integration interfaces, human-machine interfaces, etc., with each interface corresponding to its own interface type and description. When defining internal interfaces, the interface name, interface type, interface provider, calling relationship, and responsibilities can be defined. This scenario embodiment will not be described in detail here.

[0151] Step 5: Based on the API gateway open architecture and the definitions of multiple component external and internal interfaces, define the API gateway core data model of the API gateway open architecture.

[0152] Specifically, based on the open architecture of the API gateway and the definition of multiple external and internal interfaces of components, a conceptual model, logical data objects, and physical storage model related to APIs are constructed, and a data model definition is made for API-related business.

[0153] The aforementioned data model includes at least one of the following: user data model, API asset data model, and API subscription and usage information data model.

[0154] The aforementioned user data model can be used to store tenant, user, and permission data on the API gateway integration development platform through the platform's physical database; user behavior data, including login records, API development / archiving / publishing, API subscription, and SLA (Service Level Agreement) modification behavior data, are carried through the corresponding physical database.

[0155] The aforementioned API asset data model can be used to manage and store APIs, API status, and API packages through an asset catalog, stored via a file system; API policies, API Proxy, and Endpoint configurations are stored and managed through the governance service's database; and API asset statistics, including API categories, the number of APIs owned per user, the number of API calls, the number of API modifications / subscriptions, and API activity, are carried by the corresponding physical database.

[0156] The aforementioned API subscription usage information data model can be used to define the registration of subscription apps and the SLA of subscription APIs, managed through the API Governance governance service and stored in a physical database; it can also be used to synchronize with the API Engine through API Governance for API access control. The API Engine performs local snapshot storage and refreshes when changes occur, enhancing the platform's reliability and preventing the spread of failures.

[0157] In this scenario embodiment, a distributed microservice framework is used to construct five core microservices plus one portal, with a RESTful API communication mode between the microservice components and the portal. Furthermore, this embodiment establishes an architectural framework based on a three-tier architecture, including API governance service, API engine service, publish / subscribe service, API definition service, API development service, API testing service, asset catalog service, developer service, user management service, caching service, message queue, authentication and authorization, database, registry center, and unified proxy.

[0158] Furthermore, based on this architectural element, the API gateway in this embodiment supports multiple protocol access and conversion methods. The fully online API development functionality and efficient API testing management capabilities are key technical protection points in this application proposal. Based on these technical points, an integrated and open cloud service is developed, oriented towards API integration and API capability openness, enabling DSVs and ISVs to perform system integration and development based on APIs, completing interface development, testing, statistics, and monitoring in a one-stop manner.

[0159] Based on the API open integration method provided in the above embodiments, and with the same inventive concept, this application also provides an API open integration device corresponding to the above API open integration method. The following describes... Figure 12 A detailed introduction to API open integration devices is provided.

[0160] Figure 12 A schematic diagram of the structure of an API open integration device provided in an embodiment of this application is shown.

[0161] Figure 12 The API open integration device 1200 shown includes:

[0162] The first construction module 1210 is used to construct a layered API gateway open architecture, which includes an API tool layer, an API protocol access layer, and an API governance layer.

[0163] The first deployment module 1220 is used to deploy microservice components with corresponding functions in the API tool layer, the API protocol access layer and the API governance layer respectively;

[0164] The first module 1230 is used to identify the microservice components deployed in the API gateway open architecture and establish logical relationships.

[0165] The second module 1240 is used to establish a list of internal and external interfaces of the API gateway, wherein the list of internal and external interfaces of the API gateway defines multiple external interfaces and internal interfaces of components.

[0166] The first definition module 1250 is used to define the API gateway core data model of the API gateway open architecture based on the API gateway open architecture and the definitions of the multiple component external interfaces and component internal interfaces, forming an API gateway integration development platform, which supports API open integration.

[0167] This application provides an API open integration device that constructs a three-layer architecture, including an API tool layer, an API protocol access layer, and an API governance layer, by setting corresponding functional modules. Microservice components are deployed and logical relationships are established in different functional layers. Secondly, internal and external interfaces are established for the architecture to ensure effective system access to the API gateway, and a core data model for the API gateway open architecture is defined to fully guarantee the API gateway's data analysis and processing capabilities. Thus, based on the above architecture, an API gateway integration open platform supporting API open integration is ultimately formed. Compared to existing technologies, the API open integration device of this application, by designing the API protocol access layer and API orchestration layer to be decoupled, supports independent deployment of each, improving the flexibility of actual API orchestration. Simultaneously, it achieves mutual isolation between API protocol access and API orchestration logic, resulting in a more flexible and lightweight network, thereby effectively ensuring the scalability and security of the API gateway.

[0168] Based on the API open integration method provided in the above embodiments, and with the same inventive concept, this application also provides an API open integration device corresponding to the above API open integration method. The following describes... Figure 13 This section provides a detailed introduction to API open integration devices.

[0169] Please see below. Figure 13 , Figure 13 This is a schematic diagram of the structure of an API open integration device provided in an embodiment of this application.

[0170] API open integration devices may include a processor 1301 and a memory 1302 storing computer program instructions.

[0171] Specifically, the processor 1301 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0172] Memory 1302 may include mass storage for data or instructions. For example, and not limitingly, memory 1302 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 1302 may include removable or non-removable (or fixed) media. Where appropriate, memory 1302 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 1302 is non-volatile solid-state memory.

[0173] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the methods according to one aspect of this disclosure.

[0174] The processor 1301 implements any of the API open integration methods described in the above embodiments by reading and executing computer program instructions stored in the memory 1302.

[0175] In one example, the data API open integration device may also include a communication interface 1303 and a bus 1310. For example, Figure 13 As shown, the processor 1301, memory 1302, and communication interface 1303 are connected through bus 1310 and complete communication with each other.

[0176] The communication interface 1303 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0177] Bus 1310 includes hardware, software, or both, that couples components of an API Open Integration Device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 1310 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0178] The API open integration device executes the API open integration method in the embodiments of this application, thereby realizing the API open integration method described in the embodiments of this application.

[0179] Furthermore, in conjunction with the API open integration method in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the API open integration methods in the above embodiments.

[0180] Based on the API open integration method in the above embodiments, this application provides a computer program product. When the instructions in the computer program product are executed by the processor of an electronic device, the electronic device performs the API open integration method provided in any of the above embodiments of this application.

[0181] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0182] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0183] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0184] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0185] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. An API open integration method, characterized in that, The method includes: Construct a layered API gateway open architecture, which includes an API tool layer, an API protocol access layer, and an API governance layer; Deploy corresponding microservice components in the API tool layer, the API protocol access layer, and the API governance layer respectively; Identify the microservice components deployed in the API gateway open architecture and establish logical relationships; Establish an API gateway internal and external interface list, which defines multiple component external interfaces and component internal interfaces; Based on the API gateway open architecture and the definitions of the external and internal interfaces of the multiple components, the core data model of the API gateway open architecture is defined to form an API gateway integration development platform, which supports API open integration.

2. The method according to claim 1, characterized in that, The API tool layer is used to provide API design, metadata definition, API development, API orchestration, and API testing functions; The API protocol access layer is used to implement unified multi-protocol access, API authentication, and API authorization. The API governance layer is used to implement online governance, lifecycle management, and operation and maintenance of APIs.

3. The method according to claim 1, characterized in that, The API tool layer is deployed with the APIDesign microservice component, which is responsible for API design, metadata definition, and API compliance checks. The APIBuild microservice component is used to handle the online development, testing, and release of APIs. APIOrchestration is a microservice component responsible for orchestrating the business logic of APIs and supports multiple orchestration formats. The API protocol access layer is equipped with the APIAccess microservice component, which is used for unified multi-protocol access, API authentication, and authorization. The API governance layer is deployed with APIGovernance microservice components for online governance, lifecycle management, and operation and maintenance of APIs.

4. The method according to claim 3, characterized in that, The microservice components in the API gateway open architecture communicate with the APIPortal in the API gateway open architecture using a RESTful API communication mode. APIPortal is used to provide an API interaction interface, supporting the publishing, subscription, and deployment of APIs.

5. The method according to claim 4, characterized in that, The process of identifying and establishing logical relationships among the microservice components deployed in the API gateway open architecture includes: The API gateway open architecture adopts a microservice architecture. The front-end access of the API gateway open architecture uses Nginx for load balancing. The API Access microservice component is responsible for protocol access and conversion, and then the APIOrchestration microservice component is polled by session. The API Governance microservice component is used to complete the deployment and upgrade of APIs. It notifies the API Access microservice component through NATS messages, and the API Access microservice component pulls the APIs that need to be deployed and upgraded from the API Governance microservice component.

6. The method according to claim 5, characterized in that, When the API Governance microservice component starts, it connects to the database DB and Nats and provides a RESTful interface for the API Access microservice component and the APIPortal to use. When the API Access microservice component starts, it loads API information into memory by actively pulling from APIGovernance or by subscribing to Nats messages.

7. The method according to claim 1, characterized in that, The construction of the layered API gateway open architecture includes: The API gateway open architecture is constructed based on a distributed microservice framework using an asynchronous non-blocking NIO communication framework.

8. The method according to claim 1, characterized in that, Based on the API gateway open architecture and the definitions of the multiple component external interfaces and component internal interfaces, the core data model of the API gateway open architecture is defined, including: Based on the API gateway open architecture and the definitions of the external and internal interfaces of the multiple components, a conceptual model, logical data objects, and physical storage model related to APIs are constructed, and a data model definition is performed for API-related businesses. The data model includes at least one of the following: user data model, API asset data model, and API subscription and usage information data model.

9. The method according to claim 1, characterized in that, The API gateway integration development platform is used to communicate and connect with business systems and third-party systems respectively. After obtaining the API gateway integration development platform, the method further includes: The API gateway integration development platform responds to the third-party system's request for inbound API by providing the internal services of the business system to the third-party system for invocation; And / or, the API gateway integration open platform responds to the business system's request for outbound API by providing the third-party system's interface for the business system to call.

10. An API open integration device, characterized in that, The device includes: The first building module is used to build a layered API gateway open architecture, which includes an API tool layer, an API protocol access layer, and an API governance layer. The first deployment module is used to deploy microservice components with corresponding functions in the API tool layer, the API protocol access layer and the API governance layer respectively; The first module is used to identify the microservice components deployed in the API gateway open architecture and establish logical relationships. The second module is used to establish a list of internal and external interfaces of the API gateway, which defines multiple external interfaces and internal interfaces of components. The first definition module is used to define the API gateway core data model of the API gateway open architecture based on the API gateway open architecture and the definitions of the multiple component external interfaces and component internal interfaces, forming an API gateway integration development platform, which supports API open integration.

11. An API open integration device, characterized in that, The device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the API open integration method as described in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the API open integration method as described in any one of claims 1-9.

13. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device performs the API open integration method as described in any one of claims 1-9.

Images