API management method and system

Abstract

The invention discloses an API (Application Program Interface) management method and system, and the method comprises the following steps: adopting an exclusive service domain API gateway as a unified entrance of service domain flow for an API for interaction of front and back end services in a service domain; for APIs internally called by back-end services in a service domain, mutual calling, data interaction and fusing current limiting are carried out by using a micro-service registration discovery mechanism; for the cross-service domain shared API, a shared API gateway is adopted, all service domains uniformly use the shared API gateway, the API called by the cross-service domain is registered to the gateway, and a user of the API initiates calling to the shared API gateway. By adopting the technical scheme, the flow management, data sharing and system reliability inside and outside the service domain are optimized by constructing a multi-level API management system so as to cope with complex service requirements and competitive environments.

Description

Technical Field

[0001] The present invention belongs to the technical field of enterprise information system management and relates to an API management method and system. Background Art

[0002] In today's fast-paced business environment, the number of enterprise information systems continues to increase, and new and old systems coexist, which has led to a serious problem, namely the emergence of system islands. System islands prevent information from flowing and sharing smoothly between different departments or business areas, which poses a great challenge to business integration and rapid response to changes. In order to solve this problem, API (Application Programming Interface) has gradually become a mainstream solution.

[0003] APIs serve as a bridge between different systems, enabling data interaction and collaborative work between systems. By defining clear interfaces and specifications, different systems can exchange information securely and achieve seamless integration of business processes. In this context, it is particularly important to classify and grade an enterprise's API assets. By classifying APIs, enterprises can better understand and organize the purpose and functions of each API, thereby better controlling and managing them.

[0004] However, the existing technology lacks flexible API management functions, making it difficult to meet business innovation needs, and cross-business domain collaboration is limited. Insufficient monitoring and troubleshooting may affect the efficiency of problem handling. The lack of unified standards may affect the consistency of APIs, and there are potential problems in resource utilization efficiency, which may affect the overall performance and applicability of the solution in complex business environments. Summary of the invention

[0005] The purpose of the present invention is to provide an API management method and system, which optimizes traffic management, data sharing and system reliability within and outside the business domain by building a multi-level API management system.

[0006] In order to achieve the above object, the basic scheme of the present invention is: an API management method, comprising the following steps:

[0007] For the APIs for front-end and back-end service interactions within the business domain, a high-performance dedicated business domain API gateway is used as the unified entrance for business domain traffic;

[0008] For APIs called internally by backend services within the business domain, the microservice registration and discovery mechanism is used to perform mutual calls, data interaction, and circuit breaking and current limiting.

[0009] For shared APIs across business domains, a shared API gateway is used. All business domains use the shared API gateway uniformly, and the APIs called across business domains are registered with the gateway. The API users initiate calls to the shared API gateway.

[0010] The working principle and beneficial effects of this basic solution are: This technical solution innovatively solves the technical problems existing in multi-category API management, builds a multi-level API management system, addresses the limitations of existing methods in comprehensive management, problem troubleshooting, flexibility and data interaction, and is committed to providing a more comprehensive and efficient API management solution. Through key technical means such as unified entry, automatic discovery, visual management and control, and asset reuse, it realizes the comprehensive management and flexible application of different types of APIs, thereby optimizing traffic management, data interaction, problem troubleshooting and system reliability within and outside the business domain, and provides a solid technical foundation for enterprises to achieve efficient, secure and flexible API management.

[0011] Furthermore, after the user performs a business operation in the browser, if the operation needs to call the back-end interface within the business domain, the business domain front-end initiates an API call, and the request passes through the business domain gateway. In the business domain gateway, the call request is authenticated and then routed to the corresponding back-end service. After the back-end service completes the business logic processing, it returns the processing result to the business domain gateway, and the business domain gateway returns the result to the front-end, ultimately realizing the update of the user interface.

[0012] The operation is simple, achieving efficient collaboration and stable processes within and outside the business domain.

[0013] Furthermore, when an external request passes through the business domain gateway and enters the business domain, if the business domain adopts the microservice architecture and the current request does not involve a shared API call, the request will call the corresponding microservice APIs in the business domain in the specific order required to complete the business.

[0014] Each microservice is responsible for handling specific business logic, covering all aspects from data processing to interactive operations to ensure the processing of the entire request;

[0015] Once all necessary microservices have completed their corresponding tasks, including database query, calculation, and verification, the business domain will return the final processing results to the source of the request.

[0016] Optimize traffic management, data sharing, and system reliability within and outside the business domain to cope with complex business needs and competitive environments.

[0017] Furthermore, in the microservice architecture, the business domain applications use a registration discovery mechanism, and each microservice registers its existence in the system, including the services it provides, API interfaces, and corresponding network addresses;

[0018] When other components or services need to communicate with a specific microservice, they query the registration center to obtain the information of the microservice to ensure the collaboration and communication between microservices.

[0019] The registration and discovery mechanism ensures the collaboration and communication between microservices, enabling the entire business domain system to efficiently respond to external requests and complete complex business processing flows. Through the registration and discovery mechanism, the deployment and adjustment of microservices become more flexible and easier to manage, thereby improving the scalability and maintainability of the system.

[0020] Furthermore, microservices can perform load balancing, which includes polling, weighted polling, random, and least connections.

[0021] Furthermore, for shared APIs across business domains, a shared API gateway is used. The steps for applications across business domains to call the shared API gateway are as follows:

[0022] The application in the business domain that initiates the request sends a request to the shared API gateway, which contains the required parameters. The parameters include authentication information that identifies the caller and related business information.

[0023] Shared API gateway performs authentication and authorization to ensure that the application has the authority to call the target business domain;

[0024] After authentication, the shared API gateway routes the request to the target business domain. The microservices in the business domain execute the corresponding business logic and return the processing results to the shared API gateway.

[0025] The shared API gateway passes the response to the business domain that initiated the request, and the application updates the interface or status based on the response.

[0026] This ensures secure cross-domain communication, with permissions, traffic, and monitoring managed by a shared API gateway, enabling applications across business domains to work together and achieve functional sharing and flexibility.

[0027] The present invention also provides an API management system, comprising a processing unit, wherein the processing unit executes the method of the present invention to perform API management.

[0028] The system has a simple structure and provides a solid technical foundation for enterprises to achieve efficient, secure and flexible API management. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1It is a flowchart of the API management method of the present invention;

[0030] Figure 2 It is a structural diagram of the registration discovery mechanism of the API management method of the present invention;

[0031] Figure 3 It is a schematic diagram of the structure of the API management method of the present invention, which shows that the cross-business domain application calls a shared API gateway;

[0032] Figure 4 It is a structural diagram of front-end and back-end API calls within the business domain of the API management method of the present invention. DETAILED DESCRIPTION

[0033] Embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and cannot be understood as limiting the present invention.

[0034] In the description of the present invention, it is necessary to understand that the terms "longitudinal", "lateral", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside", etc., indicating the orientation or position relationship, are based on the orientation or position relationship shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on the present invention.

[0035] In the description of the present invention, unless otherwise specified and limited, it should be noted that the terms "installed", "connected" and "connected" should be understood in a broad sense. For example, it can be a mechanical connection or an electrical connection, or it can be the internal connection between two components. It can be a direct connection or an indirect connection through an intermediate medium. For ordinary technicians in this field, the specific meanings of the above terms can be understood according to the specific circumstances.

[0036] Current situation: multiple business systems (business domains), multiple suppliers, and systems interact through APIs.

[0037] APIs are divided into three categories: APIs for front-end and back-end service interactions within a business domain, APIs for internal calls to back-end services within a business domain, and APIs for cross-business domain calls.

[0038] The first type of API, namely the API for front-end and back-end service interaction within the business domain, plays a key role in the business domain. As a unified entrance for front-end traffic, the business domain gateway provides orderly traffic guidance and management for the business domain. It is usually developed and maintained by the same supplier. At the same time, it has the characteristics of frequent changes, high frequency of use, and the need to quickly locate problems. Therefore, it is handed over to the supplier for internal management and easy control.

[0039] The second type of API is the API called internally by the back-end services within the business domain. It is usually developed by the same supplier, is internally managed, and is easy to control.

[0040] The third type of API, shared API across business domains, is usually developed by different suppliers. In order to ensure the reliability of the system, shared APIs need to be uniformly managed and audited.

[0041] The present invention discloses an API management method, which aims to innovatively solve the technical problems existing in multi-category API management. By building a multi-level API management system, the solution aims to address the limitations of existing methods in terms of comprehensive management, troubleshooting, flexibility and data interaction.

[0042] This invention is committed to providing a more comprehensive and efficient API management solution, which optimizes traffic management, data sharing and system reliability within and outside the business domain through visual management, automatic discovery and asset reuse, so as to cope with complex business needs and competitive environment. Figure 1 As shown, the API management method includes the following steps:

[0043] like Figure 4 As shown in the figure, for the API of front-end and back-end service interaction within the business domain, a high-performance exclusive business domain API gateway is used (the gateway adopts asynchronous non-blocking and connection pool technology, and can support tens of thousands of requests per second) as the unified entrance for business domain traffic. The gateway has the capabilities of routing, authentication, and current limiting, and serves as the unified entrance for business domain traffic; each business domain has an exclusive business domain gateway, and the front-end and back-end applications and business domain gateways within the business domain are maintained by the same team, so that when problems occur in the front-end and back-end calls within the business domain, they can be located quickly and accurately.

[0044] For APIs called internally by backend services within the business domain, the microservice registration and discovery mechanism is used to perform mutual calls, data interaction, and circuit breaking and current limiting.

[0045] For shared APIs across business domains, a shared API gateway is used, which has functions such as workflow, permission control, log management and replay. All business domains use the shared API gateway uniformly, register the APIs called across business domains to the gateway, and the API users initiate calls to the shared API gateway. Accumulate API assets, realize asset reuse, and speed up system construction and development. Unified management and control of shared APIs to ensure API security; clarify the caller to facilitate API migration.

[0046] In a preferred embodiment of the present invention, after the user performs a business operation in the browser, if the operation needs to call the back-end interface within the business domain, the business domain front-end initiates an API call, and the request passes through the business domain gateway. In the business domain gateway, the call request is authenticated and then routed to the corresponding back-end service. After the back-end service completes the business logic processing, it returns the processing result to the business domain gateway, and the business domain gateway returns the result to the front-end, ultimately realizing the update of the user interface.

[0047] In a preferred solution of the present invention, when an external request passes through the business domain gateway and enters the business domain, if the business domain adopts a microservice architecture and the current request does not involve a shared API call, the request will call the corresponding microservice APIs in the business domain in a specific order required to complete the business;

[0048] Each microservice is responsible for handling specific business logic, covering all aspects from data processing to interactive operations to ensure the processing of the entire request;

[0049] Once all necessary microservices have completed their corresponding tasks, including database query, calculation, and verification, the business domain will return the final processing results to the source of the request.

[0050] In a preferred embodiment of the present invention, Figure 2 As shown in the figure, in the microservice architecture, the business domain application uses the registration discovery mechanism, and each microservice registers its existence in the system, including the services it provides, API interfaces, and corresponding network addresses;

[0051] When other components or services need to communicate with a specific microservice, they query the registration center to obtain the microservice information (such as address and available APIs), ensuring the collaboration and communication between microservices, so that the system of the entire business domain can efficiently respond to external requests and complete complex business processing. Through the registration discovery mechanism, the deployment and adjustment of microservices become more flexible and easier to manage, thereby improving the scalability and maintainability of the system.

[0052] Preferably, the microservices can perform load balancing, which includes polling, weighted polling, random, least connections, etc., and can be adjusted according to actual conditions.

[0053] In a preferred embodiment of the present invention, Figure 3 As shown, for a shared API across business domains, a shared API gateway is used. The steps for applications across business domains to call the shared API gateway are as follows:

[0054] The application in the business domain that initiates the request sends a request to the shared API gateway, which contains the required parameters. The parameters include authentication information that identifies the caller and related business information.

[0055] Shared API gateway performs authentication and authorization to ensure that the application has the authority to call the target business domain;

[0056] After authentication, the shared API gateway routes the request to the target business domain. The microservices in the business domain execute the corresponding business logic and return the processing results to the shared API gateway.

[0057] The shared API gateway passes the response to the business domain that initiated the request, and the application updates the interface or status based on the response. This process ensures secure cross-domain communication, and the shared API gateway manages permissions, traffic, and monitoring, enabling applications between business domains to work together to achieve functional sharing and flexibility.

[0058] The present invention also provides an API management system, including a processing unit, which executes the method of the present invention to perform API management.

[0059] The innovative multi-level API management system of this technical solution strengthens comprehensive management, problem-solving capabilities and flexibility, and improves the efficiency of problem troubleshooting and repair through visual management and automatic discovery. At the same time, asset reuse and a unified standard API market promote data interaction and system reliability, and achieve efficient collaboration and process stability within and outside the business domain.

[0060] It not only realizes efficient communication and function sharing in a multi-business domain environment, but also improves the security, stability and performance of the system. At the same time, it can bring positive and lasting impact to the system integration and development of the enterprise.

[0061] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "examples", "specific examples", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0062] Although the embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the claims and their equivalents.

Claims

1. An API management method, characterized in that: The steps include: For the APIs for front-end and back-end service interactions within the business domain, a dedicated business domain API gateway is used as the unified entrance for business domain traffic; For APIs called internally by backend services within the business domain, the microservice registration and discovery mechanism is used to perform mutual calls, data interaction, and circuit breaking and current limiting. For shared APIs across business domains, a shared API gateway is used. All business domains use the shared API gateway uniformly, and the APIs called across business domains are registered with the gateway. The API users initiate calls to the shared API gateway.

2. The API management method according to claim 1, characterized in that: After the user performs a business operation in the browser, if the operation needs to call the back-end interface within the business domain, the business domain front-end initiates an API call, and the request passes through the business domain gateway. In the business domain gateway, the call request is authenticated and routed to the corresponding back-end service. After the back-end service completes the business logic processing, it returns the processing result to the business domain gateway, and the business domain gateway returns the result to the front-end, ultimately realizing the update of the user interface.

3. The API management method according to claim 1, characterized in that: When an external request passes through the business domain gateway and enters the business domain, if the business domain adopts the microservice architecture and the current request does not involve a shared API call, the request will call the corresponding microservice APIs in the business domain in the specific order required to complete the business. Each microservice is responsible for handling specific business logic, covering all aspects from data processing to interactive operations to ensure the processing of the entire request; Once all necessary microservices have completed their corresponding tasks, including database query, calculation, and verification, the business domain will return the final processing results to the source of the request.

4. The API management method according to claim 3, characterized in that: In the microservice architecture, applications in the business domain use a registration discovery mechanism. Each microservice registers its existence in the system, including the services it provides, API interfaces, and corresponding network addresses. When other components or services need to communicate with a specific microservice, they query the registration center to obtain the information of the microservice to ensure the collaboration and communication between microservices.

5. The API management method according to claim 3, characterized in that: Microservices can perform load balancing, which includes polling, weighted polling, random, and least connections.

6. The API management method according to claim 1, characterized in that: For shared APIs across business domains, a shared API gateway is used. The steps for applications across business domains to call the shared API gateway are as follows: The application in the business domain that initiates the request sends a request to the shared API gateway, which contains the required parameters. The parameters include authentication information that identifies the caller and related business information. Shared API gateway performs authentication and authorization to ensure that the application has the authority to call the target business domain; After authentication, the shared API gateway routes the request to the target business domain. The microservices in the business domain execute the corresponding business logic and return the processing results to the shared API gateway. The shared API gateway passes the response to the business domain that initiated the request, and the application updates the interface or status based on the response.

7. An API management system, characterized in that: It comprises a processing unit, which executes the method described in any one of claims 1-6 to perform API management.

Images