KR20170062244A

KR20170062244A - Api managing apparatus

Info

Publication number: KR20170062244A
Application number: KR1020150167817A
Authority: KR
Inventors: 안성욱; 김기용
Original assignee: 주식회사 비디
Priority date: 2015-11-27
Filing date: 2015-11-27
Publication date: 2017-06-07

Abstract

The API management apparatus includes at least one API gateway module including a local cache for receiving requests of an API (Application Programming Interface) service from a user and storing API service environment information for determining suitability of the API service, A manager portal module for managing and controlling information about the API asset, and a source cache for synchronizing the local cache, the API asset including an API asset generated by an API asset provider, And an API integrated management module for updating the API. Accordingly, the API management apparatus can provide functions for facilitating management by making REST APIs for contents and services, and for facilitating API development.

Description

[0002] API MANAGING APPARATUS [0003]

The present invention relates to a computer-executable API management method and an API management apparatus, and more particularly, to a method and apparatus for quickly designing a new API from existing business assets or cloud services, And an API management apparatus and an API management method capable of performing efficient API management by performing analysis and measurement functions.

In recent years, with the development of mobile applications and SNS, interest in Open API has increased rapidly. The Open API is a model that allows an external developer to create a new service using an API by releasing the API to not only internal users but also external developers. In recent years, even APIs have been developed and serviced professionally to create business models that generate profits. In this context, the importance of API management has emerged, and there is a need for easy management, monitoring and monetization of APIs, convenient use of APIs, and sample code and manual scenarios. Is called the API platform.

Korean Patent No. 10-1528853 relates to a public API service, which includes generating metadata for executing an API, generating resource data for generating a mashup of an API, Creating mashup content from various types of APIs by creating API data including API, metadata, resource data, and description data by generating technical data for resource data The present invention provides

Korean Patent No. 10-1528853

One embodiment of the present invention is to provide a computer executable API management method and an API management apparatus that facilitate management by making REST APIs for contents and services and facilitate API development.

An embodiment of the present invention is to provide a computer-executable API management method and an API management apparatus capable of stably processing and controlling large-volume traffic by managing traffic of an API.

An embodiment of the present invention is to provide a computer-executable API management method and an API management apparatus capable of minimizing a delay time due to API distribution processing and API processing by applying various caching based on a distributed environment.

Among the embodiments, the API management apparatus distributes API (Application Programming Interface) service requests from users in a distributed manner, and each API At least one API gateway module including a local cache for storing service environment information, a manager portal module for managing and controlling information about the API asset, the API portal module including an API asset generated by an API asset provider, And an API integrated management module that includes a source cache for synchronizing and continuously updates the suitability of the API service.

In one embodiment, each of the at least one API gateway modules may detect the presence or absence of the updated content in the corresponding local cache and maintain consistency between the corresponding local cache and the original cache when the updated content is received from the source cache .

Each of the at least one API gateway module may notify the original cache of the necessity of the update when the corresponding local cache is to be updated according to a request of the API service.

In one embodiment, each of the at least one API gateway module may temporarily limit the API service by throttling a request for the API service based on a temporal service constraint.

Each of the at least one API gateway module may re-throttle the request of the API service based on a service level protocol condition preset between the API asset provider and the user to re-determine whether to provide the API service.

Each of the at least one API gateway module may determine accessibility to the API asset through authentication and authorization of the user.

Each of the at least one API gateway module may provide an arbitration function through message conversion between the API service request message format of the user and the API asset message format of the administrator portal module.

The API integrated management module may distribute the request of the API service through each of the at least one API gateway module to minimize the delay time according to the request processing of the API service.

The API integrated management module may count the API service requests in real time based on the service level protocol condition and cause each of the at least one API gateway module to perform throttling related to the request of the API service in real time .

The API integrated management module collects information on the API service request and the API service from each of the at least one API gateway module, and performs distributed parallel processing and analysis to provide statistical information.

The disclosed technique may have the following effects. It is to be understood, however, that the scope of the disclosed technology is not to be construed as limited thereby, as it is not meant to imply that a particular embodiment should include all of the following effects or only the following effects.

The computer-executable API management method and the API management apparatus according to an embodiment of the present invention can provide functions to facilitate management by making REST APIs for contents and services, and to facilitate API development.

A computer-executable API management method and an API management apparatus according to an embodiment of the present invention can manage API traffic and stably process and control large-capacity traffic.

The computer-executable API management method and the API management apparatus according to an embodiment of the present invention can minimize delay time due to API distribution processing and API processing by applying various caching based on a distributed environment.

1 is a block diagram illustrating a conceptual structure of an API management apparatus according to an embodiment of the present invention.
2 is a block diagram illustrating a structure of an API management apparatus including an API integrated management module according to an embodiment of the present invention.
3 is a block diagram illustrating the configuration of the API gateway module shown in FIG.
4 is a flowchart illustrating the overall operation of the API gateway module shown in FIG.
5 is a view for explaining a method of verifying the validity of a user's API service request by the validity verification unit shown in FIG.
FIG. 6 is a diagram for explaining a method of controlling overflow and controlling traffic by controlling API calls of the throttling unit shown in FIG. 3. FIG.
FIG. 7 is a diagram for explaining a method for the authentication unit in FIG. 3 to process user authentication and grant an API authority.
8 is a diagram illustrating an additional method used for security enhancement management for the administrator portal module access in FIG.
9 is a view for explaining that the OAuth authentication unit in FIG. 1 provides a standardized authentication method.
FIG. 10 is a diagram for explaining that the arbitration unit in FIG. 3 converts and provides an API service request message format and an API asset message format.
FIG. 11 is a diagram for explaining that the cache management unit in FIG. 2 distributes APIs based on a distributed environment.
FIG. 12 is a view for explaining that the analysis measurement management unit in FIG. 2 provides statistical information through log information collected in an API gateway module.
13 is a diagram for explaining a process in which the response data management unit in FIG. 2 returns the response data to the API gateway module.

The description of the present invention is merely an example for structural or functional explanation, and the scope of the present invention should not be construed as being limited by the embodiments described in the text. That is, the embodiments are to be construed as being variously embodied and having various forms, so that the scope of the present invention should be understood to include equivalents capable of realizing technical ideas. Also, the purpose or effect of the present invention should not be construed as limiting the scope of the present invention, since it does not mean that a specific embodiment should include all or only such effect.

Meanwhile, the meaning of the terms described in the present application should be understood as follows.

The terms "first "," second ", and the like are intended to distinguish one element from another, and the scope of the right should not be limited by these terms. For example, the first component may be referred to as a second component, and similarly, the second component may also be referred to as a first component.

It is to be understood that when an element is referred to as being "connected" to another element, it may be directly connected to the other element, but there may be other elements in between. On the other hand, when an element is referred to as being "directly connected" to another element, it should be understood that there are no other elements in between. On the other hand, other expressions that describe the relationship between components, such as "between" and "between" or "neighboring to" and "directly adjacent to" should be interpreted as well.

It is to be understood that the singular " include " or "have" are to be construed as including the stated feature, number, step, operation, It is to be understood that the combination is intended to specify that it does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or combinations thereof.

In each step, the identification code (e.g., a, b, c, etc.) is used for convenience of explanation, the identification code does not describe the order of each step, Unless otherwise stated, it may occur differently from the stated order. That is, each step may occur in the same order as described, may be performed substantially concurrently, or may be performed in reverse order.

The present invention can be embodied as computer-readable code on a computer-readable recording medium, and the computer-readable recording medium includes all kinds of recording devices for storing data that can be read by a computer system . Examples of the computer-readable recording medium include a ROM, a RAM, a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like, and also implemented in the form of a carrier wave (for example, transmission over the Internet) . In addition, the computer-readable recording medium may be distributed over network-connected computer systems so that computer readable codes can be stored and executed in a distributed manner.

All terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs, unless otherwise defined. Commonly used predefined terms should be interpreted to be consistent with the meanings in the context of the related art and can not be interpreted as having ideal or overly formal meaning unless explicitly defined in the present application.

1 is a structural diagram illustrating a conceptual structure of an API management apparatus 10 according to an embodiment of the present invention.

Referring to FIG. 1, the API management apparatus 10 includes a developer portal module 100, an API gateway module 200, a manager portal module 300, and an OAuth authentication unit 400. In Fig. 1, an end user and a developer collectively can be referred to as a user. An application may correspond to an application or service that the end user or developer wants to use. An API is a collection of interfaces that allow you to control the functions provided by an operating system or programming language for use in an application program. The developer portal module 100 may denote a developer center, and the manager portal module 300 may mean a management center.

The developer portal module 100 can provide API users with information on the application, information on the API, usage of the API, API samples, and the function of performing the API test. That is, the developer portal module 100 can provide convenience to the user as well as API development.

The developer portal module 100 may issue an API key or an application key and may select a service level agreement (SLA) presented by the administrator portal module 300. An SLA is a quality assurance system, which means that it meets the quality requirements of a certain level of service. For example, if the service level agreement condition is provided to the administrator portal module 300 to provide 5000 calls per day for each API asset provider or to provide 1000 calls per API user per day , The API gateway module 200 provides an API service only up to 1000 calls per day or 1000 calls per API user for each API asset provider based on the selected service level protocol condition through the developer portal module 100 . That is, the developer portal module 100 can adjust the service level (QoS, Quality of Service) for each contract level. Here, an asset or service can mean an API.

In addition, the developer portal module 100 may provide functions for providing an API to an external API user, sharing APIs between departments within the enterprise without selling APIs, and making APIs easy to use. Therefore, there is an effect that the development productivity can be enhanced.

The API gateway module 200 unifies and bundles the endpoints of the asset / service, validates the API request, security functions through authentication and authorization for the API access, server overload prevention through access control to the API, Control functions, routing to multiple servers according to messages, distributed memory caching, caching data monitoring, and service utilization statistics. The API gateway module 200 provides a user with a desired API and access to an asset or a service. That is, the API gateway module 200 may remotely call the API from the API provider or provide the API to the user registered in the asset or service. The API gateway module 200 will be described in more detail below with reference to FIG.

The manager portal module 300 includes the API assets generated by the API asset provider and can manage and control information about APIs generated by the API asset provider. In addition, the manager portal module 300 can present the SLA criteria described above, and can provide information on the capacity of the API, manage the API, and provide control functions for abusing the API. In other words, the manager portal module 300 can store the cache information related to the API information, authentication / verification, access restriction policy, service information, quality of service (QoS), service level agreement (SLA) Data can be monitored to perform management of the user's API calls and the provision of the called APIs.

The OAuth authentication unit 400 may provide a standardized user authentication and authorization method using an access token when a user's API service request is made. The OAuth authentication unit 400 can perform user authentication using OAuth 2.0, which is a standard authentication method for individual APIs. Accordingly, the OAuth authentication unit 400 can provide enhanced security functions for user authentication and authority verification of the API gateway module 200. OAuth standardizes the authentication method used for each application so that applications that share the authentication need not be authenticated separately so that various applications can be integrated and used. The OAuth will be described in detail with reference to FIG.

2 is a structural diagram illustrating the structure of an API management apparatus 10 including an API integrated management module 20 according to an embodiment of the present invention.

Referring to FIG. 2, the API management apparatus 10 may include at least one API (Application Programming Interface) service for distributing API service (API) service requests from a user and storing API service environment information An API gateway module 200, an original that contains the API assets generated by the API asset provider, and synchronizes the manager portal module 300 and the local cache 260 that manage the API asset or service provision according to the request of the API service And an API integration management module 20 that includes caches 530 and 730 and continuously updates the provisioning suitability of the API service.

That is, the API management apparatus 10 includes a cache management unit 500, a real-time count management unit 600, an analytical measurement management unit 600, and the like, in addition to the developer portal module 100, the API gateway module 200, And an API integration management module 20 including a response data management module 700 and a response data management module 800.

The API management device 10 including the API integrated management module 20 can easily and effectively support traffic management, security management, version management, authentication, monitoring, and analysis of APIs for API development, management, and operation.

In addition, the API management apparatus 10 can be an on-premise system in various infrastructure environments such as Cloud Stack, Open Stack, VMware, Internet Data Center (IDC), and Amazon Web Service (AWS) ), A private cloud, an open cloud, and a hybrid cloud. Therefore, according to the type of service desired by the user, an API You can easily connect them. The API integrated management module 20 can manage the integrated information related to the use of the API service.

2 includes an internal interface module 510 for connecting the API integrated management module 20 and the administrator portal module 300, a local cache 260 for each of the at least one API gateway module 200, And a source cache or cache storage module 530 that synchronizes the source cache 530 and 730 of the API integrated management module 20 to update the local cache 260. [

The cache management unit 500 can minimize the delay time according to the request processing of the API service by distributing the request of the user API service through each of the at least one API gateway module 200. [ The API distribution processing using the cache management unit 500 will be described in detail with reference to FIG.

The real-time count management unit 600 includes a cache counter module 610 for counting API service requests through real-time caching of a user's API service request, a real-time monitoring unit for counting API service requests counted through the cache counter module 610, A count management module 620 and a source cache or cache repository 630 for ensuring and managing the quality of service (QoS) and SLA (Service Level Agreement). In more detail, the real-time count management unit 600 guarantees QoS and SLA by subtracting the API service call of the user who real-time cached. The caching information for the API service call deduction of the user is stored in the original cache 630. The real-time count management unit 600 guarantees the QoS and SLA of the API asset through real-time count caching, and allows the API gateway module 200 to restrict the request of the API service in real time. That is, the API gateway module 200 can control the traffic according to the request of the API service through the real-time count management unit 600. The traffic control according to the request of the API service will be described in detail with reference to FIG.

The analysis measurement management unit 700 may include a statistical analysis module 710, an abnormal transaction analysis module 720, and a source cache 730.

The statistical analysis module 710 may collect log information from the logging unit 240 of the API gateway module 200 and store the collected log information in a database, a search engine, or a MapReduce. Here, the log information may include validation of user API service request, authentication contents, authorization, traffic control, or contents of a call regarding an API asset and whether or not there is a call error. The statistical analysis module 710 can generate various statistical information using the collected log information, and the statistical information can be inquired by the developer portal module 100 or the manager portal module 300. [

The abnormal transaction analysis module 720 can collect log information from the API gateway module 200 at predetermined time intervals. For example, the abnormal transaction analysis module 720 may collect log information at intervals of one minute. The abnormal transaction analysis module 720 determines whether the access restriction to the abnormal transaction and the lock time are controlled based on the IP of the collected log information.

The original cache 730 may store information on whether to restrict access to an IP-based abnormal transaction or not and whether to control the lock time in a predetermined time interval unit. Each of the API gateway modules 200 synchronizes the local cache 260 with the original cache 730 of the analysis measurement management unit 700 to determine whether the transaction is abnormal or not. can do. That is, the analysis measurement management unit 700 may provide backup data (Backup Data) for restricting access to abnormal transactions and performing lock time control in the API gateway module 200. 12, the analysis measurement management unit 700 will be described in detail.

The response data management unit 800 can manage response data for an asset or a service and can include a response cache management module 810 and a source cache 820. [

The response cache management module 810 determines whether there is data in the source cache 820 when the arbiter 250 of the API gateway 200 calls the response cache management module 820 through the response cache management module 820 Can be confirmed. The response cache management module 810 calls the asset / service to store the response data in the original cache 820 if there is no response cache for the asset or service in the inquiry result source cache 820, Lt; / RTI > may return the response data to processor 250, Here, an asset or a service that requires a response cache may correspond to a push, a social service, or the like.

The source cache 820 may store response data for an inquiry of an asset or service that requires a response cache. In one embodiment, the source cache 820 may delete the response data every predetermined period. The operation of the response data management unit 800 will be described later in detail with reference to FIG.

3 is a block diagram illustrating the configuration of the API gateway module 200 shown in FIG.

Referring to FIG. 3, the API gateway module 200 may include a validation unit 210, an authentication unit 220, a throttling unit 230, a logging unit 240, and an arbitration unit 250. In addition, the API gateway module 200 may include a local cache 260 for receiving API service requests from users in a distributed manner and storing API service environment information for determining suitability of the API services. Here, the API service provision conformance may refer to the service level protocol condition (SLA) described above, and the API service environment information may include application information using the API service, API service information, synchronized SLA information, , An authentication policy, an access restriction policy, service information, server information, or adapter information.

In one embodiment, each of the at least one API gateway modules 200 detects the presence or absence of updates in the local cache 260 upon receipt of updates from the original cache 530, 730, The correspondence between the original caches 530 and 730 can be maintained. In addition, each of the at least one API gateway module 200 may notify the source caches 530 and 730 of the necessity of updating when the corresponding local cache 260 is to be updated according to the API service request.

The validation unit 210 may check whether an API asset exists in response to a request for an API service. The validation unit 210 may perform access control and API call control for an asset or a service by verifying the validity of a URL and a header according to a user API service request. The validity verification unit 210 may perform validity verification by referring to the information stored in the local cache 260 of the API gateway module 200. Validation is software or manual inspection for error verification or standard conformance verification. That is, it is judged whether or not there is an error in the input value of the user, which means that the API service request of the user is judged to be appropriate. The validity verification method will be described in detail with reference to FIG.

The authentication / authorization unit 220 can determine the accessibility of the user's API asset through authentication and authorization of the user. In addition, the authentication / authorization unit 220 may perform authentication and authorization for the user by referring to the information stored in the local cache 260 of the API gateway module 200. Authentication is the function of verifying identity (that is, verification of the authentication key) to the user or client that invokes the API. Authorization or validation checks whether the user or client is authorized to invoke the API (I.e., whether the authenticated key and the API to be invoked are mutually mapped). For example, the authentication / authorization unit 220 may authenticate whether the user has an account when the user calls the API, and may permit the API call by determining whether the account is mapped to the calling API. The operation of the authentication / authorization unit 220 will be described later in detail with reference to FIG.

The throttling unit 230 may temporarily limit the API service by throttling a request of the user's API service based on the temporal service constraint condition. Here, the temporal service constraint means a condition for preventing an overload of an asset or a service. That is, the throttling unit 230 may temporarily limit the API service request through the temporal service constraint condition when the user's API service request is excessive at a time.

Also, the throttling unit 230 may re-throttle the request of the API service based on the service level protocol condition preset between the API asset provider and the user to re-determine whether to provide the API service. That is, the throttling unit 230 can provide a function of preventing overload of the asset or service and ensuring service quality by controlling traffic according to a user API service request. The operation of the throttle portion 230 will be described later in detail with reference to FIG.

The logging unit 240 can collect all logs when an API call is made. That is, the logging unit 240 may record validity of the user API service request, authentication, authorization, traffic control, or contents of the call regarding the API asset and the content of the call error. Analyzing the API call pattern can analyze the usage pattern of the user, so API call log is treated as a very important asset in conjunction with the big data area. The API call log can also be used as an important resource for tracking problems when they occur in the future. The logging unit 240 provides the collected logs to the analysis measurement management unit 700 of the API support module 20 to provide statistical information.

The arbitration unit 250 may perform conversion between a format of a user's API service request message and a message format of an API asset or service. That is, the arbiter 250 may provide the API with the API service data format requested by the user. For example, when a user requests a service of XML or JSON format, the API gateway module 200 may convert the API of REST structure into XML or JSON format and provide it. Representational State Transfer (REST) is a collection of network architecture principles. The term 'network architecture principle' refers to the way in which resources are defined and addressed to resources. In simple terms, this is a very simple interface for sending data on the web over HTTP without a separate transport layer such as SOAP or session tracking via cookies. The REST API refers to the Resource Oriented Architecture Web API. The operation of the arbitration unit 250 will be described later in detail with reference to FIG.

4 is a flowchart illustrating the overall operation of the API gateway module 200 shown in FIG.

Referring to FIG. 4, the API gateway module 200 may first receive a request for an API service from an application, a developer, or a user (S410). The validation unit 210 may perform validity checking on the existence of the URL, the header, and the API asset for the received API service request (S420). The throttling unit 230 may perform first throttling for requests (calls, calls) of API services of a plurality of validated users. The first throttling may be performed based on temporal service constraints. The throttling unit 230 may provide a wait message to the user when the user API service request exceeds an acceptance load of the asset or service unlike the temporal service constraint (S430). The authentication / authorization unit 220 may process the user authentication for the API service request of the user who has passed the first throttling and verify the API authorization (S440). The throttling unit 230 may perform the second throttling for the API service request of the user who has passed the authentication process. The second throttling refers to re-throttling the request of the user's API service based on the service level protocol condition preset between the API asset provider and the user. The throttling unit 230 may restrict the access to the API asset of the user by blocking the API service provision when the number of API service requests of the user exceeds the service level protocol condition (SLA) provided by the developer portal module 100 (S450). The arbiter 250 may convert the API service request message format to the API asset message format and convert the API asset message format to the response message format for the API service request of the user who has passed the second throttling (S460).

5 is a diagram for explaining a method for the validity verification unit 210 in FIG. 3 to verify the validity of a user's API service request.

Referring to FIG. 5, the validity verification unit 210 may perform validity verification by referring to the open API, header, path, and parameter information stored in the local cache 260 of the API gateway module 200. The validation unit 210 includes an API Validation 211 for verifying the existence of the API itself upon receipt of a user's API service request, a Media Type Negotiation A Header Validation 213 for checking whether the header syntax is appropriate, a Path Parameter Validation 214 for checking whether the access path is appropriate, a Query Parameter Validation , 215) to perform the validation of the API service request. The validation unit 210 may store the test results at each step in the logging unit 240 during validity checking. Since the unnecessary access to the asset or the service can be blocked through the validation, the validation unit 210 can provide the access control function.

FIG. 6 is a diagram illustrating a method of controlling an API call to prevent overload and to control traffic by the throttling unit 230 shown in FIG.

Referring to FIG. 6, the throttling unit 230 may perform throttling on a request for a user's API service in real time through the real-time count management unit 600 of the API integrated management module 20. [ When the real-time count management unit 600 of the API integrated management module 20 counts the real time count of the request of the user's API service and updates the data on the real-time count to the original caches 530 and 730, the API gateway module 200 checks the local cache 260 ) With the original caches 530 and 730, and the throttling unit 230 may throttle a request of the user's API service. The throttling portion 230 may prevent an overload of the asset or service according to the number of API calls and may limit the user's access to the asset or service. The traffic control speed according to the user API service request can be improved through synchronization between the source caches 530 and 730 and the local cache 260 of the API gateway module 200.

7 is a diagram illustrating a method in which the authentication / authorization unit 220 in FIG. 3 handles user authentication and grants API authority.

Referring to FIG. 7, the authentication / authorization unit 220 refers to the authentication key, the IP or the referrer, the open API, and the privilege information stored in the local cache 260 of the API gateway module 200, Verification 222 may be performed.

The user authentication 221 may be performed using an authentication key and an IP address or a referer. A referer is a trace of a hyperlink when surfing the World Wide Web with a web browser. Therefore, it is useful when the server administrator of a web site finds out how a site visitor visited his site. That is, the authentication / authorization unit 220 can process the user authentication based on the API call log of the user.

The authority verification 222 can be performed based on the open API and the authority information therefor. The authentication / authorization unit 220 may store the result of the user authentication 221 and the authorization verification 222 in the local cache 260 of the API gateway module 200.

Figure 8 is a diagram illustrating an additional method used for enhancing security for the asset or service access in Figure 3;

8, the API management apparatus 10 may perform a whitelist method through the third server or the Internet server 30 in addition to the self-authentication 221 and the authority verification 222 through the API gateway module 200. [ Security functions of the system. A white list is a security method that is incompatible with blacklist security, which blocks the proof of 'maliciousness' by allowing only 'proven' to be 'safe.' For example, only users who have already been authenticated and authorized for API asset access can pass through the API gateway module 200. In addition, the API management apparatus 10 can prevent erroneous access to the API gateway module 200 through a referrer check.

9 is a view for explaining that the OAuth authentication unit 400 shown in FIG. 1 provides a standardized authentication method.

Referring to FIG. 9, the OAuth authentication unit 400 may provide a standardized authentication method using an access token. In FIG. 9, a user 40 refers to an individual who has an account using a service provider and a consumer, and a third service 50 refers to a web site or application for accessing a service provider through OAuth. The service 60 refers to a service provider (a service providing Open API) that supports access through OAuth. OAuth authentication occurs between the third service and the service provider. The authentication process is as follows.

When the third service 50 requests an access token from the service provider 60, the service provider 60 issues an access token to the third service 50. [ The third service 50 moves the user 40 to the service provider 60. [ Here, user authentication is performed. The service provider 60 moves the user 40 to the third service 50. [ The third service 50 requests the access token. The service provider 60 issues an access token. The third service 50 accesses the user 40 information using the issued access token.

FIG. 10 is a diagram for explaining that the arbiter 250 shown in FIG. 3 converts and provides an API service request message format and an API asset message format.

Referring to FIG. 10, the arbiter 250 includes an adapter controller 251 for determining whether a format conversion between a user's API service request message and an API asset message is necessary, A message conversion unit 252 for converting a message format, and a protocol handler 253 capable of completing a communication protocol of the API asset with the communication protocol of the API service requested by the user. Here, the transformation rule may include a mapping rule (Mapping Rule). A mapping rule can mean a rule that defines a structure for transforming between messages. For example, the arbiter 250 may convert a request message in JSON when it is sent to an asset or service, and / or convert a message format when returning a response message generated by the asset or service to the client .

The adapter controller 251 determines whether conversion is necessary in the API service request message of the user and transmits an API service request message to the message conversion unit 252 when conversion is necessary. The API service request message can be transmitted immediately.

The message converting unit 252 can convert the message format using the mapping rule stored in the local cache 260 of the API gateway module 200. [ For example, when the user requests the API of the XML format, the message conversion unit 252 may convert the API, not the XML format, to the API of the XML format. Similarly, when the user requests the JSON format API, the message conversion unit 252 can convert the API, which is not the JSON format, to the API of the JSON format. In one embodiment, the message conversion unit 252 may convert the XML-based API to JSON or a binary-based API to reduce the API.

The protocol handler 253 can handle protocols corresponding to SOAP, REST, HTTP, and TCP / IP including SOAP, REST, HTTP, and TCP / IP handlers. The protocol handler 253 can perform protocol conversion at the API gateway layer to support various types of protocols, so that the same API can be serviced by other protocols.

FIG. 11 is a view for explaining that the cache management unit 500 shown in FIG. 2 distributes APIs based on a distributed environment.

11A, the cache management unit 500 includes an internal interface module 510 for connecting the API integrated management module 20 and the administrator portal module 300, a local cache 260 for each of the at least one API gateway module 200, A source cache or a cache storage module 530 that synchronizes the source cache of the API integrated management module 20 to update the local cache 260. [

Each of the plurality of API gateway modules 200 has a local cache 260. The cache manager 500 distributes a request of the user's API service through the local cache 260 of each API gateway module 200 can do. Therefore, the cache management unit 500 can minimize the latency time according to the API processing.

11B is a diagram illustrating that the administrator portal module 300 provides cache monitoring to confirm normal operation of cache data. The manager portal module 300 can provide a function of inquiring the cache module in the developer portal module 100 through the internal interface module 510 in the cache manager 500 of the API integrated management module 20. [ The cache data includes a configuration cache and capacity limitation information including API information, path verification rules, parameter verification rules, authentication policies, access restriction policies, service information, server information, adapter information, SLA restriction information, and a Permission Cache including an unauthorized user identification policy.

FIG. 12 is a diagram for explaining that the analysis measurement management unit 700 shown in FIG. 2 provides statistical information through the log information collected by the API gateway module 200.

Referring to FIG. 12, the analysis measurement management unit 700 may generate various statistical information through the log information stored in the logging unit 240 of the API gateway module 200. The analysis measurement management unit 700 may collect information on the API service request and the API service from each of the at least one API gateway module and perform distributed parallel processing and analysis to provide statistical information. The statistical information may include API usage status, server usage status, response time, error occurrence, cache usage status, API usage status per service, usage status by API, usage status by application, usage status by developer, and the like. Such statistical information can be used not only for checking the normal state of the service but also for developing future API services.

13 is a diagram for explaining a process in which the response data management unit in FIG. 2 returns the response data to the API gateway module.

The API gateway module 200 may provide the user with a JSON or XML based REST API (for convenience of explanation, but not limited to) if there is a user API call request. The response data management unit 800 can receive an API call request for an asset or service that requires a response cache from the API gateway module 200 in the process of providing the API. At this time, the response data management module 810 of the response data management unit 800 can inquire whether or not the response data for the requested asset or service is in the original cache 820. The response data management module 810 can provide the response data to the API gateway module 200 when there is response data in the original cache 820. That is, the API gateway module 200 can return the response data directly by calling the response data management unit 800 without going through the asset / service. Accordingly, the response data management unit 800 can minimize the latency time between the API gateway module 200 and the asset or service.

It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit and scope of the present invention as defined by the following claims It can be understood that

10: API management device 20: API support module
100: Developer Portal Module 200: API Gateway Module
210: validity verification unit 220: authentication /
230: Throttling part 240: Logging part
250: arbitration unit 300: manager portal module
400: OAuth authentication unit 500: cache management unit
510: internal interface module
520: cache management module 530: source cache
600: real-time count management unit
610: cache counter module 620: count management module
630: source cache 700: analysis measurement management module
710: statistical analysis module 710 720: abnormal transaction analysis module 720
730: source cache 730 800: response data management unit
810: Response Cache Management Module 820: Source Cache

Claims

An API (Application Programming Interface) service for receiving requests from users in a distributed manner and each API At least one API gateway module including a local cache for storing service environment information;
A manager portal module that includes API assets generated by an API asset provider and manages and controls information about the API assets; And
And an API integrated management module that includes a source cache for synchronizing the local cache, and continuously updates the suitability of the API service.

2. The method of claim 1, wherein each of the at least one API gateway module
And when the updated content is received from the source cache, the presence or absence of the updated content is detected in the local cache, and the correspondence between the corresponding local cache and the source cache is maintained.

3. The method of claim 2, wherein each of the at least one API gateway module
And notifies the source cache of the necessity of the update if the corresponding local cache needs to be updated according to a request of the API service.

2. The method of claim 1, wherein each of the at least one API gateway module
And temporarily limits the API service by throttling a request of the API service based on a temporal service constraint condition.

5. The method of claim 4, wherein each of the at least one API gateway module
And re-throttling a request of the API service based on a service level protocol condition preset between the API asset provider and the user to re-determine whether to provide the API service.

2. The method of claim 1, wherein each of the at least one API gateway module
And determines the accessibility of the API asset through authentication and authorization of the user.

2. The method of claim 1, wherein each of the at least one API gateway module
And provides an arbitration function through message conversion between the API service request message format of the user and the API asset message format.

The method of claim 1, wherein the API integrated management module
Wherein the API management module distributes a request for the API service through each of the at least one API gateway module to minimize the delay time according to the request processing of the API service.

6. The method of claim 5, wherein the integrated API management module
Wherein the at least one API gateway module causes real-time counting of the API service request based on the service level protocol condition, and causes each of the at least one API gateway module to perform throttling related to a request for the API service in real time.

The method of claim 1, wherein the API integrated management module
Wherein the API management module collects information on the API service request and API service from each of the at least one API gateway module and performs distributed parallel processing and analysis to provide statistical information.