KR102256736B1 - Api management system and method thereof - Google Patents

Abstract

According to an embodiment disclosed in the present document, an API management system comprises: an API gateway which manages API call requests received from a client; and a conversion relay server which assigns a transaction ID to each API call request delivered from the API gateway and communicates with an external system to process the API call requests. The API gateway comprises: a request processing unit for processing API call requests from the client through a non-blocking method; a filter unit for controlling a frequency of the API call requests based on logic set by a user; a failure propagation prevention unit for stopping delivery of the API call requests to a system in which a failure occurs among external systems; and a load balancing unit for distributing the API call requests based on a preset switching process. The conversion relay server comprises: a routing unit that provides a service related to the external systems as an HTTP/JSON-based API; a monitoring unit for monitoring a state of the API; a custom conversion unit defining a message conversion rule for the API; and a message conversion unit which converts a message included in the API according to the message conversion rule.

Description

API management system and method related thereto {API MANAGEMENT SYSTEM AND METHOD THEREOF}

The embodiments disclosed in this document relate to an API management system and a method thereof.

In the mainframe era, as Unix systems were brought down, systems began to be divided into business units. As such, communication between systems divided into business units has become necessary, and as the system becomes larger, the structure of direct P2P (Peer to Peer) communication between systems has reached its limit.

Solutions such as Enterprise Application Integration (EAI) and Service Oriented Architecture (SOA) have been devised to solve the communication problem between these systems. However, EAI is capable of interworking between heterogeneous systems that are not standardized, but there is a problem in that data is concentrated in one place, resulting in bottlenecks and development costs that are more than necessary, and is developed exclusively by vendors. In addition, in EAI, when a customer wanted to disclose and provide internal data to the outside, a separate connection adapter had to be produced for each service to be disclosed. This required separate development resources and required modification of the existing system, resulting in server downtime. On the other hand, since SOA communicates with HTTP/XML, there is a problem that performance degradation occurs due to consuming a lot of computing power when converting complex XML.

To solve these problems, an API gateway for integrating internal systems and providing services to the outside is in the spotlight these days. However, API gateway has several functions such as routing, authentication, traffic control, etc., but it does not have a function to convert message type or message format. Therefore, in each legacy, in order to use the API gateway, the process and system Had to write. In addition, since such processes and systems have to modify and distribute the source part whenever message requirements change, the system is inevitable, and all APIs that use the message conversion system are affected, so when restarting, operation is not possible. There was a limit to not being able to use the service until it was completed.

The embodiments disclosed in this document are intended to provide an API management system capable of providing smooth service and a method related thereto, since there is no need to develop a separate resource in the customer's system and thus downtime provided to users does not occur. do.

In addition, the embodiments disclosed in this document provide an API management system and a method related to the API management system that can be quickly responded by making it possible to easily check where an error has occurred in the case of an error within the system through the transaction ID assigned to each API call. To provide is for one purpose.

In addition, the embodiments disclosed in this document can manage from an API call request to a response in a single flow, and it is possible to easily add resources for providing an API from the remote system to the inside or outside, so that the administrator of the remote system can Its purpose is to provide an API management system that can more conveniently manage the life cycle of the provided API and a method related thereto.

In addition, the embodiments disclosed in this document can statistically check the API call request proceeding in a single flow and visually monitor the failure situation in the linked system, thereby enabling rapid failure detection for the operating remote system. It is an object of the present invention to provide an API management system and a method related thereto that can reduce unnecessary waste of resources for checking this.

The technical problems of the embodiments disclosed in this document are not limited to the technical problems mentioned above, and other technical problems that are not mentioned will be clearly understood by those skilled in the art from the following descriptions.

The API management system according to an embodiment disclosed in this document provides an API gateway that manages an API call request received from a client and a transaction ID for each API call request transmitted from the API gateway, and communicates with an external system to provide the API. A system including a conversion mediation server that processes a call request, wherein the API gateway includes a request processing unit that processes an API call request from the client through a non-blocking method, and a logic set by a user. Based on the filter unit controlling the frequency of the API call request, a failure propagation prevention unit stopping delivery of the API call request to a system in which a failure occurs among the external systems, and the API call request based on a preset switching process. Including a load balancing unit to distribute, the conversion mediation server, a routing unit that provides a service related to the external system through an HTTP/JSON-based API, a monitoring unit that monitors the state of the API, and a message conversion rule for the API And a message conversion unit for converting a message included in the API according to the message conversion rule and a custom conversion unit defining a message.

According to an embodiment, the request processing unit may process the API call request in an asynchronous manner through an event loop.

According to an embodiment, the filter unit may perform authentication regarding whether to allow access of the client for each route, service, and user of the API according to the logic.

According to an embodiment, the filter unit may determine a maximum number of requests for the API based on time according to the logic.

According to an embodiment, the failure propagation prevention unit may stop delivery of the API call request to a system in which a response error exceeds a threshold value among the external systems.

According to an embodiment, the failure propagation prevention unit may provide an alternative response based on a preset value while delivery of the API call request is stopped.

According to an embodiment, when the delivery of the API call request to the faulty system is stopped, the fault propagation prevention unit transmits an API connection request to the faulty system after a preset time, and the faulty system resumes normal operation. In this case, the API call request can be resumed without any separate manipulation.

According to an embodiment, the load balancer may distribute the API call request according to a preset value in units of groups of services registered in the switching process.

According to an embodiment, the routing unit may provide a plurality of communication protocols linkable with the external system.

According to an embodiment, the monitoring unit may log the API for each preset period to enable tracking of a time required for a message processing process and an error.

According to an embodiment, the custom conversion unit may define the message conversion rule in the form of a script.

According to an embodiment, the message conversion unit may convert a message in at least one of a header and a body of the API.

According to an embodiment, the message conversion unit may perform a preset conversion for each message.

According to an embodiment, when authentication is performed based on a route, service, and user of the API, the filter unit may issue an authentication key for each API in response to a request for use from the client.

The API management method according to an embodiment disclosed in this document is an API gateway that manages an API call request received from a client and a transaction ID for each API call request transmitted from the API gateway, and communicates with an external system to provide the API. As an API management method using a system including a conversion mediation server that processes a call request, processing an API call request from the client through a non-blocking method, and calling the API based on logic set by a user Controlling the frequency of requests, stopping delivery of the API call request to a system in which a failure occurs among the external systems, distributing the API call request based on a preset switching process, and service related to the external system Providing a HTTP/JSON based API, monitoring the status of the API, defining a message conversion rule for the API, and converting a message included in the API according to the message conversion rule. Can include.

The API management system and the method related thereto according to an embodiment disclosed in this document can provide a smooth service since there is no need to develop a separate resource in the customer's system, and thus downtime provided to users does not occur.

In addition, the API management system and the method related thereto according to an embodiment disclosed in this document can be quickly responded to because it is possible to easily check where an error has occurred in the case of an error internally through the transaction ID assigned to each API call. Is possible.

In addition, the API management system and the method related thereto according to an embodiment disclosed in this document can manage from an API call request to a response in a single flow, and facilitate resources for providing an API from a remote system to the inside or outside. It can be added so that the administrator of the remote system can more conveniently manage the life cycle of the API provided internally.

In addition, the API management system and the method related thereto according to an embodiment disclosed in this document can statistically check the API call request proceeding in one flow and visually monitor the failure situation in the linked system, It is possible to quickly detect a failure of a remote system, and reduce unnecessary waste of resources for checking this.

In addition, the API management system and the method related thereto according to an embodiment disclosed in the present document can manage an API call in which a failure has occurred, thereby improving the quality of service of the client and external system.

1 is a diagram illustrating that an API management system according to an embodiment disclosed in this document communicates with a client and an external system.
2 is a block diagram showing the configuration of an API management system according to an embodiment disclosed in this document.
3 is a block diagram showing the configuration of an API gateway of an API management system according to an embodiment disclosed in this document.
4 is a block diagram showing the configuration of a conversion mediation server of an API management system according to an embodiment disclosed in this document.
5 is a diagram illustrating an API management method according to an embodiment disclosed in this document.
6 is a block diagram showing a hardware configuration of a computing system that performs an API management method according to an embodiment disclosed in this document.

Hereinafter, various embodiments disclosed in this document will be described in detail with reference to the accompanying drawings. In this document, the same reference numerals are used for the same components in the drawings, and duplicate descriptions of the same components are omitted.

With respect to the various embodiments disclosed in this document, specific structural or functional descriptions are exemplified for the purpose of describing the embodiments only, and the various embodiments disclosed in this document may be implemented in various forms, and this document It should not be construed as being limited to the embodiments described in.

Expressions such as "first", "second", "first", or "second" used in various embodiments may modify various elements regardless of their order and/or importance, and the corresponding elements Not limited. For example, without departing from the scope of the rights of the embodiments disclosed in this document, a first component may be referred to as a second component, and similarly, a second component may be renamed to a first component.

Terms used in this document are only used to describe a specific embodiment, and may not be intended to limit the scope of other embodiments. Singular expressions may include plural expressions unless the context clearly indicates otherwise.

All terms used herein, including technical or scientific terms, may have the same meaning as commonly understood by a person of ordinary skill in the art of the embodiments disclosed in this document. Terms defined in a commonly used dictionary may be interpreted as having the same or similar meaning as the meaning in the context of the related technology, and should not be interpreted as an ideal or excessively formal meaning unless explicitly defined in this document. . In some cases, even terms defined in this document cannot be interpreted to exclude embodiments disclosed in this document.

1 is a diagram illustrating that an API management system according to an embodiment disclosed in this document communicates with a client and an external system.

Referring to FIG. 1, an API management system 100 according to an embodiment disclosed in this document may include an API gateway 110 and a conversion mediation server 120.

The API management system 100 may receive an API call request from a client (eg, a system developer, etc.) 10, convert it, and transmit it to an external system (eg, a customer company system) 20. have. In addition, the external system 20 may extract data corresponding to the received API call request and transmit it to the client 10 through the API management system 100.

The API management system 100 may enable efficient communication between different systems or services. In this case, the API management system 100 may standardize the API as an HTTP/JSON-based REST API in order to link different internal systems or internal and external systems. Through this, it is possible to communicate with each other even if the implementation method of the target to be linked is not known, and unnecessary development can be reduced, thereby saving cost and time.

In addition, the API management system 100 may perform API management, access control, message conversion and analysis functions. For example, API management may include overall management functions such as creation, inquiry, modification, and deletion of APIs, and access control may include a function of controlling APIs to be used only by authorized users. In addition, message conversion includes a function of converting communication between different services into a form that can be interconnected, and the analysis function may include a function of collecting API call information and allowing an administrator to analyze it.

In particular, the API management system 100 may manage by assigning a transaction ID for each API call request received from the client 10. Specifically, the API management system 100 may assign a transaction ID to each API call request, and monitor the overall flow and status from the API call request to the response. For example, the API management system 100 may log the API for each preset interval based on the transaction ID to enable tracking of a time required for a message processing process and an error. As such, the API management system 100 can easily check in which part an error has occurred through the transaction ID, and thus can respond more quickly when a failure occurs.

As described above, the API management system 100 according to an embodiment disclosed in this document does not need to develop a separate resource in the customer's system, so that downtime provided to users does not occur, and thus a smooth service can be provided. In addition, the API management system 100 according to an embodiment disclosed in this document can easily check which part of the error has occurred through the transaction ID given for each API call request, so that a quick response. Is possible.

2 is a block diagram showing the configuration of an API management system according to an embodiment disclosed in this document.

2, the API management system 100 according to an embodiment disclosed in this document may include an API gateway 110, a conversion mediation server 120, an administrator server 130, and a user server 140. have.

The API gateway 110 may manage an API received from a client. The API gateway 110 may be middleware that integrates an end point for an API and provides an additional function.

For example, the API gateway 110 may perform routing of an API call request received from a client, or may perform authentication and authorization for a user. In addition, the API gateway 110 may perform a flow rate control function for an API call request from a client, a function of preventing failure propagation, and the like. A detailed function of the API gateway 110 will be described later in FIG. 3.

The conversion mediation server 120 may convert the API received from the API gateway 110 and transmit it to an external system. Specifically, the conversion mediation server 120 supports various protocols such as TCP/IP, JDBC, and HTTP to enable linkage between heterogeneous systems, and provides a message conversion solution capable of linking with various services such as EAI and MCI. can do.

For example, the conversion mediation server 120 may perform routing of an API received from the API gateway 110 or may perform tracking monitoring for each API. In addition, the conversion mediation server 120 may perform message conversion and user-defined conversion functions of the received API. A specific function of the conversion mediation server 120 will be described later in FIG. 4.

The manager server 130 may perform management and control functions of the API gateway 110 and the conversion mediation server 120. For example, the manager server 130 may create, manage, and set rules of an API, and may set whether to approve the use of the API of the dashboard and statistical data verification user server 140. In this case, the manager server 130 may provide the above-described functions on the web site.

Specifically, the manager server 130 may perform a function of creating a domain by grouping APIs to facilitate the use and management of the API, and searching and managing the domain. In addition, the manager server 130 may display data related to the system such as CPU and real-time JVM memory through the dashboard and data such as the number of calls and failures by time slot based on the transaction ID assigned to each API in a graph.

The manager server 130 provides setting functions such as inquiry, creation, modification, deletion of each service such as a route, service, and user with respect to the API gateway 110, and a resolver with respect to the conversion mediation server 120, Setting functions such as inquiry, creation, modification and deletion of each service such as proxy and bridge can be provided. In addition, the administrator server 130 provides settings such as user inquiry, creation, modification, deletion, and access rights management functions for each domain, and setting functions such as approval or rejection of use of APIs requested by the user server 140 Can provide.

The user server 140 may manage the client to use an API provided by an external system. In this case, the manager server 130 may provide a function of checking specifications and requesting use of an API managed and provided by the manager server 130. For example, the user may use functions such as requesting, approval, and cancellation of API use through the user server 140.

Specifically, when the manager server 130 applies a separate authentication filter to a specific route or service, the user server 140 may provide a function of requesting use of a corresponding API. In this case, you can issue an authentication key for each requested API and cancel the use. In addition, the user server 140 may inquire, create, and modify API users, and it may be possible to check authentication key management, API request details, API usage status, etc. for each user.

As described above, the API management system according to an embodiment disclosed in the present document does not need to develop a separate resource in the customer's system, so that downtime provided to users does not occur, and thus a smooth service can be provided.

In addition, in the API management system according to an embodiment disclosed in this document, when an error occurs internally in the system through a transaction ID assigned to each API call, it is possible to easily check in which part the error has occurred, so that a quick response is possible.

In addition, the API management system according to an embodiment disclosed in this document can manage from an API call request to a response in a single flow, and it is possible to easily add resources for providing an API from a remote system to the inside or outside. The system administrator can more conveniently manage the life cycle of the API provided internally.

In addition, the API management system according to an embodiment disclosed in this document can statistically check the API call request proceeding in one flow and visually monitor the failure situation in the linked system, It is possible to quickly detect a failure and reduce unnecessary waste of resources to check it.

In addition, the API management system according to an embodiment disclosed in this document can manage API calls in which a failure has occurred, and accordingly, can improve the quality of service of clients and external systems.

3 is a block diagram showing the configuration of an API gateway of an API management system according to an embodiment disclosed in this document.

Referring to FIG. 3, the API gateway 110 of the API management system 100 according to an embodiment disclosed in this document performs a function of managing an API received from a client, and includes a request processing unit 111 and a filter unit. (112), it may include a failure propagation prevention unit 113 and a load balancing unit 114.

The request processing unit 111 may route the API according to the path requested from the client. In this case, the request processing unit 111 may process an API call request from a client through a non-blocking method. For example, the request processing unit 111 may process an API call request in an asynchronous manner through an event loop.

In the case of the conventional blocking method, a thread is created for each request, and when a thread is in use, the requesting thread is kept in a standby state. In this case, since the server has a limited number of request threads, if requests are being executed as many as the maximum number of threads of the server, other requests cannot be processed, thereby reducing performance and limiting overall utilization of server functions.

However, the request processing unit 111 of the API gateway 110 disclosed in this document does not create a thread for each request through a non-blocking method, and may perform a request process asynchronously through an event loop between processes. . Through this, a delay of a request does not occur, and the API gateway 110 that processes a number of API call requests can operate smoothly.

The filter unit 112 may control the frequency of the API call request based on logic set by the user. In this case, the filter unit 112 may determine the maximum number of requests available for the API based on time according to the set logic. For example, the filter unit 112 may perform a flow rate control function by designating the maximum number of requests based on time, such as 5 times per second, 10 times per hour, or 3000 times per 30 days. This logic can be set for each API and user.

In addition, the filter unit 112 may perform authentication as to whether or not to allow access of the client for each route, service, and user of the API according to the set logic. For example, when performing authentication based on an API route, a service, and a user, the filter unit 112 may issue an authentication key for each API in response to an application for use from a client. As described above, the filter unit 112 of the API gateway 110 according to an embodiment disclosed in this document saves system resources by executing only the logic set by the user, unlike the conventional method of performing all unnecessary logic. You can save.

The failure propagation prevention unit 113 may perform a circuit breaker function to stop delivery of an API call request to a system in which a failure occurs among external systems. For example, the failure propagation prevention unit 113 may stop delivery of an API call request to a system in which a response error occurs above a set threshold among external systems.

In addition, the failure propagation prevention unit 113 may provide an alternative response based on a preset value while the delivery of the API call request is stopped. In this case, the client or the remote system may perform separately set logic according to the alternate response.

In addition, the failure propagation prevention unit 113 may check whether the remote system operates normally after a preset time while the delivery of the API call request is stopped, and automatically resume the stopped API service if the response is normal.

In the existing integrated system, when one of several services is slowed down or a failure occurs, the failure is propagated to a subordinate service that calls the service in which the failure occurs. Accordingly, failure may occur not only in the service in which the failure occurred, but also other services, which may cause problems in the entire system.

Meanwhile, in the case of the failure propagation prevention unit 113 of the API gateway 110 disclosed in this document, it is possible to prevent such failure propagation in advance, and by stopping the delivery of requests for the corresponding service until the service in which the failure occurred is restored. , It can prevent the propagation of faults to other services.

The load balancer 114 may distribute an API call request based on a preset switching process. In this case, the load balancer 114 may distribute the API call request according to a preset value in units of groups of services registered in the switching process. For example, the load balancer 114 may distribute the API in a manner such as round robin, weighted round robin, weighting for each average response time, or the like.

In the existing load balancing method, a physical switch device is placed in front of the server, and all external requests are distributed through the switch device. However, such a physical method was not possible to perform a load balancing function for each service group registered in the API gateway. On the other hand, the load balancing unit 114 of the API gateway 110 according to an embodiment disclosed in this document distributes the API call request through a software-type switch process, so that a separate physical device is not required, and a registered service group Various load balancing is possible for each.

4 is a block diagram showing the configuration of a conversion mediation server of an API management system according to an embodiment disclosed in this document.

Referring to FIG. 4, the conversion mediation server 120 of the API management system according to an embodiment disclosed in this document performs communication between an API gateway and an external system, and includes a routing unit 121 and a monitoring unit 122. , A custom conversion unit 123 and a message conversion unit 124 may be included.

The routing unit 121 may provide a service related to the external system through an HTTP/JSON based API.

The monitoring unit 122 may monitor the state of the API. Specifically, the monitoring unit 122 may perform monitoring of the overall flow and status from the request to the response of the API by assigning a transaction ID to each API call request. In this case, the monitoring unit 122 logs the API for each preset section to enable tracking of the time required for the message processing process and errors, thereby enabling a more rapid response when a failure occurs. Meanwhile, the monitoring unit 122 may be included in the API gateway 110 in addition to the conversion mediation server 120. In this case, the functions of the monitoring unit 122 included in the API gateway 110 may be substantially the same.

Specifically, the monitoring unit 122 assigns a separate transaction ID for each API call request, and processes data for each step between the client 10-API gateway 110-conversion mediation server 120-remote system 20 Can be checked. If an error occurs internally in the API management system 100, it is possible to easily check where the error has occurred through the transaction ID, so that a quick response is possible. By using the data accumulated in this way, it is possible to provide basic information such as success/failure for each API call request, as well as statistical data such as process time.

The custom conversion unit 123 may define a message conversion rule for an API. For example, the custom conversion unit 123 may define a message conversion rule in the form of a script. In this way, when a message conversion rule is defined in the form of a script, a new rule can be applied without additional coding or restarting the service.

In the case of adding message conversion logic, the existing message conversion method had to be developed separately and provided through program restart. On the other hand, the custom conversion unit 123 of the conversion mediation server 120 according to an embodiment disclosed in this document has a message conversion rule defined as a script, so that a new rule can be applied without separate development and service restart.

The message conversion unit 124 may convert a message included in the API according to a message conversion rule. For example, the message conversion unit 124 may convert a message in at least one of a header and a body of an API. Also, the message conversion unit 124 may perform a preset conversion for each message. For example, the message conversion unit 124 may perform encryption/decryption, masking, padding, encoding/decoding, validation check, and the like. Through this, the message conversion unit 124 may provide variously converted message types according to communication environments of various remote systems.

In addition, the message conversion unit 124 may provide a plurality of communication protocols that can be linked with various remote systems. For example, the communication protocol provided by the message conversion unit 124 may include TCP/IP, JDBC, HTTP, and the like. That is, the message conversion unit 124 may convert a communication protocol before and after the message conversion.

When receiving an API call request from the conversion mediation server 120, a proxy (for example, a mediation function according to a request from another network service) and a bridge (for example, data change through calculation or set operation for each message) Function) can be called sequentially to request data from a remote system. In this case, the message conversion unit 124 applies a conversion rule provided by default or a conversion rule generated by the custom conversion unit 123 to a message (parameter) in the header or body of the API call delivered in each step. , User can apply the desired process step by step.

5 is a diagram illustrating an API management method according to an embodiment disclosed in this document.

Referring to FIG. 5, the API management method according to an embodiment disclosed in this document first, when routing an API according to a path requested from a client, performs processing of an API call request from a client through a non-blocking method. It can be done (S110). For example, in step S110, an API call request may be processed in an asynchronous manner through an event loop.

In addition, the frequency of the API call request may be controlled based on the logic set by the user (S120). In this case, in step S120, the maximum number of requests available for the API may be determined based on time according to the set logic. This logic can be set for each API, service, and user.

In addition, in step S120, authentication regarding whether or not to allow access of the client for each of the API routes, services, and users may be performed according to the set logic. For example, when authentication is performed based on an API route, service, and user, an authentication key may be issued for each API in response to an application for use from a client.

Next, delivery of an API call request to a system in which a failure occurs among external systems may be stopped (S130). For example, in step S130, delivery of an API call request may be stopped to a system in which a response error occurs more than a set threshold among external systems. In addition, while the delivery of the API call request is stopped, an alternative response may be provided based on a preset value. In this case, the client or the remote system may perform separately set logic according to the alternate response.

In addition, in step S130, while the delivery of the API call request is stopped, it is possible to automatically restart the stopped API service if the response is normal by checking whether the remote system is operating normally after a preset time.

In addition, the API call request may be distributed based on a preset switching process (S140). In this case, the API call request may be distributed according to a preset value in units of groups of services registered in the software type switching process. For example, the API can be distributed in a manner such as round robin, weighted round robin, and weighting for each average response time.

Next, it is possible to monitor the state of the API (S160). Specifically, in step S160, a transaction ID is assigned to each of the API call requests, and the overall flow and status of the API request to the response may be monitored. In this case, by logging the API for each preset section, the time required for the message processing process and the error can be traced, thereby enabling a more rapid response in the event of a failure.

And, it is possible to define a message conversion rule for the API (S160). For example, in step S170, a message conversion rule may be defined in the form of a script. In this way, when a message conversion rule is defined in the form of a script, a new rule can be applied without additional coding or restarting the service. In addition, a message included in the API may be converted according to a message conversion rule (S170). For example, in step S170, a message in at least one of a header and a body of the API may be converted. At this time, a preset conversion may be performed.

In addition, in step S170, a plurality of communication protocols capable of linking with various remote systems may be provided. For example, the communication protocol provided in step S170 may include TCP/IP, JDBC, HTTP, and the like. That is, in step S170, the communication protocol may be converted before and after the message is converted.

Steps S110 to S140 described above may be performed by the API gateway 110, and steps S150 to S170 may be performed by the conversion mediation server 120. However, the API management method according to an embodiment disclosed in this document is not limited thereto, and the subject performing each step may be changed as necessary.

As described above, the API management method according to an embodiment disclosed in this document does not need to develop a separate resource in the customer's system and thus does not generate downtime provided to users, and thus, a smooth service can be provided.

In addition, in the API management method according to an embodiment disclosed in this document, when an error occurs internally in the system through a transaction ID assigned for each API call, it is possible to easily check where the error has occurred, so that quick response is possible. It is possible.

The API management method according to an embodiment disclosed in this document can manage from an API call request to a response in a single flow, and it is possible to easily add resources for providing an API from a remote system to the inside or outside of the remote system. The life cycle of the API provided by the administrator can be managed more conveniently.

In addition, the API management method according to an embodiment disclosed in this document can statistically check the API call request proceeding as a single flow and visually monitor the failure situation in the linked system. It is possible to quickly detect a failure and reduce unnecessary waste of resources to check it.

In addition, the API management method according to an embodiment disclosed in this document can manage an API call in which a failure has occurred, and accordingly, can improve service quality of a client and an external system.

6 is a block diagram showing a hardware configuration of a computing system that performs an API management method according to an embodiment disclosed in this document.

6, a computing system 1000 according to an embodiment disclosed in this document may include an MCU 1010, a memory 1020, an input/output I/F 730, and a communication I/F 1040. have.

The MCU 1010 executes various programs (e.g., API management (routing, filtering, monitoring, etc.) programs, message conversion programs, etc.) stored in the memory 1020, and requests API calls and transactions through these programs. It may be a processor that processes various data such as IDs and various messages, and performs functions of the API management system 100 shown in FIG. 2 described above.

The memory 1020 may store various programs related to API management and message conversion. In addition, the memory 1020 may store various data such as an API call request received from a client, a transaction ID generated through the conversion mediation server 120, and a message.

A plurality of such memories 1020 may be provided as needed. The memory 1020 may be a volatile memory or a nonvolatile memory. As the memory 1020 as a volatile memory, RAM, DRAM, SRAM, or the like may be used. As the memory 1020 as a nonvolatile memory, ROM, PROM, EAROM, EPROM, EEPROM, flash memory, or the like may be used. Examples of the above-listed memories 1020 are merely examples and are not limited to these examples.

The input/output I/F 1030 is an interface that allows data to be transmitted/received by connecting an input device (not shown) such as a keyboard, a mouse, and a touch panel, and an output device such as a display (not shown), and the MCU 1010 Can provide.

The communication I/F 1040 is a component capable of transmitting and receiving various data to and from a server, and may be various devices capable of supporting wired or wireless communication. For example, through the communication I/F 1040, programs for API management and message conversion, API call requests, transaction IDs, and various data such as messages may be transmitted and received from an external server provided separately.

In this way, the computer program according to the exemplary embodiment disclosed in this document is recorded in the memory 1020 and processed by the MCU 1010, so that it may be implemented as, for example, a module that performs each function shown in FIG. 2. have.

In the above, just because all the constituent elements constituting the embodiments disclosed in this document have been described as being combined into one or operating in combination, the embodiments disclosed in this document are not necessarily limited to these embodiments. That is, as long as it is within the scope of the objectives of the embodiments disclosed in this document, one or more of the components may be selectively combined and operated.

In addition, terms such as "include", "consist of" or "have" described above mean that the corresponding component may be present unless otherwise stated, excluding other components. It should not be construed as being able to further include other components. All terms, including technical or scientific terms, unless otherwise defined, have the same meaning as commonly understood by a person of ordinary skill in the art to which the embodiments disclosed in this document belong. Terms generally used, such as terms defined in the dictionary, should be interpreted as being consistent with the meaning of the context of the related technology, and should not be interpreted as an ideal or excessively formal meaning unless explicitly defined in this document.

The above description is merely illustrative of the technical idea disclosed in this document, and those of ordinary skill in the technical field to which the embodiments disclosed in this document belong to within the scope not departing from the essential characteristics of the embodiments disclosed in this document. Various modifications and variations will be possible. Accordingly, the embodiments disclosed in this document are not intended to limit the technical idea of the embodiments disclosed in this document, but to describe, and the scope of the technical idea disclosed in this document is not limited by these embodiments. The scope of protection of the technical ideas disclosed in this document should be interpreted by the scope of the claims below, and all technical ideas within the scope equivalent thereto should be construed as being included in the scope of the rights of this document.

10: client 20: external system
100: API management system 110: API gateway
111: request processing unit 120: filter unit
130: failure propagation prevention unit 140: load balancing unit
120: conversion mediation server 121: routing unit
122: monitoring unit 123: custom conversion unit
124: message conversion unit 130: administrator server
140: user server 1000: computing system
1010: MCU 1020: memory
1030: I/O I/F 1040: Communication I/F

Claims (15)

An API gateway that manages an API call request received from a client;
A conversion mediation server that assigns a transaction ID for each API call request transmitted from the API gateway, and processes the API call request by communicating with an external system;
A manager server that creates a domain by grouping the APIs, and displays data including the number of calls and failures by time slot in a graph based on a transaction ID assigned to each API; And
As a system including a user server that provides a function for requesting use of a corresponding API when a separate authentication filter is applied to a specific route or service in the administrator server,
The API gateway,
A request processing unit that processes an API call request from the client through a non-blocking method;
A filter unit controlling a frequency of the API call request based on a logic set by a user;
A failure propagation prevention unit for stopping delivery of the API call request to a system in which a failure occurs among the external systems; And
Includes a load balancing unit for distributing the API call request based on a preset switching process,
The conversion mediation server,
A routing unit that provides a service related to the external system through an HTTP/JSON based API;
A monitoring unit monitoring the state of the API;
A custom conversion unit for generating a message conversion rule for the API defined by the user; And
A message conversion unit for converting a message included in the API according to the message conversion rule,
The API management system for tracking the time required for the message processing process and errors by the monitoring unit logging the API for each preset interval based on the transaction ID. The method according to claim 1,
The request processing unit is an API management system that processes the API call request in an asynchronous manner through an event loop. The method according to claim 1,
The filter unit is an API management system for authenticating whether access of the client is permitted for each route, service, and user of the API according to the logic. The method according to claim 1,
The API management system for the filter unit to determine the maximum number of times the API can be requested based on time according to the logic. The method according to claim 1,
The failure propagation prevention unit stops the delivery of the API call request to a failure system in which a response error exceeds a threshold value among the external systems. The method of claim 5,
The failure propagation prevention unit provides an alternative response based on a preset value while the delivery of the API call request to the failure system is stopped. The method of claim 5,
When the delivery of the API call request to the faulty system is stopped, the fault propagation prevention unit transmits the API connection request to the faulty system after a preset time, and when the faulty system operates normally again, the faulty system is operated again without any separate operation. API management system that resumes API call requests. The method according to claim 1,
The load balancing unit is an API management system that distributes the API call request according to a preset value in units of a group of services registered in the switching process. The method according to claim 1,
The API management system for providing a plurality of communication protocols linkable with the external system in the routing unit. delete The method according to claim 1,
The custom conversion unit API management system for defining the message conversion rule in the form of a script. The method according to claim 1,
The message conversion unit API management system for converting a message in at least one of a header and a body of the API. The method according to claim 1,
The message conversion unit API management system for performing a preset conversion for each of the messages. The method according to claim 1,
When the filter unit performs authentication based on the route, service, and user of the API, an API management system that issues an authentication key for each API in response to a request for use from the client. An API gateway that manages an API call request received from a client;
A conversion mediation server that assigns a transaction ID for each API call request transmitted from the API gateway, and processes the API call request by communicating with an external system;
A manager server that creates a domain by grouping the APIs, and displays data including the number of calls and failures by time slot in a graph based on a transaction ID assigned to each API; And
As an API management method using a system including a user server that provides a function for requesting use of a corresponding API when a separate authentication filter is applied to a specific route or service in the manager server,
Processing an API call request from the client through a non-blocking method;
Controlling a frequency of the API call request based on a logic set by a user;
Stopping delivery of the API call request to a system in which a failure occurred among the external systems;
Distributing the API call request based on a preset switching process;
Providing a service related to the external system through an HTTP/JSON based API;
Monitoring the state of the API;
Generating a message conversion rule for the API defined by the user; And
Including the step of converting the message included in the API according to the message conversion rule,
In the step of monitoring the state of the API, the API is logged for each preset interval based on the transaction ID to track a time required for a message processing process and an error.

Images