API Led Connectivity – Introduction | Sovereign Solutions

API Led Connectivity – Introduction

Introduction

An application programming interface (API) is an  interface or communication protocol between a client and a server intended to simplify the building of client-side software. It has been described as a “contract” between the client and the server, such that if the client makes a request in a specific format, it will always get a response in a specific format or initiate a defined action.

In this modern era of digital transformation, API’s are no longer considered just to be the technical interface on top of a database. Nowadays, API-led connectivity is the new way to communicate with customers and partners through API.

The Need of API Led Connectivity

The technologies that enterprises are using to engage with customers or partners are advancing day by day and the role of API-led connectivity seems to be an indispensable integration strategy. Technologies like IoT, SaaS, Cloud technologies and APIs are providing more powerful tools to bring the best out of business like generating more revenue, understanding the customer better, etc. So, in order to do so more powerfully, APIs are needed.

Mule recommends a new approach called API-Led connectivity, that connects data to applications through a series of reusable and purposeful modern APIs that are each developed to play a specific role – unlock data from systems, compose data into processes, and/or deliver an experience. This approach essentially has 3 layers as explained below with pictorial representation:

Data/Systems APIs

Unlock data from backend systems like database, Workday, SAP, Salesforce, file systems, Siebel, Service Now, etc., by putting APIs in front of those applications. These form a “Data/System API” layer that provides consistent, managed, and secure access to the backend systems.

Below are the characteristics of a Data/System APIs.

  1. Data APIs are micro services and decomposed as granular as possible.
  2. Data API’s are owned by the team closure to data layer.
  3. No frequent changes, scheduled quarterly basis.
  4. Data System API’s are mainly consumed by Process APIs.

Process APIs

Build on the Data/System APIs by combining and streamlining data from multiple sources into a process specific API (breaking down application siloes). These “process APIs” take core assets and combine them with some business logic to create a higher level of value. Importantly, these higher-level objects are now useful assets that can be further reused, so they should also be APIs themselves. Below are the characteristics of a Process APIs.

  1. API’s built for each modular business process
  2. Owner by team with business process knowledge. Developed by specific line of business (LOB) team.
  3. Does transformation, aggregation, enrichment, pagination for performance etc.
  4. Changes to process API’s are controlled and limited to quarterly basis.
  5. Consumed mostly by Experience or Proxy API and end consumers if no further transformation required.

Experience APIs

Finally, “experience APIs” are designed specifically for consumption by a specific end-user application or device with specific permissions. These APIs allow application developers to quickly innovate on projects by consuming the underlying assets without having to know how the data got there. In fact, if anything changes to any of the systems of processes underneath, it shouldn’t require any changes to the app itself. Below are the characteristics of Experience APIs.

  1. API’s built for specific consuming application needs with data filters etc.
  2. Owned by consuming application and may be developed initially by specific data/system’s team.
  3. Supports data format (JSON vs XML etc.) transformation and Protocol transformation.
  4. Changes can be as frequent as the consuming application needs.
  • Proxy APIs: Proxy API’s are the proxy to backend API’s OR existing services hosted in another platform with no custom coding and for management purposes. No custom coding is required for this API and the API manager generates the proxy code if they are http(s) based implementation. Proxies can be created for non-http(s) based application as well, but needs an API development and will be categorized in Experience API.

Title: API Development Principles

A number of API development best practices have been created in order to facilitate the development of the most valuable and consumable APIs. It is a good idea to adopt some, if not all of those best practices, in order to create the best chance of API success in your organization:

  • Create Expectations: When working with developers, it is critical to inform them of what is expected, when it should be delivered, and what pain points are to be solved by the API functionality.
  • Service Messaging: With the goal of creating new products and services, or transforming existing products and services, it is paramount to make sure those services and the APIs that provide access to them align with business goals and lead to services that deliver value.
  • Case Studies: It’s key to back up assumptions with viable case studies that illustrate the improvements that API adoption brings to the table.
  • Documentation and Support: Make sure the proper tools are in place for the dev team to document their progress, as well as address change management, along with exposing the capabilities of an API. Ensure that support for the both the development and implementation team is readily available.
  • SDKs and Libraries: Provide the necessary resources to the development team to speed services development and implementation by offering resources that contain reusable code and processes.
  • APIs must be treated as products to maximize their successful uptake
    • Consistency across operations and APIs
    • Naming, usage patterns
    • Documentation
    • SDKs
    • Live sandbox environments for app onboarding
  • How can enterprises achieve the necessary level of quality and consistency for their APIs?
    • “Just enough governance” – define the content, rules and roles required to produce and expose enterprise-quality APIs
    • Automate what you can
    • Review what you can’t automate

Manage APIs like products and developers like customers

APIs and developers each follow a lifecycle with stages of maturity that require proper management. APIs need to be managed like products and developers need to be managed like customers. The right API management solution enables organizations to manage both lifecycles independently and successfully.

API Lifecycle management enables API owners to:

  • Align API programs with business objectives, simplify API creation and publishing, manage and govern changes to meet internal policies and regulatory requirements, control and communicate updates, monitor availability and measure performance.
  • Enables developers to discover new and updated APIs, register for access to APIs, leverage development tools, test client apps and collaborate with other developers.

Real Time Order Status and Order History

Following are the scenarios where this 3-layered approach may not be followed:

  1. Event based integrations where a change in one system needs to be published to another system.
  2. There is no orchestration, transformation or translation logic required.
  3. All consumers use same data format and has the same permission levels to the underlying APIs.

Let’s take an example where you have to provide real-time order status and order history for sales teams to engage with customers in some consumer application. With customers data in SAP and Salesforce and Orders data in SAP, below is how you would implement the use case using API-led approach.

  • Systems APIs: You unlock data from SAP and Salesforce systems by putting canonical APIs in front of them. These form a “System API” layer, which provides consistent, managed, and secure access to backend systems.
  • Process APIs: Then you can build on the system APIs by combining and streamlining customer data from multiple sources into a “customers” API (breaking down application siloes). Then mapping customers and orders to create order status and order history APIs. These canonical “process APIs” take core assets and combine them with some business logic to create a higher level of value. Importantly, these higher-level objects are now useful assets that can be further reused, so they should also be APIs themselves.

Experience APIs: Finally, an API is built that brings together the order status and history, delivering the data specifically needed by the consumer app. These are “experience APIs” that are designed specifically for consumption by a specific end-user app or device. These APIs allow app developers to quickly innovate on projects by consuming the underlying assets without having to know how the data got there. In fact, if anything changes to any of the systems of processes underneath, it shouldn’t require any changes to the app itself.


Talk to our experts now to learn how Sovereign Solutions can help your organization meet its business objectives

*This content is being provided for informational and educational purposes, and should not be regarded as a specific recommendation for your situation.

Comments