API-First

“API-First” means using APIs as the preferred method of accessing applications,?platforms, and data.?The API-First strategy involves creating layers of APIs that significantly improve over other integration methods, such as native adapters. Delivering API-First involves viewing APIs as?products?and adopting a contract-first approach to service design and delivery.

APIs are a good option for standardizing interfaces and simplifying integrations?because they improve accessibility to services and are central to modern service delivery. However, the techniques of successful API-first integration implementations are not universally understood.?The proliferation of APIs,?through increased adoption of SaaS?and the rise of microservices development practices, has only exacerbated?the problem?by creating the risk of chaotic, unmanaged API usage.

IT leaders looking to succeed with API-first integration should:

》Separate out their integration and API strategies.

》Focus their integration strategy on connecting systems, applications and services, instead of creating APIs for current and future integrations.

》Focus their API strategy on establishing consistent design, governance and security standards.

Given how important APIs have become for organizations undergoing digital transformations, having a separate function focusing on API strategy is a must.

Separate Out Your?API Strategy and Your Integration Strategy

For decades, the prevailing advice was that the integration team, in the form of an integration competency center, should also be responsible for the creation of APIs. The reality, however, is very different.

Application integration is making independently designed applications, data sources and services work together. In this scenario, the endpoints should already exist and will have interfaces defined already. Today, the majority of these interfaces are API-based, but this is not always the case.

There are three established patterns for integration:

》Data consistency

》Multistep process

》Composite service

The composite service pattern is shown alongside the two other integration patterns.

If we look at these three?patterns, we can see that the first two patterns are the ones that most closely match a definition of integration.?The third pattern of composite service is really more of a use case for integration technology with the outcome being an API. This composition can also be achieved using a variety of technologies like data visualization, data fabrics, code-based approaches, robotic process automation (RPA) technology and low-code application platforms (LCAPs). Owing to the diversity of technologies that could potentially be used to create composite services, the delivery of said composite services should not, by default, be the responsibility of the integration team.

Managing the life cycle of APIs using API management solutions is an integral part of the hybrid integration capability framework (HICF), also known as a hybrid integration platform (HIP).?It is recommended that the HICF is overseen by an integration strategy empowerment team (ISET). However, there remain challenges around the proliferation of APIs across organizations and the delivery of APIs to enable composition using diverse technologies. This requires an effective API strategy driven by an API platform team, to enforce consistency and quality in API development.

The API platform team can consist of API product managers from various lines of business (LOBs), software engineers, and, optionally, subject matter experts across various domains like personal information compliance, performance engineering and security. In addition to establishing governance around API delivery, the API platform team can also work with various Line Of Business (LOB) to identify the potential need for new APIs, and candidates for reuse.?The API platform team will eventually help in resolving the ownership dilemma brought about as a result of APIs being developed pervasively across an organization. This team can establish good governance around APIs by acting as a focal point from which consistent standards for API delivery emerge.

Focus The Integration Strategy on Connecting Endpoints and Not Building Them

An API-first approach toward integration means using APIs to connect to a system, service or?application — provided that the APIs are well-defined and documented, and there are integration technologies to support the use of APIs to enable integration.?

In Figure above, the integration platform is connecting to cloud and on-premises applications, events and data sources using a mixture of APIs and other mechanisms such as native connectors, database connectors or via message queues.?Achieving this integration outcome does not require publishing new APIs on top of existing connectivity mechanisms using the integration platform.

In the absence of an API or scenarios where using an API for connection may not be ideal, integration between systems can also be facilitated efficiently using a variety of methods. These include files, event brokers, JDBC/ODBC connectors or custom code for databases and user interfaces for RPA use cases.?Being API-first does not mean being API-only. There will be scenarios where other interface standards may be more appropriate, such as ODBC/JDBC, FTP, AMQP and MQTT.

Integration, in its most basic form, is about connecting two disparate endpoints to enable communication between them.?Organizations should be wary of adding the complexity of delivering interfaces on top of each of these endpoints, even when your existing integration technologies can connect them efficiently. Doing so will only lead to the integration team’s time and effort being spent applying governance and security policies to these interfaces, without the guarantee of any future reuse.

APIs can be implemented using a variety of styles including REST, GraphQL, event-based APIs (for example, webhooks) and streaming.?If there is a requirement to access data via new applications being developed or from partners, then publishing a new API that can be utilized as part of the integration process is warranted.?This scenario is shown in Figure below. In this scenario, APIs are published for consumption via an API gateway.?The APIs may be published in an API portal, which could be provided by the?API gateway provider, or may be separate.

APIs carry with them an inherent need for comprehensive governance separate from the underlying implementation and the integration process they are a part of. Therefore, the creation of a new API should not, by default, be the responsibility of the integration team.?Instead, it should be delivered by either the application team or the API platform team in accordance with the development guidelines and governance standards laid out by the API platform team.

Ensure The APIs Are Consistent, Discoverable and Secure

An API portal and API gateway are the two main components of API management. However, not all integrations require a published API provided they make use of other mechanisms through the integration platform. Such mechanisms include the use of message queues or native adapters. Similarly, not all integrations require an API to be created.?The only instance in which an API should be created is where an integration is likely to be reused via that API.

Whether the choice is to create APIs indiscriminately or methodically, tracking the created APIs and protecting them from insider and outsider threats will be critical. It is imperative that the APIs created for internal or external purposes are published to the API gateway of choice, where necessary authentication and authorization policies can be applied.

Published APIs should also be added to an API catalog — and where they are intended for reuse, they should be published in an API portal and supplemented with standardized documentation to ensure your APIs are discoverable. APIs teams should collaborate with their security teams to ensure they discover their APIs before attackers do.?They should conduct penetration testing on the APIs regularly,?and implement reusable security policies to make the APIs bulletproof from a security standpoint.

The API platform team is responsible for fostering a practice of consistent delivery of APIs that are developed across the organization. This generally entail:

》Ensuring technical consistency of APIs by adopting an API style guide.

》Establishing standard and reusable security and runtime policies.

》Creating a community of practice in line with API best practices.

》Ensuring appropriate documentation for published APIs.

》Managing the API portal so that APIs can also be consumed in a consistent way.

API mediation helps manage communication between API consumers who interact with outer APIs and service producers who provide inner APIs. The technology most often used for API mediation is an API?gateway, frequently provided as part of an API management platform.?API management platforms:

》Help service providers to manage the life cycle of their APIs.

》Provide developer access to outer APIs via a portal.

》Map?outer APIs to inner APIs (see Figure 6).

》Allow for the creation and management of policies to be applied to each mediation.

API gateways are not an integration technology, but an enabler of integration. API gateways do the heavy lifting in terms of nonfunctional requirements like traffic management, load balancing, routing (mapping outer APIs to inner APIs) and enforcing security policies. If the mapping of the outer APIs to the inner APIs becomes complex and tends toward embedding business logic in the gateway (by calling more than one inner API or performing look-ups), then in reality the teams are creating a composite service rather than an outer API.

This composite service should not be implemented within the API gateway, as this will harm the performance of the API gateway and overload it with integration logic. Who have implemented composite services in their API gateways often express their concerns over performance — with some reporting several orders of magnitude worse performance than they were expecting. This results in much higher costs due to having to scale out the technology. Manageability is also a concern.

Adding extra APIs along the integration process, under the guise of reuse, can dramatically impact the implementation time for the integration process. Doing so introduces unnecessary complexity and increased latency into the implementation process.?API-first means thinking about the consumers of the API, and if the only consumer is to be an integration platform then creating new APIs is unnecessary.

Treat reuse as one benefit of API-first integration, but not the main benefit. For APIs and integrations, avoid the trap of focusing only on reuse as a metric. Doing so can cause unwanted behaviors such as forcing developers to reuse APIs that are not suitable for their needs. Reuse is just one of a broad set of business metrics to measure.

From Gartner's article "How to Successfully Implement API-First Integration"