In the first blog post of this series, we described how Anypoint DataGraph relates to API-led connectivity. In this post, we present three approaches on how to consume APIs:
- Application directly calls System APIs
- Application calls dedicated Experience API
- Application calls DataGraph endpoint
These approaches differ in the location of integration logic like filter, sort, join, and merge operations and the amount of data that needs to be moved between client and server. In this blog we will explore these three approaches:
#1 Application directly calls System APIs
In this approach, the client is responsible for calling the System APIs and integrating the results.
To illustrate the different approaches, the following example is used: A mobile application requires order and customer data. This data is spread over several systems. Customer data is provided by SAP and Salesforce; order data by an eCommerce solution. Every system exposes the data via a System API. In this example, the mobile application calls the REST APIs SAP customers, Salesforce customers, and Orders over the internet as depicted in the figure below.
API consumer directly calls System APIs
As all the integration logic sits on client-side operations like joining, merging, and sorting has to be coded. Also reducing the results delivered by potentially verbose APIs is done on the client-side; e.g. filtering and selecting relevant data fields. This implies that more data is transferred over the internet than necessary for the use case.
#2 Application calls dedicated Experience API
This approach leverages the API-led connectivity methodology with APIs categorized in three layers. Goal of this approach is to:
- Speed up delivery and enhance efficiency by making APIs reusable
- Drive maintainability by isolating changes
Instead of putting all integration logic into the client, the logic is distributed over Process and Experience APIs. In our example, a Customers Process API merges the customer data from SAP and Salesforce providing a holistic view on customer data. An Order History Process API joins the order data from the eCommerce system with the customer data. Both APIs are designed channel-agnostic to maximize their reusability. The figure below depicts the relationships between the APIs.
API consumer calls dedicated Experience API
Tailoring the Order History Process API to the mobile channel is done in a dedicated Mobile Experience API. It provides exactly the data that the mobile application requires. Besides calling the Mobile Experience API no integration logic is required on the consumer side.
#3 Application calls DataGraph endpoint
This approach leverages Anypoint DataGraph. The foundation is to define and maintain a Unified Schema of available APIs. This allows exposing a DataGraph endpoint that can respond to GraphQL requests from any application.
In our example, the client mobile application sends a GraphQL request to the DataGraph endpoint that precisely describes the required data for the use case. Anypoint DataGraph then processes the request. It calls the required System APIs, merges and joins the results, and tailors the response as specified in the GraphQL request. Prerequisite is that the same IDs are used for entities at the System API level. To tailor the response, sorting and filtering capabilities are leveraged from the underlying APIs. The figure below depicts these interactions.
API consumer calls DataGraph endpoint
In this blog post, we presented three approaches to API consumption. In the next post, we will compare these approaches based on a selection of characteristics.
For more information on Anypoint DataGraph, watch our webinar.
