Feature based application programming interface federation

Methods, apparatuses, and computer program products for feature based application programming interface (API) federation are disclosed. In some examples, a federated API manager may receive user input indicating source APIs including features for data processing. The federated API manager may identify elements forming one or more patterns from the features based on federation protocols. The federated API manager may identify federated operations based on the identified elements and federation operation rules. The federated API manager may generate a federated API schema based on the federated operation rules, and the federated API schema may expose the federated operations.

FIELD OF TECHNOLOGY

The present disclosure relates generally to database systems and data processing, and more specifically to feature based application programming interface federation.

BACKGROUND

Users of cloud systems often interact with the cloud systems via an application programming interface (API). Further, users of cloud systems often interact with various APIs of varying types and having various characteristics (e.g., REST, RPC, Query, Batch, etc.). For ease of use, users of these various APIs may federate these APIs into a single federated API. However, in some federation approaches, the various APIs may have interrelated hard dependencies, so that if one of the APIs is changed in some way, the other APIs may not be able to interface with the changed API, and the federated API may be broken. Further, much of the coordination that takes place in some API federation approaches must be done manually by the user.

DETAILED DESCRIPTION

In some cloud systems or platforms, users may interact with the cloud system via an application programming interface (API). Further, users of cloud systems often interact with various APIs of varying types and having various characteristics. In some cloud systems, the various APIs may be federated into a single interface through which the user may access the functions and data of the various APIs. In some examples, a cloud platform may utilize a federated API manager that may automatically recognize patterns among the various APIs, and may break the various APIs into individual features common to the various APIs. In some examples, the federated API manager may map the various APIs to these common features, and the cloud platform may compose a federated API without having hard dependencies between the constituent APIs. For example, the individual source APIs may still be modified, updated, or changed without breaking the federated API. In the process of forming the federated API, the federated API manager may perform one or more consistency checks to ensure that each of the various constituent APIs and features all work together without errors. By assembling the federated API in this way, each individual API may also change and evolve while still ensuring the consistency of the federated API.

In some examples, the federated API manager may receive user input that indicates a first and second source API to be federated. Each of the first and second source APIs may include one or more features for data processing. The federated API manager may identify one or more elements forming one or more patterns from the features of the first and second source APIs. In some examples, the federated API manager may identify these elements based on one or more federation protocols. The federated API manager may identify one or more federated operations based on the identified elements and one or more federated operation rules. The federated API manager may generate a federated API schema based on the one or more federated operation rules. In some examples, the federated API schema may expose the one or more federated operations so that the user may interact with the federated API, which may have access to the features and data of the source APIs. In this way, the federated API may be composed and utilized by the user without creating hard dependencies between source APIs, and the source APIs may be changed or updated without breaking the federated API. Thus, the technical problems present in other approaches, where source APIs have hard dependencies and cannot be altered without breaking the federated API, are reduced or eliminated.

In some examples, the federated API manager may identify that elements of the source APIs are compatible elements. For example, the federated API manager may identify that elements of the source APIs each include a compatible element identifier, a compatible data type, a compatible dataset instance identifier, a compatible lookup field associated with the compatible dataset instance identifier, a reference from one element to another, or any combination thereof. The federated API manager may form one or more federated elements through element extension, element composition, an element reference, or any combination thereof. In some examples, the federated API manager may identify errors arising in the composition of the federated API, and the federated API manager may perform a conflict resolution operation (e.g., renaming or hiding an element or a sub-element) to resolve errors arising in the federated API.

Aspects of the disclosure are initially described in the context of an environment supporting an on-demand database service. Aspects of the disclosure are then illustrated by diagrams of database systems, federation processes, an example graphical user interface, and a process flow. Aspects of the disclosure are further illustrated by and described with reference to apparatus diagrams, system diagrams, and flowcharts that relate to feature based application programming interface federation.

FIG.1illustrates an example of a system100for cloud computing that supports feature based application programming interface federation in accordance with various aspects of the present disclosure. The system100includes cloud clients105, contacts110, cloud platform115, and data center120. Cloud platform115may be an example of a public or private cloud network. A cloud client105may access cloud platform115over network connection135. The network may implement transfer control protocol and internet protocol (TCP/IP), such as the Internet, or may implement other network protocols. A cloud client105may be an example of a user device, such as a server (e.g., cloud client105-a), a smartphone (e.g., cloud client105-b), or a laptop (e.g., cloud client105-c). In other examples, a cloud client105may be a desktop computer, a tablet, a sensor, or another computing device or system capable of generating, analyzing, transmitting, or receiving communications. In some examples, a cloud client105may be operated by a user that is part of a business, an enterprise, a non-profit, a startup, or any other organization type.

Contacts110may interact with the cloud client105in person or via phone, email, web, text messages, mail, or any other appropriate form of interaction (e.g., interactions130-a,130-b,130-c, and130-d). The interaction130may be a business-to-business (B2B) interaction or a business-to-consumer (B2C) interaction. A contact110may also be referred to as a customer, a potential customer, a lead, a client, or some other suitable terminology. In some cases, the contact110may be an example of a user device, such as a server (e.g., contact110-a), a laptop (e.g., contact110-b), a smartphone (e.g., contact110-c), or a sensor (e.g., contact110-d). In other cases, the contact110may be another computing system. In some cases, the contact110may be operated by a user or group of users. The user or group of users may be associated with a business, a manufacturer, or any other appropriate organization.

Data center120may include multiple servers. The multiple servers may be used for data storage, management, and processing. Data center120may receive data from cloud platform115via connection140, or directly from the cloud client105or an interaction130between a contact110and the cloud client105. Data center120may utilize multiple redundancies for security purposes. In some cases, the data stored at data center120may be backed up by copies of the data at a different data center (not pictured).

Subsystem125may include cloud clients105, cloud platform115, and data center120. In some cases, data processing may occur at any of the components of subsystem125, or at a combination of these components. In some cases, servers may perform the data processing. The servers may be a cloud client105or located at data center120.

In some examples, the cloud platform115may receive user input (e.g., from a cloud client105) that indicates a first and second source API to be federated. Each of the first and second source APIs may include one or more features for data processing. The cloud platform115may identify one or more elements forming one or more patterns from the features of the first and second source APIs. In some examples, cloud platform115may identify these elements based on one or more federation protocols. The cloud platform115may identify one or more federated operations based on the identified elements and one or more federated operation rules. The cloud platform115may generate a federated API schema based on the one or more federated operation rules. In some examples, the federated API schema may expose (e.g., to one or more cloud clients105) the one or more federated operations so that a cloud client105may interact with the federated API, which may have access to the features and data of the source APIs. In this way, the federated API may be composed by the cloud platform115and utilized by a cloud client105without creating hard dependencies between source APIs, and the source APIs may be changed or updated without breaking the federated API.

In some approaches to API federation, each of the source APIs may be strictly matched with each of the other source APIs, and if a source API makes a change in nomenclature, data types, or another element, the federated API may not be able to access features or data of the source API. Further, the source APIs may have hard dependencies between each other, such that if a source API is changes, another source API may also have to be changed in a similar way to accommodate the change in the first source API. In addition, many such changes to maintain compatibility and functionality of the federated API may be performed manually by a user or an administrator.

The approaches described herein include utilization of a federated API manager that may break the source APIs into individual features that can be federated (e.g., read, list, update, query, subscribe, publish), and may further define federation primitives that can be used to expose such features in an API independent way (e.g., identifiers, finders, or reverse-finder methods). The federated API manager may also map different APIs to a set of common features and allow enrichment of those features with the federation primitives. In this way, the individual APIs may be composed into a federated API without hard dependencies between the individual APIs. This identification, mapping, and composition may be performed automatically based on federated operation rules, federation protocols, or other parameters, thus reducing or eliminating the need for a user or administrator to intervene.

Additionally, or alternatively, the federated API manager may check the consistency of the federated API automatically, notifying owners of the individual APIs if some aspect of their APIs will break the overall federated API. Further, the federated API manager may also perform one or more conflict resolutions operations (either automatically or as prompted by a user or administrator) to resolve errors arising in the generation of the federated API. The federated API may be exposed in any combination of protocols that support the features of the source APIs that are being federated. In addition, consistency checks based on rules, configurations, or other parameters may be performed to ensure consistency and allow for future additions of features to the source APIs. Thus, a flexible and agile mechanism for federation and collaboration of the source APIs may be achieved without compromising the ability of the individual APIs to change and evolve. Through these approaches, the technical problems present in other approaches where the source APIs have hard interdependencies and may not be modified or updated without breaking the federation may be reduced or eliminated.

For example, if a user desires to federate a number of APIs (e.g., an API dealing with customer orders and an API dealing with shipping of products to the customers) to more easily manage the APIs and the data associated with the APIs, the user may send a request (e.g., via a cloud client105) to the cloud platform115identifying the source APIs to be federated. The cloud platform115may identify elements from the features found in the source APIs that may form patterns. The cloud platform115may recognize those patterns and identify or determine federated operations based on those pattern forming elements. The cloud platform115may form a federated API that may expose these federated operations to the user, such that the user may access the functions and data from the source APIs through the unified interface of the federated API.

FIG.2illustrates an example of a database system200that supports feature based application programming interface federation in accordance with aspects of the present disclosure. The database system200may include a client205and an application server210.

The application server210may support a federated API manager212that may generate a federated API schema215. The federated API schema215may offer capabilities (e.g., capabilities or features such as read, list, update, query, subscribe, or publish) at a federated level. For example, the federated API schema215may expose an endpoint to which a client205may connect to utilize a query capability at the federated level.

The federated API manager212may generate the federated API schema215based on a number of source APIs, such as the first source API220-aand the second source API220-b. The federated API schema215may be generated based on any number of source APIs, represented by the N-th source API220-c. Each of the source APIs220may include features, such as the first API features225-aassociated with the first source API220-a, the second API features225-bassociated with the second source API220-b, and the N-th API features225-cassociated with the N-th source API220-c. In some examples, the API features225may include data processing capabilities, data storage capabilities, data transformation capabilities, or other data processing tasks. For example, an API feature225may include retrieval of data associated with a customer based on an input provided by the client205, and the API feature225may return the requested data to the client205.

In some examples, the source APIs may enter into the federation actively. The source APIs may comply with a federation protocol, and the generation of the federated API schema215may be based upon such a federation protocol. The federation protocol may define, identify, or select rules, procedures, configurations, or other parameters that define how the federated API schema215may be generated. In some examples, the federation protocol may be regarded as a contract that binds the federated parts, and governs the relationships between the various source APIs220and associated API features225. In some examples, the federation protocol may include federation metadata. For example, the federation protocol may include various elements, including names, fields, finders, keys, linking, and extensions, that may define or identify various relationships between the source APIs220to aid in the generation of the federated API schema215.

In some examples, the federated API manager212may generate the federated API schema215by automatically generating or manipulating federation metadata from the source APIs220. The federated API manager212may further configure, customize, or manipulate the federation metadata to comply with the federation protocol, and the federation metadata may be used as input for the execution of runtime federated operations. In some examples, generation of the federated API schema215may include a set of customizations that may be applied to the source APIs220to prepare or modify the source APIs220for federations. In some examples, federation specific metadata (e.g., links or references across different source APIs220) may be designed to make any conceptual connections across the source APIs220explicit and consumable. In some examples, generation of the federated API schema215may also include the design, selection, or identification of governance tools that may ensure that changes to the individual source APIs220do not break the federated API schema215and the integrations of any clients that may be consuming the federated API schema215.

In some examples, the federated API manager212may generate the federated API schema215by generating a federated API metadata model or data graph. A data graph may be an API model that describes the various features, data, resources, or connections of an API (e.g., the source APIs220). In some examples, the input API models may be transformed into a data graph that may be consumed by a query (or other operational) engine. In some examples, one or more data graphs may be merged into a single data graph that may be the logical union of the individual data graphs, in some cases without loss of information. In some examples, one or more federated operations may be performed on such a merged data graph (e.g., the merged data graph may be queried).

In some examples, the source APIs220may be autonomous. That is, the source APIs220may be free to change and evolve over time. In some examples, the source APIs220may be free to change and evolve as long as they comply with the federation protocol. In some examples, such a federated API schema215or other federated systems may be decentralized systems, including portions that are associated with various systems, servers, machines, virtual machines, processing nodes, workers, or other data processing elements. For example, as shown inFIG.2, the second source API220-bmay be associated with a different application server (and may not be associated with the application server210on which the federated API schema215is generated). In some examples, all of the source APIs220may be associated with the application server210. In other examples, a portion of the source APIs220or none or the source APIs220may be associated with the application server210.

FIG.3illustrates an example of a database system300that supports feature based application programming interface federation in accordance with aspects of the present disclosure. In some examples, the database system may include an application server, on which a federated API manager305may operated. The federated API manager305may generate a federated API schema320based on a first source API310and a second source API315. Though only two source APIs are described in relation toFIG.3, the federated API manager305may use any number of source APIs to generate the federated API schema320.

In some examples, the first source API310and the second source API315may include various elements, such as the first elements325and the second elements330. As used herein, elements may include data processing functions or structures, data storage functions or structures, or other data processing elements. For example, an element may be a type that identifies, stores, or organizes data used in a source API (e.g., the first source API310or the second source API315). For example, a type may be named “Product,” “OrderItem,” or “Order,” and may contain or be associated with data relating to the type (e.g., product data, order item data, or order data). In some examples, an element (e.g., a type) may also contain one or more sub-elements. Such sub-elements may be fields within a type that may provide data related to the element. For example, an element (e.g., a type) may be a “Country” type that contains data associated with countries, and the element or type may include a sub-element (e.g., a field) indicating, for example, a telephone prefix or a currency associated with the country. In addition, the data values stored in the element may be associated with the sub-element (e.g., field). For example, a data value for a sub-element (e.g., field) of “telephone prefix” may be “+39” and a data value for a sub-element (e.g., field) of “currency” may be “Euro.”

In some examples, the federated API manager305may generate the federated API schema320by identifying, determining, or selecting one or more patterns in the first elements325and the second elements330. A pattern may be an operation defined over elements (e.g., types) in different source APIs (e.g., the first source API310and the second source API315) to combine the elements as a single element in the federated API schema320. For example, the federated API manager305may identify that the first elements325and the second elements330form a first pattern335, a second pattern340, and a third pattern345. The identification, determination, or selection of such patterns may be accomplished in a variety of ways. For example, the federated API manager305may identify, determine, or select elements that may include compatible elements. In some examples, the federated API manager305may identify two elements that are included in both the first source API310and the second source API315, and the federated API manager305may further identify that the elements contain common sub-elements (e.g., fields). As such, the federated API manager305may determine or identify that the two elements are compatible elements.

The federated API manager305may deem or determine elements to be compatible by identifying or determining that the elements include compatible element identifiers. For examples, the first elements325and the second elements330may include elements that have element identifiers with a value of “Monetary Amount.” In some examples, the federated API manager305may deem or determine elements to be compatible by identifying or determining that the elements include a compatible data type. For example, the federated API manager305may determine that the elements associated with the first pattern335may include a string data type. In some examples, such compatible element identifiers or compatible data types may be associated with an element composition capability of the federated API manager305or the federated API schema320, as described herein.

In some examples, the federated API manager305may deem or determine elements to be compatible by identifying or determining that the elements include a compatible dataset instance identifier. In some examples, a dataset instance identifier may also be known as a key. A key may be any combination of properties that uniquely identify instances of the element. For example, if elements (e.g., elements from the first elements325and the second elements330that are associated with the first pattern335) support the same key, information from both elements may be merged. By defining the key, information in a first element may be extended with information from other matching elements. For example, information in a local graph may be extended with information from other data graphs with a matching type, key, and offering a default constructor. Another example may include when a local reference in a first API (e.g., the first source API310) may refer to data available in a second API (e.g., the second source API315). In some examples, local information may be provided as a source for queries over multiple data graphs, (e.g., when joining different parts of a type for the same key joining information from multiple APIs). In some examples, such use of keys may be associated with an element extension capability of the federated API manager305or the federated API schema320, as described herein.

In some examples, the federated API manager305may deem or determine elements to be compatible by identifying or determining that the elements include a compatible lookup field (e.g., a finder) associated with compatible dataset instance identifier. In some examples, a finder may be a sub-element (e.g., a field) at the top level element (e.g., type) of an individual API that may return single instances of a type. In some examples, a finder or lookup field may give access to a data set for an element (e.g., type) to clients (e.g., query clients). Without a finder, clients may not be able to directly fetch data for a type from an API. However, in some cases, a client may still find that type of data nested in a different type that does have a finder.

In some examples, the federated API manager305may deem or determine elements to be compatible by identifying or determining that a first element includes a reference to a second element. For example, if an element of the first elements325contains a reference to data associated with another element of the second elements330, the federated API manager305may identify that the elements are compatible, and may also determine that the elements are associated with a pattern (e.g., the first pattern335, the second pattern340, or the third pattern345). In some examples, such use of references may be associated with an element reference capability of the federated API manager305or the federated API schema320, as described herein.

In some examples, the federated API manager305may identify, determine, or select compatible elements based on a federation protocol350. As described herein, the federation protocol may define, identify, or select rules, procedures, configurations, or other parameters that define how the federated API schema320may be generated. In some examples, the federation protocol may be regarded as a contract that binds the federated parts, and governs the relationships between the first source API310and the second source API315and associated API features (e.g., API features225as discussed in relation toFIG.2). In some examples, the federation protocols350may capture one or more strategies to federate a set of source API schemas into a final federated API schema. The federation mechanism may be defined through a federation algorithm that may be configured with different federation protocols. The outcome may be a federated schema (e.g., the federated API schema320) that may describe the combined schema of all the source API schemas or a set of errors in the sources.

In some examples, the federation protocols350may be associated with federation metadata. For example, the federation protocols350may include various rules, procedures, configurations, or parameters, (e.g., rules concerning names, fields, finders, keys, linking, or extensions) that may define or identify various relationships between the first source API310and the second source API315to aid in the generation of the federated API schema320. For example, the federation protocols350may establish that elements with the same name in the source APIs may be merged recursively in the federated API schema320. In some examples, matching elements may be merged, and, in some examples, for each matching pair of elements, matching sub-elements may also be merged.

In some examples, the federation protocols350may establish that the federated API schema320may include a number of sub-elements (e.g., fields) in an element (e.g., a type). In some examples, the sub-element set (e.g., the field set) in a federated API schema320may be the union of the merged sub-elements (e.g., fields) for the element (e.g., type) in each individual API (e.g., the first source API310and the second source API315). In some examples, mandatory sub-elements for an element present in every single individual API may be mandatory in the federated API schema320. Any other sub-element, mandatory or optional, in the source APIs become optional in the federated schema. In some examples, finders cannot be merged, and are instead renamed.

In some examples, the federation protocols350may establish that the data set containing all the instances for a type in the federated schema may be the union of the data sets for the types in the individual APIs. In some examples, finders in the federated schema give access to the subset of the instances accessible through that finder.

In some examples, the federation protocols350may establish that a key or dataset instance identifier may be a sub-element (e.g., field) in an element (e.g., type) chosen by the API owner to uniquely identify each instance of that element. For each value of the key there may be only one resource in any given API. In some examples, multiple fields in an element may be candidate keys. In some examples, one key may be picked by the API owner as the designated key. In some examples, keys allow a federation layer or federated API schema320to join data with the same key in a query or other federated operation (e.g., the first federated operation355).

In some examples, the federation protocols350may establish a requirement for default finder, which may be a finder field used to perform data lookups by key over the data set of an element. In some examples, multiple finders could be the default finders. In some examples, default finders allow the federated API schema320to look up for data from the different individual APIs that may be joined when executing a query or other federated operation.

In some examples, the federation protocols350may establish that if a dataset instance identifier (e.g., a key) is defined for one type in an API, every source API may define the same dataset instance identifier or key for that type. In some examples, the source APIs may support the same dataset (e.g., key id=1 must be available in all APIs extending the element with mandatory fields). In some examples, the same value for a dataset instance identifier and element identifies the same information in some or all source APIs in the federated API schema320(e.g., customers with key id=1 may identify the same customer in any API supporting the customer element). In some examples, some or all of the source APIs providing one or more lookup fields (e.g., finders) for an element with a defined dataset instance identifier (e.g., a key) may define at least one default lookup field. In some examples, default lookup fields may be merged.

In some examples, the federation protocols350may establish that if a dataset instance identifier (e.g., key) is defined for an element (e.g., type) all the data instances for that type may be joined by the dataset instance identifier in the federated API schema320, instead of being added as a union. In some examples, common fields provided by more than one source API, that are not keys, may have the same values for an instance identified by the dataset instance identifier in all the APIs. In some examples, fields provided by only one source API may appear in the federated schema with the same type of access they have in the individual source API (e.g., mandatory or optional).

In some examples, the federation protocols350may establish that a reference may not extend an element. In some examples, references may not introduce new sub-elements not provided already by another source API that may define a default lookup field for the element. In some examples, references may be merged into the federated API schema320just as other elements may be merged into the federated API schema320.

Though examples of federation protocols are provided herein, these examples should be interpreted as examples only, and should not limit the scope of possible federation protocols.

In some examples, the federation protocols350may establish parameters, configurations, or rules about reference capabilities. In some examples, references may not extend an element. For example, a reference may not introduce new fields not provided already by other source APIs. In some examples, references are merged into the federated schema as any other type definition.

In some examples, the federated API manager305may identify, determine, select, or create one or more federated operations (e.g., the first federated operation355, the second federated operation360, or the third federation operation365). In some examples, the first federated operation355, the second federated operation360, and the third federation operation365may be associated with the first pattern335, the second pattern340, and the third pattern345, respectively. For example, based on the identification of the first pattern335, the second pattern340, and the third pattern345in the first elements325and the second elements330, the federated API manager305may identify, determine, select, or create the first federated operation355, the second federated operation360, and the third federation operation365.

In some examples, the federated operations may be operations that may be accessible to a client that may be consuming the federated API schema320. For example, the first federated operation355may be a query operation that may retrieve customer information based on an input provided to the first federated operation355. Based on such a first federated operation355, the federated API schema320may retrieve the requested customer information that may be stored or associated with one or more elements of the first elements325of the first source API310and the second elements330of the second source API315. Thus, the client may be accessing data, features, functions, or information through the federated API schema320.

In some examples, the federated API manager305may identify, determine, select, or create a federated operation (e.g., the first federated operation355, the second federated operation360, or the third federation operation365) based on one or more federation operation rules370. In some examples, the federated operation rules370may include configurations, rules, procedures, or parameters that may define, determine, or affect how the federated operations may be identified, determined, selected, or created. For example, a federated operation rule370may establish that a federated operation that receives a string as an input from a client may require that information or values returned to the client also be formatted as a string. As such, based on the federated operation rule370, a federated operation (e.g., the first federated operation355) may include a data transformation that may transform data retrieved from a source API (e.g., the first source API310) from an integer data type to a string data type to comply with the requirement of the federation operation rules. Many other rules, configurations, procedures, and parameters may also be included in the federation operation rules, and the provided example discusses only one possibility out of many.

In some examples, the federated API manager305may generate the federated API schema320based on the federated operation rules370. For example, the federated operation rules370may define or determine how various federated operations (e.g., the first federated operation355, the second federated operation360, or the third federation operation365) may interact with one another. For example, the third federated operation365may also invoke the second federated operation360for data retrieval (as one of many possible examples). Such an interaction may be governed or affected by the federation operation rules370.

In some examples, the federated API manager305may generate the federated API schema320generating one or more federated elements. The federated elements may be similar to first elements325or second elements330, except that the federated elements may have been extended, composed, referenced, or modified based on the identified patterns (e.g., the first pattern335, the second pattern340, or the third pattern345). For example, the federation protocols350, the federation operation rules370, or both may allow the first source API310and the second source API315to collaborate through various capabilities, including extension, reference, and composition. Extension and reference may rely on the definition of keys for the different elements (e.g., types), allowing the API Federation service to join and link data provided by the individual source APIs (e.g., the first source API310and the second source API315). Composition may merge elements (e.g., as a default option) if no keys are defined. The generation, identification, or selection of such federated elements through extension, reference, and composition is additionally discussed inFIGS.4-6herein.

In some examples, the federated API manager305may generate the federated API schema320through use of a federation algorithm. The federation algorithm may include various steps, rules, analyses, procedures, operations, determinations, selections, or other elements that may be used to generate the federated API schema320. For example, the federation algorithm may be defined as a function that receives a federation protocol and a set of canonical API schemas and returns a federated API schema (e.g., the federated API schema320) with an associated set of errors. In some examples, the federation algorithm may use information in the individual source schemas and may not rely on any metadata stored at the federated level.

In one exemplary federation algorithm, the federated API manager305may initialize the federated API schema320with a null schema including an empty set of elements (e.g., types) and errors. The federated API manager305may iterate through all canonical source API schemas (e.g., the first source API310and the second source API315). The federated API manager305may iterate through all elements (e.g., elements (e.g., types)) in each canonical source API schema.

If there is an element (e.g., type) in the federated schema with a matching name, the federated API manager305may execute various actions. If the action defined in the federation protocol for both elements (e.g., type) is an error, the federated API manager305may add the error to the list of errors in the federated schema. If the action defined in the federation protocol for both element (e.g., type) is a rewrite operation, the federated API manager305may add the rewritten element (e.g., type) to the set of elements (e.g., types) in the canonical source API schema. If the action defined in the federation protocol for both elements (e.g., types) is a composition action, the federated API manager305may add the composed element (e.g., type) to the set of elements (e.g., types) in the federated schema and may add all operations from the canonical source returning the composed element (e.g., type) to the set of operations in the federated schema. If the action defined in the federation protocol for both elements (e.g., types) is an extension action, the federated API manager305may add the extended element (e.g., type) to the set of elements (e.g., types) in the federated schema, and may add all element (e.g., type) resolvers from the canonical source returning the extended element (e.g., type) to the set of operations in the federated schema. If the action defined in the federation protocol for both elements (e.g., types) is a reference or link action, the federated API manager305may, for all sub-elements (e.g., fields) in the federated schema returning the reference element (e.g., type) being linked, rewrite them to return the element (e.g., type) referenced.

However, if there is not matching element (e.g., type) defined in the federated schema, the federated API manager305may add the element (e.g., type) to the set of elements (e.g., types) in the federated schema.

In some examples, the federated API manager305may then return the federated schema after iterating through all of the canonical source API schemas.

In some examples, the federated API manager305may perform a consistency check or error checking on the generated federated API schema320to ensure that the federated API schema320functions properly and correctly incorporates and combines the various sources APIs. In some examples, a consistency check may include the process of checking if one individual source API schema may be added to the federated schema without violating the federation protocol. In some examples, a consistency check may work with the information of the individual API schema metadata and the federated API schema320metadata. For example, a consistency check may include determining whether a matching element exists in the federated API schema320that matches an element in a candidate source API. Such a consistency check may also include determining whether a dataset instance identifier (e.g., a key) is found in the federated API schema320or in the candidate source API. In some examples, a consistency check may include determining whether there are new sub-elements (e.g., fields) in the candidate source API. In some examples, a consistency check may include determining whether there are compatible sub-elements between the federated API schema320and the candidate source API. Further, in some examples, a consistency check may include determining whether a default lookup field (e.g., finder) may be defined or found in the candidate source API.

In some examples, the federated API manager305may identify one or more federation errors arising in the federated API schema320, and the federated API manager305may perform a conflict resolution operation to resolve one or more federation errors. For example, the federated API manager305may rename an element (e.g., a type) or a sub-element (e.g., a field). Additionally, or alternatively, the federated API manager305may hide an element (e.g., a type) or a sub-element (e.g., a field).

FIG.4illustrates an example of an extension capability400that supports feature based application programming interface federation in accordance with aspects of the present disclosure. In some examples, a federated API schema405may be generated based on source APIs, such as the shipping API410and the orders API415. The shipping API410and the orders API415are only examples of possible source APIs, and the description of the extension capability herein is not limited to this particular example. Rather, the principles and approaches described herein may be applied to any number and any type of source API.

In some examples, element extension (or type extension) may enrich the same element or type of information providing new fields for the element or type in the federated API schema405. In some examples of element extension, individual APIs may provide a network endpoint to access directly the element or type data. Individual APIs may act as providers of information, and the federated API schema may join the data from the different providers through a shared key for the federated element or type.

For example, the shipping API410and the orders API415may both include an element or type named “Country.” The shipping API410and the orders API415may both include a common dataset instance identifier or key (e.g., an ID of “1”). As described herein, a key may be any combination of properties that uniquely identify instances of the element. However, the shipping API410element may include a telephone prefix associated with the dataset instance identifier or key, and the orders API415may include a currency associated with the same dataset instance identifier or key. Thus, the country element of the shipping API410and the country element of the orders API415may form a pattern (e.g., the first pattern335as discussed in relation toFIG.3) and may be extended. In some examples, extension may include combining new fields from the various source APIs (e.g., the shipping API410and the orders API415) to provide better information to the client interfacing with the federated API schema405. As such, the federated API schema405may contain or be associated with the fields and information from the shipping API410and the orders API415. In some examples, a new federated element (e.g., the country element of the federated API schema405) may be generated, determined, or identified as part of the generation of the federated API schema405.

FIG.5illustrates an example of a reference capability500that supports feature based application programming interface federation in accordance with aspects of the present disclosure. In some examples, a federated API schema505may be generated based on source APIs, such as the employees API508, the shipping API510and the orders API515. The shipping API510may be an example of the shipping API410discussed in relation toFIG.4, and the orders API515may be an example of the orders API415discussed in relation toFIG.4. It should be noted that the shipping API510and the orders API515are only examples of possible source APIs, and the description of the extension capability herein is not limited to this particular example. Rather, the principles and approaches described herein may be applied to any number and any type of source API.

In some examples, element references (e.g., type references) may connect different items of information in the federated API schema505by holding a reference to the target element key (e.g., type key) in the individual API schema (e.g., the employees API508). For example, a reference (or linking) function may be a function defined for a pair of compatible type reference and network addressable elements (e.g., types) with a common key that may combine the elements into an image element referencing or linking the element holding the reference to the target element. In some examples, individual APIs (e.g., the employees API508) must contain a reference or embedded foreign key or dataset instance identifier. In some examples, a federated API manager may resolve the references, effectively linking information from multiple APIs. In some examples, reference capabilities may also be known as linking capabilities.

For example, in the employees API508, the employee element may contain a reference to a country element, and the employee element and the country element may both contain the same key (e.g., an ID of “1”). As such, the reference may be used to connect the employee element and the country element from the employees API508with the additional country information from the shipping API510and the orders API515(e.g., the information appearing in the country element of the federated API schema505and as shown in relation to the shipping API410and the orders API415discussed in relation toFIG.4). As such, the employee and country elements of the federated API schema505are enriched with information from the various source APIs.

In some examples, as part of the generation of the federated API schema505, an operation for retrieval of the first element of a first source API (e.g., the employee element of the employees API508) may be replaced with an operation for retrieval of the first element of a second source API (e.g., the country element of the shipping API510or the orders API515). Alternatively, or additionally, an operation for retrieval of retrieval of a target of a reference (e.g., the reference from the employee element of the employees API508to the country element of the employees API508) may be replaced with an operation for retrieval of an enriched element of a federated API schema (e.g., the country element of the federated API schema505).

FIG.6illustrates an example of a composition capability600that supports feature based application programming interface federation in accordance with aspects of the present disclosure. In some examples, a federated API schema605may be generated based on source APIs, such as the shipping API610and the orders API615. The shipping API610may be an example of the shipping API410or shipping API510discussed in relation toFIGS.4and5, and the orders API615may be an example of the orders API415or the orders API515discussed in relation toFIGS.4and5. The shipping API610and the orders API615are only examples of possible source APIs, and the description of the extension capability herein is not limited to this particular example. Rather, the principles and approaches described herein may be applied to any number and any type of source API.

In some examples, composition may be used to generate federated elements in the federated API schema605where no individual source has provided a key. In some examples, a key may be not provided because the information may be a value object, or because there is no join of information. As such, element composition (e.g., type composition) may be utilized to enrich a federated element (e.g., federated type).

As shown inFIG.6, both the shipping API610and the orders API615may include a “monetary amount” element, and each element (e.g., type) may include a sub-element (e.g., field) of “value” and associated data (“200.99”). Through composition, the sub-elements (e.g., fields) that have matching names may be recognized, and the associated data from both the shipping API610and the orders API615may be combined under the same sub-element in federated element “monetary amount” in the federated API schema605.

FIG.7illustrates an example of a graphical user interface700that supports feature based application programming interface federation in accordance with aspects of the present disclosure. In some examples, the graphical user interface (GUI)700may include an interface through which a user may view various source APIs, elements, sub-elements, patterns, and other aspects of the approaches described herein. Through the GUI700, the user may transmit user input to the federated API manager for federation of the various source APIs into a federated API. Similarly, the federated API manager may also report errors, provide suggestions or recommendations (e.g., recommendations for error resolution), or other notifications, updates, message, or information to the user through the GUI700.

For example, in GUI700, various source APIs may be viewed through the source API selection area705. In this particular example, a user may be viewing the orders API. In the main display area710, information about the selected orders API may be displayed. For example, the GUI may display information about the orders API's individual resources, and collective resources. Such information may be helpful to a user during the process of transmitting information to a federated API manager that may generate a federated API through the approaches described herein.

FIG.8illustrates an example of a process flow800that supports feature based application programming interface federation in accordance with aspects of the present disclosure. The process flow800may implement various aspects of the present disclosure described with reference toFIGS.1-3. The process flow800may include a client805and an application server810, which may be examples of the clients105and205and federated API manager212and305as described with reference toFIGS.1-3.

In the following description of the process flow800, the operations between the client805and the application server810may be performed in different orders or at different times. Some operations may also be left out of the process flow800, or other operations may be added. Although the client805and the application server810are shown performing the operations of the process flow800, some aspects of some operations may also be performed by one or more other wireless devices.

At815, the application server810may receive, via a user interface of the federated API manager, first user input indicating a first source API and a second source API for generating a federated API. The first source API and the second source API may each include one or more features for data processing.

At820, the application server810may identify, by the federated API manager, elements that may form one or more patterns from the one or more features of the first source API and the one or more features of the second source API based on one or more federation protocols.

At825, the application server810may identify, by the federated API manager, one or more federated operations based on the identified one or more elements and one or more federated operation rules.

At830, the application server810may identify that a first element of the first source API and a first element of the second source API are compatible elements. In some examples, identifying that the first element of the first source API and the first element of the second source API are compatible elements may include identifying that the first element of the first source API and the first element of the second source API each include a compatible element identifier. In some examples, identifying that the first element of the first source API and the first element of the second source API are compatible elements may include identifying that the first element of the first source API and the first element of the second source API each include a compatible data type. In some examples, identifying that the first element of the first source API and the first element of the second source API are compatible elements may include identifying that the first element of the first source API and the first element of the second source API each include a compatible dataset instance identifier. In some examples, identifying that the first element of the first source API and the first element of the second source API are compatible elements may include identifying that the first element of the first source API and the first element of the second source API each include a compatible lookup field associated with the compatible dataset instance identifier. In some examples, identifying that the first element of the first source API and the first element of the second source API are compatible elements may include identifying that the first element of the first source API includes a reference that is compatible with the first element of the second source API.

At835, the application server810may generate, by the federated API manager, the federated API schema based on the one or more federated operation rules. The federated API schema may expose the one or more federated operations. In some examples, generating the federated API schema may include generating a federated element comprising the union of a set of sub-elements of the first element of the first source API and a set of sub-elements of the first element of the second source API. In some examples, generating the federated API schema may include replacing an operation for retrieval of the first element of the first source API with an operation for retrieval of the first element of the second source API. In some examples, generating the federated API schema may be based on the one or more federated operations.

At840, the application server810may identify, by the federated API manager, one or more federation errors arising in the federated API schema. In some examples, the application server810may determine whether a schema of the first source API or the second source API violates the one or more federation operation rules.

At845, the application server810may perform a conflict resolution operation to resolve at least one of the one or more federation errors. In some examples, the conflict resolution operation may include renaming an element, renaming a sub-element of an element, hiding an element, hiding a sub-element, or any combination thereof.

FIG.9shows a block diagram900of a device905that supports feature based application programming interface federation in accordance with aspects of the present disclosure. The device905may include an input module910, an output module915, and a federated API manager920. The device905may also include a processor. Each of these components may be in communication with one another (e.g., via one or more buses).

The input module910may manage input signals for the device905. For example, the input module910may identify input signals based on an interaction with a modem, a keyboard, a mouse, a touchscreen, or a similar device. These input signals may be associated with user input or processing at other components or devices. In some cases, the input module910may utilize an operating system such as iOS®, ANDROID®, MS-DOS®, MS-WINDOWS®, OS/2®, UNIX®, LINUX®, or another known operating system to handle input signals. The input module910may send aspects of these input signals to other components of the device905for processing. For example, the input module910may transmit input signals to the federated API manager920to support feature based application programming interface federation. In some cases, the input module910may be a component of an I/O controller1110as described with reference toFIG.11.

The output module915may manage output signals for the device905. For example, the output module915may receive signals from other components of the device905, such as the federated API manager920, and may transmit these signals to other components or devices. In some examples, the output module915may transmit output signals for display in a user interface, for storage in a database or data store, for further processing at a server or server cluster, or for any other processes at any number of devices or systems. In some cases, the output module915may be a component of an I/O controller1110as described with reference toFIG.11.

For example, the federated API manager920may include a user input component925, a pattern recognition component930, a federated operation component935, a federated schema generation component940, or any combination thereof. In some examples, the federated API manager920, or various components thereof, may be configured to perform various operations (e.g., receiving, monitoring, transmitting) using or otherwise in cooperation with the input module910, the output module915, or both. For example, the federated API manager920may receive information from the input module910, send information to the output module915, or be integrated in combination with the input module910, the output module915, or both to receive information, transmit information, or perform various other operations as described herein.

The federated API manager920may support generating a federated API schema by a federated API manager in accordance with examples as disclosed herein. The user input component925may be configured as or otherwise support a means for receiving, via a user interface of the federated API manager, first user input indicating a first source API and a second source API for generating a federated API, wherein the first source API and the second source API each comprise one or more features for data processing. The pattern recognition component930may be configured as or otherwise support a means for identifying, by the federated API manager, elements forming one or more patterns from the one or more features of the first source API and the one or more features of the second source API based at least in part on one or more federation protocols. The federated operation component935may be configured as or otherwise support a means for identifying, by the federated API manager, one or more federated operations based at least in part on the identified one or more elements and one or more federated operation rules. The federated schema generation component940may be configured as or otherwise support a means for generating, by the federated API manager, the federated API schema based at least in part on the one or more federated operation rules, the federated API schema exposing the one or more federated operations.

FIG.10shows a block diagram1000of a federated API manager1020that supports feature based application programming interface federation in accordance with aspects of the present disclosure. The federated API manager1020may be an example of aspects of a federated API manager or a federated API manager920, or both, as described herein. The federated API manager1020, or various components thereof, may be an example of means for performing various aspects of feature based application programming interface federation as described herein. For example, the federated API manager1020may include a user input component1025, a pattern recognition component1030, a federated operation component1035, a federated schema generation component1040, a conflict resolution component1045, a federated element generation component1050, or any combination thereof. Each of these components may communicate, directly or indirectly, with one another (e.g., via one or more buses).

The federated API manager1020may support generating a federated API schema by a federated API manager in accordance with examples as disclosed herein. The user input component1025may be configured as or otherwise support a means for receiving, via a user interface of the federated API manager, first user input indicating a first source API and a second source API for generating a federated API, wherein the first source API and the second source API each comprise one or more features for data processing. The pattern recognition component1030may be configured as or otherwise support a means for identifying, by the federated API manager, elements forming one or more patterns from the one or more features of the first source API and the one or more features of the second source API based at least in part on one or more federation protocols. The federated operation component1035may be configured as or otherwise support a means for identifying, by the federated API manager, one or more federated operations based at least in part on the identified one or more elements and one or more federated operation rules. The federated schema generation component1040may be configured as or otherwise support a means for generating, by the federated API manager, the federated API schema based at least in part on the one or more federated operation rules, the federated API schema exposing the one or more federated operations.

In some examples, to support identifying, by the federated API manager, elements forming one or more patterns, the pattern recognition component1030may be configured as or otherwise support a means for identifying that a first element of the first source API and a first element of the second source API are compatible elements.

In some examples, to support identifying that the first element of the first source API and the first element of the second source API are compatible elements, the pattern recognition component1030may be configured as or otherwise support a means for identifying that the first element of the first source API and the first element of the second source API each comprise a compatible element identifier.

In some examples, to support generating the federated API schema, the federated element generation component1050may be configured as or otherwise support a means for generating a federated element comprising the union of a set of sub-elements of the first element of the first source API and a set of sub-elements of the first element of the second source API.

In some examples, to support identifying that the first element of the first source API and the first element of the second source API are compatible elements, the pattern recognition component1030may be configured as or otherwise support a means for identifying that the first element of the first source API and the first element of the second source API each comprise a compatible data type.

In some examples, to support identifying that the first element of the first source API and the first element of the second source API are compatible elements, the pattern recognition component1030may be configured as or otherwise support a means for identifying that the first element of the first source API and the first element of the second source API each comprise a compatible dataset instance identifier.

In some examples, to support generating the federated API schema, the federated element generation component1050may be configured as or otherwise support a means for generating a federated element comprising the union of a set of sub-elements of the first element of the first source API and a set of sub-elements of the first element of the second source API.

In some examples, to support identifying that the first element of the first source API and the first element of the second source API are compatible elements, the pattern recognition component1030may be configured as or otherwise support a means for identifying that the first element of the first source API and the first element of the second source API each comprise a compatible lookup field associated with the compatible dataset instance identifier.

In some examples, to support identifying that the first element of the first source API and the first element of the second source API are compatible elements, the pattern recognition component1030may be configured as or otherwise support a means for identifying that the first element of the first source API comprises a reference that is compatible with the first element of the second source API.

In some examples, to support generating the federated API schema, the federated schema generation component1040may be configured as or otherwise support a means for replacing an operation for retrieval of the first element of the first source API with an operation for retrieval of the first element of the second source API.

In some examples, the conflict resolution component1045may be configured as or otherwise support a means for identifying, by the federated API manager, one or more federation errors arising in the federated API schema. In some examples, the conflict resolution component1045may be configured as or otherwise support a means for performing a conflict resolution operation to resolve at least one of the one or more federation errors.

In some examples, the conflict resolution operation comprises renaming an element, renaming a sub-element of an element, hiding an element, hiding a sub-element, or any combination thereof.

In some examples, the conflict resolution component1045may be configured as or otherwise support a means for determining whether a schema of the first source API or the second source API violates the one or more federation operation rules.

In some examples, generating the federated API schema is further based at least in part on the one or more federated operations.

FIG.11shows a diagram of a system1100including a device1105that supports feature based application programming interface federation in accordance with aspects of the present disclosure. The device1105may be an example of or include the components of a device905as described herein. The device1105may include components for bi-directional data communications including components for transmitting and receiving communications, such as a federated API manager1120, an I/O controller1110, a database controller1115, a memory1125, a processor1130, and a database1135. These components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more buses (e.g., a bus1140).

The I/O controller1110may manage input signals1145and output signals1150for the device1105. The I/O controller1110may also manage peripherals not integrated into the device1105. In some cases, the I/O controller1110may represent a physical connection or port to an external peripheral. In some cases, the I/O controller1110may utilize an operating system such as iOS®, ANDROID®, MS-DOS®, MS-WINDOWS®, OS/2®, UNIX®, LINUX®, or another known operating system. In other cases, the I/O controller1110may represent or interact with a modem, a keyboard, a mouse, a touchscreen, or a similar device. In some cases, the I/O controller1110may be implemented as part of a processor1130. In some examples, a user may interact with the device1105via the I/O controller1110or via hardware components controlled by the I/O controller1110.

The database controller1115may manage data storage and processing in a database1135. In some cases, a user may interact with the database controller1115. In other cases, the database controller1115may operate automatically without user interaction. The database1135may be an example of a single database, a distributed database, multiple distributed databases, a data store, a data lake, or an emergency backup database.

Memory1125may include random-access memory (RAM) and ROM. The memory1125may store computer-readable, computer-executable software including instructions that, when executed, cause the processor1130to perform various functions described herein. In some cases, the memory1125may contain, among other things, a BIOS which may control basic hardware or software operation such as the interaction with peripheral components or devices.

The processor1130may include an intelligent hardware device, (e.g., a general-purpose processor, a DSP, a CPU, a microcontroller, an ASIC, a field-programmable gate array (FPGA), a programmable logic device, a discrete gate or transistor logic component, a discrete hardware component, or any combination thereof). In some cases, the processor1130may be configured to operate a memory array using a memory controller. In other cases, a memory controller may be integrated into the processor1130. The processor1130may be configured to execute computer-readable instructions stored in a memory1125to perform various functions (e.g., functions or tasks supporting feature based application programming interface federation).

The federated API manager1120may support generating a federated API schema by a federated API manager in accordance with examples as disclosed herein. For example, the federated API manager1120may be configured as or otherwise support a means for receiving, via a user interface of the federated API manager, first user input indicating a first source API and a second source API for generating a federated API, wherein the first source API and the second source API each comprise one or more features for data processing. The federated API manager1120may be configured as or otherwise support a means for identifying, by the federated API manager, elements forming one or more patterns from the one or more features of the first source API and the one or more features of the second source API based at least in part on one or more federation protocols. The federated API manager1120may be configured as or otherwise support a means for identifying, by the federated API manager, one or more federated operations based at least in part on the identified one or more elements and one or more federated operation rules. The federated API manager1120may be configured as or otherwise support a means for generating, by the federated API manager, the federated API schema basing at least in part on the one or more federated operation rules, the federated API schema exposing the one or more federated operations.

By including or configuring the federated API manager1120in accordance with examples as described herein, the device1105may support techniques for improved user experience related to reduced processing, more efficient utilization of data processing resources, improved coordination between devices, or improved utilization of processing capability.

FIG.12shows a flowchart illustrating a method1200that supports feature based application programming interface federation in accordance with aspects of the present disclosure. The operations of the method1200may be implemented by an application server or its components as described herein. For example, the operations of the method1200may be performed by an application server as described with reference toFIG.1through11. In some examples, an application server may execute a set of instructions to control the functional elements of the application server to perform the described functions. Additionally or alternatively, the application server may perform aspects of the described functions using special-purpose hardware.

At1205, the method may include receiving, via a user interface of the federated API manager, first user input indicating a first source API and a second source API for generating a federated API, wherein the first source API and the second source API each comprise one or more features for data processing. The operations of1205may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of1205may be performed by a user input component1025as described with reference toFIG.10.

At1210, the method may include identifying, by the federated API manager, elements forming one or more patterns from the one or more features of the first source API and the one or more features of the second source API based at least in part on one or more federation protocols. The operations of1210may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of1210may be performed by a pattern recognition component1030as described with reference toFIG.10.

At1215, the method may include identifying, by the federated API manager, one or more federated operations based at least in part on the identified one or more elements and one or more federated operation rules. The operations of1215may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of1215may be performed by a federated operation component1035as described with reference toFIG.10.

At1220, the method may include generating, by the federated API manager, the federated API schema based at least in part on the one or more federated operation rules, the federated API schema exposing the one or more federated operations. The operations of1220may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of1220may be performed by a federated schema generation component1040as described with reference toFIG.10.

FIG.13shows a flowchart illustrating a method1300that supports feature based application programming interface federation in accordance with aspects of the present disclosure. The operations of the method1300may be implemented by an application server or its components as described herein. For example, the operations of the method1300may be performed by an application server as described with reference toFIGS.1through11. In some examples, an application server may execute a set of instructions to control the functional elements of the application server to perform the described functions. Additionally or alternatively, the application server may perform aspects of the described functions using special-purpose hardware.

At1305, the method may include receiving, via a user interface of the federated API manager, first user input indicating a first source API and a second source API for generating a federated API, wherein the first source API and the second source API each comprise one or more features for data processing. The operations of1305may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of1305may be performed by a user input component1025as described with reference toFIG.10.

At1310, the method may include identifying, by the federated API manager, elements forming one or more patterns from the one or more features of the first source API and the one or more features of the second source API based at least in part on one or more federation protocols. The operations of1310may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of1310may be performed by a pattern recognition component1030as described with reference toFIG.10.

At1315, the method may include identifying that a first element of the first source API and a first element of the second source API are compatible elements. The operations of1315may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of1315may be performed by a pattern recognition component1030as described with reference toFIG.10.

At1320, the method may include identifying, by the federated API manager, one or more federated operations based at least in part on the identified one or more elements and one or more federated operation rules. The operations of1320may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of1320may be performed by a federated operation component1035as described with reference toFIG.10.

At1325, the method may include generating, by the federated API manager, the federated API schema based at least in part on the one or more federated operation rules, the federated API schema exposing the one or more federated operations. The operations of1325may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of1325may be performed by a federated schema generation component1040as described with reference toFIG.10.

FIG.14shows a flowchart illustrating a method1400that supports feature based application programming interface federation in accordance with aspects of the present disclosure. The operations of the method1400may be implemented by an application server or its components as described herein. For example, the operations of the method1400may be performed by an application server as described with reference toFIGS.1through11. In some examples, an application server may execute a set of instructions to control the functional elements of the application server to perform the described functions. Additionally or alternatively, the application server may perform aspects of the described functions using special-purpose hardware.

At1405, the method may include receiving, via a user interface of the federated API manager, first user input indicating a first source API and a second source API for generating a federated API, wherein the first source API and the second source API each comprise one or more features for data processing. The operations of1405may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of1405may be performed by a user input component1025as described with reference toFIG.10.

At1410, the method may include identifying, by the federated API manager, elements forming one or more patterns from the one or more features of the first source API and the one or more features of the second source API based at least in part on one or more federation protocols. The operations of1410may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of1410may be performed by a pattern recognition component1030as described with reference toFIG.10.

At1415, the method may include identifying, by the federated API manager, one or more federated operations based at least in part on the identified one or more elements and one or more federated operation rules. The operations of1415may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of1415may be performed by a federated operation component1035as described with reference toFIG.10.

At1420, the method may include generating, by the federated API manager, the federated API schema based at least in part on the one or more federated operation rules, the federated API schema exposing the one or more federated operations. The operations of1420may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of1420may be performed by a federated schema generation component1040as described with reference toFIG.10.

At1425, the method may include identifying, by the federated API manager, one or more federation errors arising in the federated API schema. The operations of1425may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of1425may be performed by a conflict resolution component1045as described with reference toFIG.10.

At1430, the method may include performing a conflict resolution operation to resolve at least one of the one or more federation errors. In some examples, the conflict resolution operation may comprise renaming an element, renaming a sub-element of an element, hiding an element, hiding a sub-element, or any combination thereof. The operations of1430may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of1430may be performed by a conflict resolution component1045as described with reference toFIG.10.

A method for generating a federated API schema by a federated API manager is described. The method may include receiving, via a user interface of the federated API manager, first user input indicating a first source API and a second source API for generating a federated API, wherein the first source API and the second source API each comprise one or more features for data processing, identifying, by the federated API manager, elements forming one or more patterns from the one or more features of the first source API and the one or more features of the second source API based at least in part on one or more federation protocols, identifying, by the federated API manager, one or more federated operations based at least in part on the identified one or more elements and one or more federated operation rules, and generating, by the federated API manager, the federated API schema based at least in part on the one or more federated operation rules, the federated API schema exposing the one or more federated operations.

An apparatus for generating a federated API schema by a federated API manager is described. The apparatus may include a processor, memory coupled with the processor, and instructions stored in the memory. The instructions may be executable by the processor to cause the apparatus to receive, via a user interface of the federated API manager, first user input indicating a first source API and a second source API for generating a federated API, wherein the first source API and the second source API each comprise one or more features for data processing, identify, by the federated API manager, elements forming one or more patterns from the one or more features of the first source API and the one or more features of the second source API based at least in part on one or more federation protocols, identify, by the federated API manager, one or more federated operations based at least in part on the identified one or more elements and one or more federated operation rules, and generating, by the federated API manager, the federated API schema based at least in part one the one or more federated operation rules, the federated API schema exposing the one or more federated operations.

Another apparatus for generating a federated API schema by a federated API manager is described. The apparatus may include means for receiving, via a user interface of the federated API manager, first user input indicating a first source API and a second source API for generating a federated API, wherein the first source API and the second source API each comprise one or more features for data processing, means for identifying, by the federated API manager, elements forming one or more patterns from the one or more features of the first source API and the one or more features of the second source API based at least in part on one or more federation protocols, means for identifying, by the federated API manager, one or more federated operations based at least in part on the identified one or more elements and one or more federated operation rules, and means for generating, by the federated API manager, the federated API schema based at least in part on the one or more federated operation rules, the federated API schema exposing the one or more federated operations.

A non-transitory computer-readable medium storing code for generating a federated API schema by a federated API manager is described. The code may include instructions executable by a processor to receive, via a user interface of the federated API manager, first user input indicating a first source API and a second source API for generating a federated API, wherein the first source API and the second source API each comprise one or more features for data processing, identify, by the federated API manager, elements forming one or more patterns from the one or more features of the first source API and the one or more features of the second source API based at least in part on one or more federation protocols, identify, by the federated API manager, one or more federated operations based at least in part on the identified one or more elements and one or more federated operation rules, and generating, by the federated API manager, the federated API schema based at least in part one the one or more federated operation rules, the federated API schema exposing the one or more federated operations.

In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, identifying, by the federated API manager, elements forming one or more patterns may include operations, features, means, or instructions for identifying that a first element of the first source API and a first element of the second source API may be compatible elements.

In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, identifying that the first element of the first source API and the first element of the second source API may be compatible elements may include operations, features, means, or instructions for identifying that the first element of the first source API and the first element of the second source API each comprise a compatible element identifier.

In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, generating the federated API schema may include operations, features, means, or instructions for generating a federated element comprising the union of a set of sub-elements of the first element of the first source API and a set of sub-elements of the first element of the second source API.

In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, identifying that the first element of the first source API and the first element of the second source API may be compatible elements may include operations, features, means, or instructions for identifying that the first element of the first source API and the first element of the second source API each comprise a compatible data type.

In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, identifying that the first element of the first source API and the first element of the second source API may be compatible elements may include operations, features, means, or instructions for identifying that the first element of the first source API and the first element of the second source API each comprise a compatible dataset instance identifier.

In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, generating the federated API schema may include operations, features, means, or instructions for generating a federated element comprising the union of a set of sub-elements of the first element of the first source API and a set of sub-elements of the first element of the second source API.

In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, identifying that the first element of the first source API and the first element of the second source API may be compatible elements may include operations, features, means, or instructions for identifying that the first element of the first source API and the first element of the second source API each comprise a compatible lookup field associated with the compatible dataset instance identifier.

In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, identifying that the first element of the first source API and the first element of the second source API may be compatible elements may include operations, features, means, or instructions for identifying that the first element of the first source API comprises a reference that may be compatible with the first element of the second source API.

In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, generating the federated API schema may include operations, features, means, or instructions for replacing an operation for retrieval of the first element of the first source API with an operation for retrieval of the first element of the second source API.

Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for identifying, by the federated API manager, one or more federation errors arising in the federated API schema and performing a conflict resolution operation to resolve at least one of the one or more federation errors.

In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, the conflict resolution operation comprises renaming an element, renaming a sub-element of an element, hiding an element, hiding a sub-element, or any combination thereof.

Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for determining whether a schema of the first source API or the second source API violates the one or more federation operation rules.

Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for generating the federated API schema may be further based at least in part on the one or more federated operations.