Systems and/or methods for intelligently detecting API key domains

• US 8,793,359 B1
• Filed: 11/25/2013
• Issued: 07/29/2014
• Est. Priority Date: 11/25/2013
• Status: Active Grant

• Current Assignee: Software AG
• Original Assignee: Software AG
• Inventors: Fiebig, Thorsten, Woods, Gary, Adelhardt, Daniel
• Primary Examiner(s): ZHANG, SHIRLEY X
• Application Number:
  US14/088,732
• Time in Patent Office: 246 Days
• Field of Search: 709/223, 719/313, 719/320, 719/331
• US Class Current: 709/223
• CPC Class Codes: G06F 11/3003 Monitoring arrangements specially adapted to the computing system or computing system component being monitored
• CPC Class Codes: G06F 11/3051 Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs verification or detection of system hardware configuration G06F11/2247
• CPC Class Codes: G06F 2201/865 Monitoring of software
• CPC Class Codes: H04L 67/51 Discovery or management thereof, e.g. service location protocol [SLP] or web services
• CPC Class Codes: H04L 69/322 Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions

Abstract

Certain example embodiments described herein relate to an application programming interface (API) management system and/or method that automatically detects API domains, e.g., by analyzing consumer registration and runtime data, while also allowing API providers to provide approval for proposed detected domains and/or continued governance. The technology set forth herein not only provides an automatic detection mechanism, but also provides the capability of full management/control, while also allowing API producers to dynamically expand or otherwise modify their API domain offerings based on usage, etc. This dynamic process can be fully or partially automated and is efficient.

Claims

1. An application programming interface (API) management system, comprising:

a plurality of APIs, each said API having a native endpoint;

a plurality of gateways providing virtual endpoints to respective APIs, the gateways being configured to identify consumers attempting to access the APIs and forward API calls for authorized consumers to the native endpoints;

a registry stored on a non-transitory computer readable storage medium, the registry storing (a) registration information indicating which consumers have registered for which APIs, (b) metadata that includes information concerning operations supported by, and native and virtual endpoint information for, the APIs, and (c) runtime data from the gateways for at least API call type events, the runtime data including, for each API call type event, a timestamp, a consumer identifier, a location, and an identifier of the API being called;

a communications channel defined between the gateways and the registry, the communications channel being configured to transmit runtime data from the gateways to the registry; and

processing resources comprising at least one processor and a memory, the processing resources being configured to;

detect API domains by analyzing the registration information and the runtime data from the gateways, each said detected API domain including at least two of the APIs, and

for a given detected API domain,

receiving an indication as to whether the respective detected API domain is approved of by a provider of the APIs included therein, and

in response to the respective detected API domain being approved of by the provider, registering the respective detected API domain with the registry by storing in the registry metadata including information concerning operations supported by, and native and virtual endpoint information for, the respective detected API domain.

2. The system of claim 1, wherein the processing resources are further configured to respond to a consumer registering for a plurality of APIs by at least:

generating API domain proposals by analyzing the registration information and the runtime data from the gateways, each said API domain proposal including at least two of the APIs, and

for each said API domain proposal,

receiving first input indicating whether the respective domain proposal is approved of by a provider of the APIs included therein,

in response to the respective domain proposal being approved of by the provider, receiving second input indicating whether the respective domain proposal is accepted by the consumer registering for the APIs, and

in response to the respective domain proposal being approved of by the provider and accepted by the consumer registering for the APIs, registering the respective domain proposal with the registry as an API domain by storing in the registry registration information indicating that the consumer has registered for the respective API domain, and by storing metadata including information concerning operations supported by, and native and virtual endpoint information for, the respective API domain.

3. The system of claim 2, wherein the processing resources are further configured to at least analyze the registration information in order to identify whether there is an existing API domain including the plurality of APIs being registered for by the consumer and, if so:

receive third input indicating whether the existing API domain is accepted by the consumer; and

in response to the existing API domain being accepted by the consumer, register the consumer as a consumer of the existing API domain.

4. The system of claim 3, wherein in the event that there are no existing API domains including the plurality of APIs being registered for by the consumer, the processing resources are further configured to at least generate API domain proposals based at least in part on whether other consumers have registered for a set of APIs including at least the APIs being registered for by the consumer.

5. The system of claim 4, wherein the processing resources are further configured to at least analyze the runtime data from the gateways by applying at least one set of one or more rules thereto in order to identify APIs that likely are consumed together and thus should be included in an API domain proposal.

6. The system of claim 5, wherein the at least one set of rules groups together APIs that are invoked by the same consumer and from the same location, and that are invoked within a predetermined timeframe.

7. The system of claim 1, wherein:

the processing resources are further configured to at least analyze the runtime data from the gateways by applying at least one set of one or more rules thereto in order to identify APIs that likely are consumed together and thus should be included in an API domain proposal presented for approval by the provider of the APIs therein, and

at least one of said set of rules groups together APIs that are invoked by the same consumer and from the same location.

8. The system of claim 7, wherein the processing resources are further configured to filter API domain proposals based on the registration data so that a given API domain proposal is presented as a detected API domain only if there are a predetermined number of consumers who have each registered for the all of the APIs in that given API domain proposal.

9. The system of claim 1, wherein the gateways are configured to identify consumers making API calls by introspecting the API keys provided with the respective API calls.

10. The system of claim 1, wherein the processing resources are further configured to at least generate a proposal for extending an already-existing API domain if a detected domain includes a superset of the APIs included in that already-existing API domain.

11. The system of claim 1, wherein the communications channel is an event channel, and wherein the gateways are configured to send to the event channel events with API invocation information and runtime information related to API invocations.

12. The system of claim 11, wherein the processing resources are further configured to at least subject the events on the event channel to complex event processing (CEP) queries.

13. The system of claim 11, further comprising complex event processing (CEP) queries run on the event channel, the CEP queries including continuous queries that, through windowing, identify time-based relations between different API call type events.

14. The system of claim 13, wherein the CEP queries at least:

identify related API call type events;

create domain detection events in response to the identification of related API call type events;

filter created domain detection events based on the runtime data and the registration data; and

generate events corresponding to domain proposals and/or domain extension proposals in response to the filtering.

15. The system of claim 1, wherein the gateways are further configured to provide service-level agreement (SLA) enforcement.

16. The system of claim 1, wherein the registry is configured to enforce a predefined domain lifecycle in connection with API domains, the predefined domain lifecycle being defined in accordance with one or more associated policies.

17. The system of claim 16, wherein the policies indicate when proposed API domains should be automatically approved by a provider and/or accepted by a consumer.

18. A method of managing application programming interfaces (APIs), the method comprising:

providing a plurality of gateways providing virtual endpoints to APIs that have respective native endpoints, the gateways being configured to identify consumers attempting to access the APIs and forward API calls for authorized consumers to the native endpoints;

storing, in a registry provided on a non-transitory computer readable storage medium, (a) registration information indicating which consumers have registered for which APIs, (b) metadata that includes information concerning operations supported by, and native and virtual endpoint information for, the APIs, and (c) runtime data from the gateways for at least API call type events, the runtime data including, for each API call type event, a timestamp, a consumer identifier, a location, and an identifier of the API being called;

detecting, via at least one processor, API domains by analyzing the registration information and the runtime data from the gateways, each said detected API domain including at least two of the APIs; and

for at least some of the detected API domains and using the at least one processor;

receiving an indication as to whether the respective detected API domain is approved of by a provider of the APIs included therein, and

in response to the respective detected API domain being approved of by the provider, registering the respective detected API domain with the registry by storing in the registry metadata including information concerning operations supported by, and native and virtual endpoint information for, the respective detected API domain.

19. The method of claim 18, further comprising applying to the runtime data from the gateways at least one set of one or more rules in order to identify APIs that likely are consumed together and thus should be included in an API domain proposal presented to the provider of the APIs therein for approval.

20. The method of claim 19, further comprising filtering API domain proposals based on the registration data so that a given API domain proposal is presented as a detected API domain only if there are a predetermined number of consumers who have each registered for the all of the APIs in that given API domain proposal.

21. The method of claim 19, wherein at least one of said set of rules groups together APIs that are invoked by the same consumer and from the same location, and within a predetermined timeframe.

22. The method of claim 18, further comprising generating a proposal to extend an already-existing API domain if a detected domain includes a superset of the APIs included in that already-existing API domain.

23. The method of claim 18, further comprising running complex event processing (CEP) queries on events provided from the gateways to an event bus, the CEP queries including continuous queries that, through windowing, identify time-based relations between different API call type events.

24. The method of claim 23, wherein the CEP queries at least:

identify related API call type events;

create domain detection events in response to the identification of related API call type events;

filter created domain detection events based on the runtime data and the registration data; and

generate events corresponding to domain proposals and/or domain extension proposals in response to the filtering.

25. The method of claim 18, further comprising enforcing service-level agreements (SLAs) via the gateways.

26. The method of claim 18, further comprising enforcing a predefined policy-based domain lifecycle in connection with API domains via the registry.

27. A non-transitory computer readable storage medium tangibly storing instructions that, when executed by at least one processor of a computer system, are configured to at least perform the method of claim 18.

28. A method of managing application programming interfaces (APIs), the method comprising:

providing a plurality of gateways providing virtual endpoints to APIs that have respective native endpoints, the gateways being configured to identify consumers attempting to access the APIs and forward API calls for authorized consumers to the native endpoints;

storing, in a registry provided on a non-transitory computer readable storage medium, (a) registration information indicating which consumers have registered for which APIs, (b) metadata that includes information concerning operations supported by, and native and virtual endpoint information for, the APIs, and (c) runtime data from the gateways for at least API call type events, the runtime data including, for each API call type event, a timestamp, a consumer identifier, a location, and an identifier of the API being called; and

responding to a consumer registering for a plurality of APIs by using at least one processor for at least;

generating, via at least one processor, API domain proposals by analyzing the registration information and the runtime data from the gateways, each said API domain proposal including at least two of the APIs, and

for at least some of said API domain proposals,

receiving first input indicating whether the respective domain proposal is approved of by a provider of the APIs included therein,

in response to the respective domain proposal being approved of by the provider, receiving second input indicating whether the respective domain proposal is accepted by the consumer registering for the APIs, and

in response to the respective domain proposal being approved of by the provider and accepted by the consumer registering for the APIs, registering the respective domain proposal with the registry as an API domain by storing in the registry registration information indicating that the consumer has registered for the respective API domain, and by storing metadata including information concerning operations supported by, and native and virtual endpoint information for, the respective API domain.

29. The method of claim 28, further comprising:

determining whether there is an existing API domain including the plurality of APIs being registered for by the consumer;

in response to a determination that there is an existing API domain including the plurality of APIs being registered for by the consumer;

receive third input indicating whether the existing API domain is accepted by the consumer, and

in response to the existing API domain being accepted by the consumer, register the consumer as a consumer of the existing API domain; and

in response to a determination that there are no existing API domains including the plurality of APIs being registered for by the consumer;

generating API domain proposals based at least in part on whether other consumers have registered for a set of APIs including at least the APIs being registered for by the consumer, and

applying at least one set of one or more rules to the runtime data in order to identify APIs that likely are consumed together and thus should be included in an API domain proposal.

30. A non-transitory computer readable storage medium tangibly storing instructions that, when executed by at least one processor of a computer system, are configured to at least perform the method of claim 28.