Use of collected data for web API ecosystem analytics

An embodiment of the invention pertains to Web application programming interface (API) data associated with a Web API ecosystem. The embodiment comprises constructing a data structure that is selectively related to at least some of the Web API data associated with the Web API ecosystem. The embodiment further comprises commencing an analytics operation to determine specified information which is of interest to a given Web API user, wherein the given Web API user has a role that pertains to the Web API ecosystem. Responsive to commencing the operation, Web API data related to the data structure is used to determine one or more preliminary data elements, wherein at least one of the preliminary data elements comprises an answer to a specified preliminary query. Respective preliminary data elements are selectively used to determine the specified information that is of interest to the given Web API user.

BACKGROUND

1. Field of the Invention

The invention disclosed and claimed herein generally pertains to collected or acquired data, related to at least one Web application programming interface (API) in a Web API ecosystem. The invention further pertains to use of the acquired data to gain important knowledge and insights, for the benefit of API users. At least some of the acquired data is contained in or otherwise related to an API data graph or other data structure. Embodiments of the invention disclosed herein expressly pertain to APIs that are known as Web APIs, as such term is defined hereinafter.

2. Description of the Related Art

Businesses are increasingly exposing their functionalities through APIs. For example, in excess of 10,000 APIs are currently available through a website known as Programmable Web. Moreover, the type of API known as Web API is emerging as a dominant technology for accessing and integrating applications. As a result, there is a movement away from the Service Oriented Architecture (SOA) form of application integration, which generally needs high upfront technology investments. API ecosystems are emerging to address API promotion and identification, trust, Terms of Service (ToS), Quality of Service (QoS), composability and the like.

The increased interest in APIs, and specifically Web APIs as described above, has encountered a number of challenges. Existing approaches for capturing Web API domain knowledge, as well as consumption models, are only semi-automated and static. These approaches generally crawl existing data at particular points in time, and thus do not acquire pertinent data on a continuing basis. Also, such approaches tend to have predefined schemas to support query related activities. Moreover, the focus of prior art approaches has generally been only on matchmaking and recommending Web APIs for consumers, but not on analyses that also consider Web API providers and Web API ecosystem providers.

SUMMARY

Embodiments of the invention analyze incoming data about Web API events and other related data sources. This data then is used to generate a data structure such as a high level Web API graph, which is capable of answering Web API usage queries. Examples of such queries are provided hereinafter. Also, analytics operations are run periodically to discover clusters, and to create recommendations based on Web API events and the Web API graph. These analytics operations may also use the answers or other results that are provided to the usage queries. Compared to currently used graph clustering and recommendation methods, embodiments of the invention specifically create a Web API graph that supports usage and other queries, and can provide clusters and recommendations useful to API users.

An embodiment of the invention directed to a computer implemented method pertains to Web application programming interface (API) data associated with a Web API ecosystem. The method comprises the step of constructing a data structure that is selectively related to at least some of the Web API data associated with the Web API ecosystem. The method further comprises commencing an analytics operation to determine specified information which is of interest to a given Web API user, wherein the given Web API user has a role that pertains to the Web API ecosystem. Responsive to commencing the operation, Web API data related to the data structure is used to determine one or more preliminary data elements, wherein at least one of the preliminary data elements comprises an answer to a specified preliminary query. Respective preliminary data elements are selectively used in the operation to determine the specified information that is of interest to the given Web API user. At least some of the specified information determined by the analytic operation may be delivered or routed to the data structure, to be stored in relation thereto.

The term “Web API”, as defined and used herein, and as known and used by those of skill in the art, means and refers to a server-side API on a Web server. A server-side Web API is a programmatic interface to a defined request-response message system, which is exposed via the web such as by means of an HTTP-based web server. Mashups are Web applications that combine the use of multiple Web APIs of the above type. The term “Web API” may also refer to a client-side API within a web browser.

In view of the above definitions, all uses herein of the terms “API” and “application programming interface” are to be interpreted as referring to, or to mean, “Web API” and “Web application programming interface”, respectively. Herein, solely for convenience, “API” may be used rather than the complete term “Web API”.

DETAILED DESCRIPTION

Referring toFIG. 1, there are shown components and architecture of a system100, pertaining to an embodiment of the invention. The system100includes a Web API graph102. API graph102also has an interface104, which is described hereinafter in further detail. Moreover,FIG. 1shows an exemplary Web API ecosystem106with which system100is associated.FIG. 1further depicts entities representing the three Web API ecosystem roles described above, that is API consumer108, API provider110, and API ecosystem provider112.

FIG. 1additionally depicts exemplary activities that each role may carry out with respect to the API ecosystem106. Thus, API consumer108can discover, combine, and rate respective APIs. API consumer108can also use widgets to provide tags for APIs, in order to display API graph data. Tags can be keywords, such as “social” or “location-based”, or quantitative expressions. When a user creates a tag, a corresponding characteristic node may be created and a feature relationship between the API and the characteristic node is also created.

FIG. 1shows that API provider110interacts with API ecosystem106by publishing, describing, promoting, and assessing APIs which it provides, particularly with respect to its competition. API ecosystem provider112interacts with API ecosystem106by analyzing the ecosystem.

Referring further toFIG. 1, there is shown data130, of a type to be collected from API ecosystem106, being transferred to the interface104of API graph102. This data includes node related data for a graph core structure, described hereinafter. The data more specifically includes data pertaining to users, APIs, and applications, and further data comprising relationships. Such data also includes invocations, requirements, features, and provisions. Moreover, some or all of this data needs to be logged or entered into a log file, register, or record, together with appropriate timestamps. Data of the above type is described hereinafter in further detail, in connection withFIG. 2.

In the system of the embodiment ofFIG. 1, a log file or record for the above transferred data is usefully provided in a Resource Description Framework (RDF) triple store126, which is used to persist the data. Representing data in RDF form, as described hereinafter in further detail, is very convenient since RDF data can be reused in a number of other contexts.

In order to translate data of the above type from API graph102to RDF triple store126, at least in part, API graph102is implemented as a service, denoting Representational State Transfer (REST) interfaces. Interface104is referred to as an API logging REST interface. Interfaces114and116are two additional REST interfaces, which are both included in or comprise the REST interface104. Interface114is a core structure CRUD (create, read, update, and delete) interface, and interface116is a generic CRUD interface.

Core structure CRUD interface114exposes entities of the API graph core structure, which include both nodes and relationships. For each node (e.g., user or API), CRUD operations are provided at a designated endpoint (e.g., user or API). Additionally, these endpoints provide CRUD operations for relationships defined in the API graph core structure that originate from these nodes. For example, creation or retrieval of an invocation relationship between user “A” and API “B” can be achieved by performing POST respectively GET to./user/A/invocation/B. On the other hand, the generic CRUD interface116provides CRUD operations for any type of nodes and relationships. This interface allows the API graph102to be extended beyond its core structure, by enabling relationships and nodes of any, novel kind to be defined.

The two types of CRUD interfaces114and116also allow API graph102to be integrated with API ecosystem106. In reaction to events in the ecosystem, corresponding actions can be triggered in the API graph using them. For example, if a new user or API is registered, a user or API node in the API graph can be posted. Or, if a user invokes an API, an invocation relationship between the two can be posted. Thus, a continuous data collection occurs, where events in the ecosystem are reflected in the API graph, and data can readily flow between graph102and RDF store126.

The REST interfaces consume and produce data in Java Script Object Notation (JSON) format, which is useful for transmitting data objects comprising key-value or attribute-value pairs. This is described hereinafter. A resource representing a node contains its type, (e.g., “user”), id (e.g., “user_93”), href in the API graph (e.g., “./user/user_93”), lists of properties (e.g., “name=Erik Wittern”), incoming relationships (e.g., “user_7/contact/user_93”) and outgoing relationships (e.g., “user_93/invocation/api_20”). Similarly, a resource representing a relationship contains its type (e.g., “invocation”), id (e.g., “user_93/invocation/api_20”), href in the API graph (e.g., “./user/user_93/invocation/api_20”), source and source href, target and target href, and a list of properties.

The system ofFIG. 1further includes a JSON/RDF translator118, which is responsible for translating between JSON representation of data and RDF triple store126, used to persist the data. To carry this out, received JSON data is decoded by the translator to an intermediary property graph domain model120. In the implementation, domain model120uses plain old Java objects (POJOs). The POJOs are then translated to RDF triples, which are persisted in RDF triple store126. In reverse, when requesting data from the API graph, required triples are retrieved from the RDF triple store using SPARQL queries. JSON/RDF translator118populates corresponding POJOs out of the triples, which are encoded in JSON and provided at the REST interfaces.

In order to carry out the above translation, data in the API graph must be represented in RDF form. Utilizing RDF enables the API graph's dataset to be integrated with others, following the idea of open linked data. For example, RDF datasets capturing social relations between users or technical properties of APIs can readily be integrated with the API graph. Similarly, the RDF data representing data from the API graph can thereby be reused in other contexts as well. In RDF, information is stored in triples consisting of a resource, a predicate, and an object. Objects can either be other resources, allowing triples to depict relationships between them, or literals, allowing triples to depict properties of resources. The relationships defined in the API graph's core structure have properties. In RDF, however, predicates cannot in a standard way act as resources of triples, and thus cannot have their own properties. To overcome this problem, embodiments of the invention map the property graph representation of the core structure of API graph102to RDF.

More particularly, to represent a given node from the API graph in RDF, a resource representing the given API graph node is defined, wherein each property of both node and edges in the API graph is specified as a key-value pair. Thus, for each property of the given node, a triple originating from that resource is defined whose predicate represents the key of the property and whose literal represents the value of the property. For each relationship of the property graph representation, another resource is defined. Again, to represent properties of the relationship, triples whose objects are literals and that originate from this resource are defined. Thus, at least two triples are required to represent a relationship between two nodes in the property graph, one originating from the source and targeting the relationship, and one originating from the relationship, and targeting the target node. The naming conventions has <relationship name>, and <relationship of> are used for the predicates of these two triples. While this mapping results in an increased number of triples, it allows relationships, represented as resources, to be the origin of as many further descriptive triples as needed.

An example of a key-value pair for an embodiment of the invention, or attribute—value pair, could be the following:

The key or attribute of this key-value pair would be the “type” of user_1000 in an API graph. The value would be “node”.

Another example of a key-value pair would be the following:

The key for this key-value pair would be the creation date and time of availability for API—62of the API graph. The value would be “2013-08-16T13:55:35.133-04:00”.

The API graph as described above can be used to obtain critical insights about API ecosystems, and also about consumption patterns of respective APIs and related applications. This is achieved by carrying out analysis or analytic operations on the API graph, such as by executing selected information queries over the graph entities and relationships. To access analysis operations using the API graph, a dedicated analysis operations interface124is provided, which is referred to as an analysis REST interface. This interface124furnishes dedicated endpoints for each analysis operation, allowing for example, retrieval of a list of APIs that fulfill some of the user's requirements for characteristics by issuing a GET to../analysis/requirements matching/user ID. Analysis operations122are performed by an analysis operations controller128, which issues required SPARQL queries to RDF triple store126. Resulting data is translated to JSON by translator component118and provided via REST interface124.

Thus, analysis operations may make use of data pertaining to the Web API ecosystem that was delivered previously to the RDF triple store from the Web API graph.FIG. 1further shows that results of analysis or analytic operations, such as requested insights or the results of queries, may be provided to API ecosystem106. Results of analytic operations may also be routed to API graph102by translator component118, as some of the data which is routinely collected by the API graph.

Referring toFIG. 2, there is shown a unique data structure200for an embodiment of the invention. More particularly,FIG. 2shows an exemplary Web API graph core structure200for a Web API graph102or the like, wherein core graph200comprises a graph-based data model. The Web API core graph200captures or collects data which pertains to respective entities included in a Web API ecosystem106, and also pertains to relationships between such entities. Moreover, the API core graph200ofFIG. 2collects data continually, and thus provides a means for continuously collecting all pertinent data needed for an associated Web API ecosystem. This includes data regarding both API features and relationships. Moreover, the API core graph structure is extensible. That is, if elements such as new users, APIs or relationships are added to the API ecosystem, the graph structure200can be extended to represent these new elements.

In addition, it is anticipated that an API ecosystem will change or evolve over time. Accordingly, an embodiment of the invention can include the capability of applying temporal or timing information to event data which is captured by the API graph of the data model, wherein the event data indicates changes of various types. A record of these changes thus captures the evolution of the API ecosystem over time. This information timing capability is described hereinafter, in further detail.

Referring further toFIG. 2, graph core structure200of the API graph is defined as a property graph, in which both nodes and edges have properties specified as key-value or key-attribute pairs. This graph structure further attempts a balancing act. That is, it intends to perform a set of meaningful analysis operations described hereinafter, while not requiring a verbose and potentially off-putting structure. To achieve this balance, the embodiment ofFIG. 2initially captures fundamental concepts of an API ecosystem, and explicitly allows the data model to evolve over time.FIG. 2illustrates the nodes and relationships denoting the API graph core structure200. These elements are also used as the API graph extends, i.e., has additional nodes and relationships added to it.

User node202of graph structure200represents humans or organizations that interact with a particular API ecosystem. User node202has provision relationships204or invocation relationships220to nodes206that represent APIs, or to application nodes208. Depending on the existence of these relationships, users act either as API providers, API consumers, or both. Between user nodes202, contact relationships210capture social structures, such as that users are friends, or follow the choices of each other. Application nodes208, representing for example mash-ups (applications) in Programmable Web, also invoke API nodes206. Both API and application nodes can have connection relationships212to denote, for example, dependencies to other APIs or applications.

API and application nodes may also have feature relationships214to characteristic nodes216. Characteristic nodes216represent functionalities or non-functionalities that are potentially shared among APIs or applications. For example, characteristic nodes216represent categories like “social” or “location-based”, data formats like “JSON” OR “XML”, or qualities like “cost per request” or “availability”. The concrete value that an API206or application208has with regard to a characteristic node216is denoted in the properties of a feature relationship214. For example, an API's feature relationship214to the characteristic “cost per request” with “measurement: $” can denote the properties “value: 0.05” and “comparator: equals”. User nodes202can have requirement relationships218to characteristic nodes216that (similar to feature relationships214) capture quantitative information about the requirement.

To summarize the data storing capabilities of some of the node and edge elements of the API graph described above, when a user signs up to the associated Web API ecosystem, a corresponding node is posted to the API graph core structure200. When an API is registered to the API ecosystem, a corresponding node is likewise posted to the API graph core structure. A provision relationship between the API node and the node representing the user is also created. Each endpoint of the API is also represented with a corresponding API node. A connection relationship of type “parent API” between the nodes representing the endpoint and the API is created. Thus, it is seen that respective nodes and edges of the API graph, as illustrated by core structure200, provide a comprehensive repository for storing data that represents respective entities, conditions, states and changes of the associated API ecosystem.

The core structure200, while comprising a simplified example, still provides a rich set of relationships. This becomes clear when mapping web data, exemplified by Programmable Web data, as the web data is reported to the graph structure. Based on the data, nodes206for Web APIs, nodes208for mash-ups (applications), and the user nodes202who created them, can respectively be created. Invocation relationships220between mash-ups and Web APIs, and provision relationships204between users and Web APIs and/or mash-ups can also be derived. Further, categories contained in the Programmable Web data can be represented as characteristic nodes216with feature relationships214, from the corresponding Web APIs and/or mash-ups to the characteristics. Thus, by way of example, the complete Programmable Web data is mappable to the API graph, whose core dataset constitutes a superset. Additionally, the API graph allows capturing quantitative information about characteristics (using properties in feature relationships214and requirements relationships218) and keeps track of the invocations220a user performs for each Web API and application.

Capturing the required data from a Web API ecosystem is enabled through the system associated with the API graph, which denotes required interfaces to transfer data, such as the interfaces described previously in connection withFIG. 1.

Web API ecosystems are subject to constant change, and correspondingly evolve over time. For example, users, Web APIs, and applications enter and leave the ecosystem, their usage is volatile, and their characteristics change. The Web API graph structure200is capable of keeping track of these changes, and can be used in analysis operations that provide the potential to better deal with the changes. For example, Web API providers can detect and react to changing demand or competition, Web API consumers can obtain information about novel Web APIs to consume, and Web API ecosystem providers can gain insights into how the ecosystem evolves over time.

To collect temporal information, all relationships in the Web API graph200denote a state property, and capture time stamps of events pertaining to activation and inactivation properties, as illustrated inFIG. 2. More particularly,FIG. 2explicitly shows that each of the relationships204,210-214and218-220has a state property, an activation property and a deactivation property. On creation, a relationship obtains a first activation property, representing the creation date. Subsequent re-establishments of that relationship produce additional activation properties, thus capturing currentness and relevance of the relationship. For example, an invocation relationship220keeps track of the evolution of when and to what extent a user node202consumes a Web API node206. With the creation and each re-establishment, the state property of the relationship will be set to active. On the other hand, deletion of a relationship will not result in its data being dismissed. Rather, a deactivation property will capture the time of the deletion, and the state property of the relationship will be set to inactive. Thus, knowledge about the prior existence of a relationship is not lost due to data dismissal. Also, a history, such as frequent changes of the state of a relationship, can reveal patterns of interest. Using this mechanism, relationships may also be marked inactive automatically if they are not established for a certain period of time. One potential concern is the accumulation of data, which could eventually impact performance negatively. To avoid this, ancient data can be summarized, stating for example the amount of re-establishments in a certain time period within one property. Here, a trade-off between the amount of data and its granularity must be chosen by the user.

It will be seen that by capturing the above temporal information, a database of such information is made available, for tracking usage of related Web API ecosystem components. For example, the information could be used to determine whether a given Web API is being consumed more frequently or less frequently, by respective users. More generally, the temporal information could enable users to gain significant insights into evaluation of the ecosystem. Such insights, by way of example, could be directed to how the consumption of a Web API evolved, when a Web API did and did not denote corrections, and how requirements change over time.

As a further example of temporal information,FIG. 2shows user node202having an invocation relationship220that could be as follows, by way of example:

This example shows that invocations became frequent in August, 2013. Explicit deactivation of relationship220then occurred, possibly because Web API node206was substituted with another Web API.

The above example further emphasizes the capability of core structure200of the Web API graph to continuously collect data pertaining to interaction events and change events that occur in a Web API ecosystem associated with the Web API graph. For instance, the API of node206first became active in the ecosystem on 2013 Jan. 4 and was deactivated from the ecosystem on 2013 Aug. 18. The example also shows that the state of respective elements of the Web API graph at a given time will indicate the state of the comparable elements of the Web API ecosystem at the given time.

As described hereinafter in further detail, a Web API graph having a core structure200as described above, together with other components of system100as described above in connection withFIG. 1, can be used to resolve issues and problems encountered by those who have respective roles in a Web API ecosystem such as ecosystem106. For example, those who have the role of providing a given Web API would want to understand how API users are invoking the given API. This may include learning what other APIs are used in conjunction with the given API of the provider, and what types of users and usage patterns are associated with the given API.

An exemplary issue for a Web API consumer could be a desire to understand how a given Web API available in the ecosystem was being used. More particularly, the consumer may want to know what other APIs are typically used together with the given API, what APIs similar users are using, and what the friends of the consumer are doing with respect to the given API.

An exemplary issue for a Web API ecosystem provider could be a need to know which APIs are popular among Web API consumers. This might require determining which APIs were trending, which APIs go together with one another, and how API usage changes over time.

Referring toFIG. 3, there is shown a flowchart depicting steps of a method that can be carried out using components of system100or the like, and also using API core graph structure200, in accordance with an embodiment of the invention. The embodiment is intended to address issues and problems such as those described above, which are encountered by those who have roles in a Web API ecosystem. However, the invention is by no means limited to such embodiment.

At step302ofFIG. 3, data is continuously collected that pertains to Web API related events, which may occur in Web API ecosystem103or the like. The collected data could include, by way of example and not limitation, the data130disclosed in connection withFIG. 1. This data includes information regarding users, Web APIs, applications and associated relationships, and further includes events such as Web API invocations, requirements, features and provisions, and registration of Web API users. Relationships could be between a Web API and a Web API user, between different Web API users, and between different Web APIs, without limitation thereto. The collected data could usefully be kept in a log file or database that was located in RDF triple store126ofFIG. 1.

Step304collects other data from pertinent data sources, which is related to the collected Web API event data. Such other data can include, for example, social relationships and associations of Web API users. The other data can also include further contact information210for an API user, and connection information212for Web APIs and applications, such as shown byFIG. 2.

At step306, the data collected at both steps302and304is combined together to construct or enhance a Web API graph structure, such as core graph structure200. Thus, the collected data can be used to extend the Web API graph from its core structure.

Step308processes the collected API event data to add new edges and nodes to the Web API graph, wherein the new edges and nodes are provided to support, or assist in providing answers for, specified API usage queries. For example, a specified usage query could seek to determine “how many times a Web API X was used by a user Y.” As described hereinafter in further detail, the answer to a usage query of this type could be very important, in order to carry out an analysis to determine the answer to a broader query of interest. Broader queries could, by way of example, include issues and problems such as those described above, which are encountered by users who have respective roles in the Web API ecosystem.

Step310, at specified intervals which may be periodic, such as every N hours, or may be aperiodic, carries out an operation to update the Web API graph, wherein the updating analytics may pertain to the whole graph. Each update at this step comprises a map-reduce job that can discover or identify clusters which are contained in the Web API graph content. Clusters of nodes found in the graph, for example, can help a user to quickly identify relationships of graph components that otherwise would be hard to see. The updates can also create recommendations for a user. Moreover it is to be appreciated that step308and step310each demonstrates an important self-enrichment capability of the Web API graph.

At step312, the previously collected data content of the Web API graph, as updated at step310, is used to execute or pursue a query of interest, and to acquire a response to the query of interest. The previously collected data content can include the answers or other results of specified usage queries of step308, and can also include clusters and recommendations of step310. Examples of queries of interest are described hereinafter.

Step314enables the user to subscribe, in order to gain access to some or all of the data content of the Web API graph. The user can then use the data to run continuous queries of interest to the user, and can be notified when graph data content provides new results. Examples of useful new results can include enhanced visualization, such as having API nodes that are more relevant to the user being displayed larger, or color coding API nodes that have similar characteristics with one another, or that are used by similar types of users.

To summarize the method ofFIG. 3, a Web API graph is initially provided, which includes a core graph structure200or the like, as shown inFIG. 2. Incoming data pertaining to API events, and also to data sources related to the API events, is collected and analyzed. These efforts are then used to generate a higher level API graph, which is capable of providing answers to preliminary or usage queries that pertain to API usage or characteristics. Such queries are exemplified by the specified usage queries of step308ofFIG. 3. Moreover, analytic operations may be run periodically to discover component clusters in the graph, and to create recommendations, using the data previously collected for the API graph.

Another perspective ofFIG. 3is that it discloses a method and system wherein a Web API graph structure can interrelate pertinent Web API information that includes, without limitation, APIs, API users, applications, API invocations, social relationships between users, and required and featured characteristics. Moreover, API graph data of the above type can be mined, such as by an analytics operation, to enable API users to discover new insights that can be of great benefit and importance to them. These API users can include those having roles as Web API consumers, providers, and ecosystem providers.

As used herein, the term “insight” includes, without limitation, an answer which is discovered or determined for a query of interest or importance, wherein an answer to the query of interest is sought by a Web API user having a role such as one of the above roles. Examples of insights as defined above are described hereinafter in further detail, in connection withFIG. 4. In a useful embodiment of the invention, insights can be discovered by carrying out an analytics operation applied to data contained in or otherwise a related to a Web API graph, as described herein. Learned or discovered insights and other data resulting from such analytics can then be incorporated into the graph to extend it, or can be stored in association with the graph, such as in RDF store126or the like. This further illustrates the self-enrichment of the Web API graph.

Respective components of system100shown inFIG. 1can be used to carry out these analytics operations. Also, an analytics operation can be carried out on top of Web API graph structure that includes results of previous analytic efforts. These analytics operations can be used to answer queries of interest, in order to provide Web API users with corresponding insights, in accordance with step312. Such efforts also can include determining answers to specified Web API usage queries or other preliminary queries, as described above at step308ofFIG. 3.

Referring toFIG. 4, there is shown a table pertaining to exemplary use cases402-412. Each use case is associated with one of the types of API graph users described above, and is concerned with a particular query of interest to that user. By using the API graph to execute respective queries, valuable insights, as defined above, may be realized in regard to Web API ecosystems, and to consumption patterns of Web APIs and applications.

More particularly, the Web API graph can produce insights that are of interest to API providers, consumers, and the ecosystem, in order to drive the API and application (App) consumption. Through search queries or discussions in forums on the API ecosystem, consumers expose their requirements. Such information can be used to identify whether existing APIs and/or applications are in place to enable characteristics that meet the consumer requirements. Similarly, API providers and ecosystem providers can use this information to understand if there are APIs and/or applications with low usage that can be enhanced to incorporate sought after requirements. Insights about what different APIs and applications are enabling help providers obtain insights into the competition and how they can differentiate their offering.

The table ofFIG. 4shows how the API graph can enable these insights. For each sample use case, the table shows the path of a query of interest on an API graph, in order to determine a corresponding insight, and provides a resulting set of nodes representing the insight. For example, if consumers want to know which APIs their business and social contacts are using, the graph structure would be used to traverse the user's contact relationships to other users. From them their relationships to certain APIs could be identified or determined. This insight is then represented by the identified set of APIs. More complex insights, such as the ability to understand which characteristics users seek, could be provided by low usage of particular APIs and/or applications, and may require a number of queries about selected users, characteristics and API consumption levels. Insights such as these are key to understanding how to improve, and what characteristics can drive higher consumption of, APIs and/or applications. These insights also exemplify the term “insight” as used herein.

Use case402of the table pertains to API Consumeri, and to the query of interest “Which APIs are my contacts using?” To gain insight by answering this query, Consumerican use contact information, for the Consumeriuser node of the API graph, to identify each contact user Uiof Consumeri. These contact users collectively are contacts Ui . . . n. Consumerithen uses data from the API graph to determine that contact users Ui . . . ncollectively invoke API1 . . . m, which is the desired result.

Use case404pertains to API Consumeriand to the query of interest “Which APIs meet my requirements?” For this query, Consumeriuses API graph data to determine that its contact users Uicollectively have the requirements C1 . . . nAnalysis of API graph data then shows that requirements C1 . . . ncan be met by providing respective features of API1 . . . m.

Use case406pertains to API Providerjand to the query of interest “Which characteristics are required that I currently do not offer?” API graph data is used to determine that contact users Ujof Providerjalready have APIs and/or applications API/App1 . . . n, which offer features or characteristics C1 . . . m. Other users U1 . . . krequire characteristics C1 . . . l. The query of use case406can then be resolved by comparing characteristics C1 . . . land C1 . . . m.

Use case408pertains to API Provider) and to the query of interest “Who provides APIs and/or applications with similar characteristics?” To answer this query, API graph data is used to determine that Providerjalready provides its contact users Ujwith APIs and applications that have the features C1 . . . m. The API graph data is used further to determine that the features C1 . . . mare also provided by APIs and applications API/App1 . . . k. These are made available by users U1 . . . l, which is the result of the query of interest.

Use case410pertains to a Web API Ecosystem Provider, and to the query of interest “Which characteristics are common to successful APIs and/or applications?” This query uses API graph data to determine that each of the APIs and applications API/App1 . . . nhas a number of user invocation events that exceeds a pre-specified minimum x. The API graph further indicates that each of the API/App1 . . . nhas all of the characteristics C1 . . . m, which is the result of the query.

Use case412pertains to a Web API Ecosystem Provider, and to the query of interest “Which often required characteristics are not provided by unsuccessful APIs?” This query first uses API graph data to identify a set of required characteristics C1 . . . n. This is accomplished by analyzing data to determine characteristics that are each required by more than a pre-specified number x of users. The query then identifies a set API/App1 . . . mthat each has less than a pre-specified number y of invocation events. The set API/App1 . . . mprovides characteristics C1 . . . k. The characteristic sets C1 . . . nand C1 . . . kare then compared with each other, to furnish a result for the query of use case412.

Providing an answer to a query of interest, such as those described above, typically requires answers to or resolutions of one or more preliminary queries or questions. These could be queries pertaining to usage or specified characteristics of a particular Web API. For example, to determine an answer to the query of interest of use case402, it is first necessary to answer each of the preliminary usage queries. More particularly, each usage query must find out which APIs the contact user Uiis using. The answers to all the preliminary usage queries may then be used in an analytic operation that answers the query of interest.

Implicit or indirect insights are an auxiliary outcome of the API graph. These are analytic operations designed to derive insights from the API graph that can be used to enrich the API graph. For example, API nodes can share a set of characteristics. This information can first be obtained from querying the API graph and then be put back into it, for example, by creating a connection relationship between the API nodes.

Referring toFIG. 5A, there are shown a number of examples of questions or queries of interest, wherein the answers to respective queries could provide insights or other information of great interest to API users that are Web API consumers. Column502ofFIG. 5Aspecifies the analysis subject for each query of interest. Column504states explicitly each query of interest, or question, that is to be answered. Column506indicates the edges of the Web API graph that must be considered in answering each query of interest, and Column508indicates the required input for each query.

Referring toFIG. 5B, there are shown a number of examples of questions or queries of interest, wherein the answers to respective queries could provide insights or other information of great interest to API users that are Web API providers. Column510ofFIG. 5Bspecifies the analysis subject for each query of interest. Column512states explicitly each query of interest that is to be answered. Column514indicates the edges of the Web API graph that must be considered in answering each query of interest. Column516indicates the required input for each query.

Referring toFIG. 5C, there are shown a number of examples of questions or queries of interest, wherein the answers to respective queries could provide insights or other information of great interest to API users that are Web API ecosystem providers. Column518ofFIG. 5Cspecifies the analysis subject for each query of interest. Column520states explicitly each query of interest that is to be answered. Column522indicates the edges of Web API graph that must be considered in answering each query of interest.

Referring toFIG. 6, there is shown a schematic diagram that illustrates how particular data contained in or related to a Web API graph, such as graph200of FIG.2, can be used in an analytic operation to answer a specified query of interest of a Web API user. Such queries of interest are exemplified by those described above, but are by no means limited thereto. In the illustrative example ofFIG. 6, a Web API user602, identified as Jim, seeks an answer to the query of interest “Which APIs used by my contact users fulfill my requirements?”

To determine the answer to this query of interest, user602submits a request for a corresponding analytic operation. The operation may be carried out by a system such as system100, having a Web API graph200. As a first step, the operation must determine the respective requirements of user602. Using data from the Web API graph200, such as requirement data218and characteristic data216, it is determined that user602has a requirement604pertaining to a characteristic or property606, which is cost per request. The requirement604provides specific value data and a comparator for cost per request. Thus, a requirement for API user602is that cost per request can be less than or equal to, but may not exceed, 0.05$. Graph data also shows the cost per request property to be of a business type, and to be in a real domain.

In order to comply with requirement604,FIG. 6shows API user602invoking a Web API610, known as Tweet API. API graph data discloses the base URL of this API, and invocation608indicates3405previous invocations of the Tweet API. Provision612data from the API graph shows that the Tweet API provides a cost per request that can be less than or equal to, but may not exceed, 0.04$. Accordingly, the Tweet API clearly meets the cost per request requirement of user602.

Referring further toFIG. 6, contact information614of the API graph200shows that Web API user602has only a single contact user616, identified as Erik. By further mining and analysis of data related to the API graph, it is found that contact user616invokes a Web API618, known as Posti API, in connection with cost per request property606. Invocation620indicates230previous invocations of the Posti API. Provision related data622from the graph shows that the Posti API provides a cost per request that can be less than or equal to, but may not exceed, 0.03$. Thus, the Posti API used by contact user616fulfills or complies with requirement604of user602.FIG. 6also shows a connection624between the Posti API and the Tweet API.

The analytic operation usefully would then determine whether or not user602had any requirements in addition to requirement604. If not, the final answer provided by the operation, to the above query of interest, would be that the Posti API fulfills the Web API user's requirements. Otherwise, the analytic operation would successively consider all other requirements of the user. For each of these requirements, the operation would search data related to the API graph for pertinent user contact APIs. Each pertinent API found by the search would then be added to the final answer or response that the analytic operation provides to the above query of interest.

FIG. 7is a pictorial representation of a network of data processing systems in which illustrative embodiments of the invention may be implemented. Network data processing system700is a network of computers in which the illustrative embodiments may be implemented. Network data processing system700contains network702, which is the medium used to provide communications links between various devices and computers connected together within network data processing system700. Network702may include connections, such as wire, wireless communication links, or fiber optic cables.

In the depicted example, server computer704and server computer706connect to network702along with storage unit708. In addition, client computers710,712, and714connect to network702. Client computers710,712, and714may be, for example, personal computers or network computers. In the depicted example, server computer704provides information, such as boot files, operating system images, and applications to client computers710,712, and714. Client computers710,712, and714are clients to server computer704in this example. Network data processing system700may include additional server computers, client computers, and other devices not shown.

Program code located in network data processing system700may be stored on a computer-recordable storage medium and downloaded to a data processing system or other device for use. For example, program code may be stored on a computer-recordable storage medium on server computer704and downloaded to client computer710over network702for use on client computer710.

In the depicted example, network data processing system700is the Internet with network702representing a worldwide collection of networks and gateways that use the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers consisting of thousands of commercial, governmental, educational and other computer systems that route data and messages. Of course, network data processing system700also may be implemented as a number of different types of networks, such as, for example, an intranet, a local area network (LAN), or a wide area network (WAN).FIG. 7is intended as an example, and not as an architectural limitation for the different illustrative embodiments.

Turning now toFIG. 8, an illustration of a data processing system is depicted in accordance with an illustrative embodiment. In this illustrative example, data processing system800includes communications fabric802, which provides communications between processor unit804, memory806, persistent storage808, communications unit810, input/output (I/O) unit812, and display814.

Memory806and persistent storage808are examples of storage devices816. A storage device is any piece of hardware that is capable of storing information, such as, for example, without limitation, data, program code in functional form, and/or other suitable information either on a temporary basis and/or a permanent basis. Storage devices816may also be referred to as computer readable storage devices in these examples. Memory806, in these examples, may be, for example, a random access memory or any other suitable volatile or non-volatile storage device. Persistent storage808may take various forms, depending on the particular implementation.

For example, persistent storage808may contain one or more components or devices. For example, persistent storage808may be a hard drive, a flash memory, a rewritable optical disk, a rewritable magnetic tape, or some combination of the above. The media used by persistent storage808also may be removable. For example, a removable hard drive may be used for persistent storage808.

Communications unit810, in these examples, provides for communications with other data processing systems or devices. In these examples, communications unit810is a network interface card. Communications unit810may provide communications through the use of either or both physical and wireless communications links.

Input/output unit812allows for input and output of data with other devices that may be connected to data processing system800. For example, input/output unit812may provide a connection for user input through a keyboard, a mouse, and/or some other suitable input device. Further, input/output unit812may send output to a printer. Display814provides a mechanism to display information to a user.

Instructions for the operating system, applications, and/or programs may be located in storage devices816, which are in communication with processor unit804through communications fabric802. In these illustrative examples, the instructions are in a functional form on persistent storage808. These instructions may be loaded into memory806for processing by processor unit804. The processes of the different embodiments may be performed by processor unit804using computer-implemented instructions, which may be located in a memory, such as memory806.

Program code818is located in a functional form on computer readable media820that is selectively removable and may be loaded onto or transferred to data processing system800for processing by processor unit804. Program code818and computer readable media820form computer program product822in these examples. In one example, computer readable media820may be computer readable storage media824or computer readable signal media826.

Computer readable storage media824may include, for example, an optical or magnetic disk that is inserted or placed into a drive or other device that is part of persistent storage808for transfer onto a storage device, such as a hard drive, that is part of persistent storage808. Computer readable storage media824also may take the form of a persistent storage, such as a hard drive, a thumb drive, or a flash memory, that is connected to data processing system800.

In some instances, computer readable storage media824may not be removable from data processing system800. In these examples, computer readable storage media824is a physical or tangible storage device used to store program code818rather than a medium that propagates or transmits program code818. Computer readable storage media824is also referred to as a computer readable tangible storage device or a computer readable physical storage device. In other words, computer readable storage media824is media that can be touched by a person.

Alternatively, program code818may be transferred to data processing system800using computer readable signal media826. Computer readable signal media826may be, for example, a propagated data signal containing program code818. For example, computer readable signal media826may be an electromagnetic signal, an optical signal, and/or any other suitable type of signal. These signals may be transmitted over communications links, such as wireless communications links, optical fiber cable, coaxial cable, a wire, and/or any other suitable type of communications link. In other words, the communications link and/or the connection may be physical or wireless in the illustrative examples.

In some illustrative embodiments, program code818may be downloaded over a network to persistent storage808from another device or data processing system through computer readable signal media826for use within data processing system800. For instance, program code stored in a computer readable storage medium in a server data processing system may be downloaded over a network from the server to data processing system800. The data processing system providing program code818may be a server computer, a client computer, a remote data processing system, or some other device capable of storing and transmitting program code818. For example, program code stored in the computer readable storage medium in data processing system800may be downloaded over a network from the remote data processing system to the computer readable storage medium in data processing system800. Additionally, program code stored in the computer readable storage medium in the server computer may be downloaded over the network from the server computer to a computer readable storage medium in the remote data processing system.