Integration - Demystifying API

There is lot of buzz around API's (application programming interfaces) with discussions focusing on API strategy, API maturity, API economy, API monetization, API management, hybrid API, low code API, bulk API, streaming API, and the list goes on. As the list grows on, mapping these against your organizations need becomes very important. An API can be exposed by a monolith or a microservice or a macro-service, so its very important to understand that the API is one of many methods of communication between various components / systems. More and more businesses are adopting API based architecture as it allows them to share and distributed content / data much easily than done ever before and this trend will continue.

Whether you choose an API based architecture or not, remember 3 key recommendations, always build your integration system as a product, there is no one size fit all, and finally your architecture should be implementable & your implementation should be supportable.

API Journey

Currently, the term API is most commonly used term for web API's. In the past this term was more commonly used for the entry points to software libraries/frameworks, computer operating systems API's, etc.

Web API's too have a long journey and my experience of it started from the time when web API's were exposed using Java Servlets i.e. server side web API. Then there was time when XML-RPC was commonly used way to implement web API. Then came SOAP API's which became foundation for service oriented architecture (SOA). And now a days we have REST API's which are more focused on web resources hence the term resource oriented architecture (ROA). REST architectural style is blurring the lines between actual software and the architectural principles behind it.

Irrespective of this journey, primary reason for existence of an API is/was to create an execution/entry point to a system/library/framework for a business function/data/algorithm, which then allows 2 software systems to work together in both B2B or EAI scenarios. This is mainly done by exposing resources / services of a monolith or micro-service or macro-service for real time or near real time consumption in primarily request/response approach (others like bulk & streaming API's have specific use cases), implemented over HTTP/s protocol.

API Building Blocks

API's can be used for variety of purposes whether its exposing an algorithm as an API, providing access to data, calling API's within a module or across different modules of an application, within an application or across applications within your organizations boundaries, within organization or across multiple organizations, within specialized developer community or across community developers, and so on. Each of these use cases require a different strategy when it comes to type, purpose, delivery mechanism and management.

There are 3 key aspects of an API implementation and all the jargons you will hear are mainly related to one of these areas

• Business function / Data / algorithms: Behind this API, there may be a monolith or a microservice or a macro-service but core of it is need to provide access to a business function, data or an algorithm
• Type, purpose and delivery/execution mechanism: These are data transmission & execution modalities of an API whether its SOAP/REST/BULK/Streaming API's and/or execution within/across module/application/organization. This also includes runtime management of an API including security, monitoring, synchronous vs asynchronous processing etc
• Management: This should be seen in perspective of design time management of an API. This covers everything which is not mandatory but beneficial function for a successful API implementation such as management, discovery, monetization etc

API implementation benefits

It is important to understand that API's mainly impact transport layer so use of an API will not magically resolve business process issues however it can definitely facilitate forward looking application design which streamline business processes by making access to data easier. Some of the key benefits of an API based design are

• Efficiency: API's increase efficiency of integration between 2 systems / applications / modules / layers. Accessing new content / service / resource becomes easy and it yields better results
• Collaboration: API's allow easy collaboration between multiple resources / services to create new functionality. Encourages community developers and makes it easy to use exposed functionality / algorithms to create new business functions
• Automation: As business functions / algorithms are exposed through an API, it can facilitate automation of business processes, automation of support function, integration of AI / ML etc
• Reduced time to market: API based design supports higher reusability of built business functions and algorithms. They are also easy to scale up and down then any other method of allowing access to data
• Bridge the technology gap: APIs are able to bridge the gap between legacy systems and new technologies, and ensure they work together in harmony

API Implementation Challenges/Drawbacks

API implementation has its own limitation, challenges & drawbacks. There are some important issues which are solved by API's but its not fit for all of your integration needs. There are ways to overcome these limitations, challenges and drawback's however cost of it may become prohibitory

• Security Risk: Biggest benefit of an API is that it makes access to data easier and quicker, which means if your API's are not properly secured they will expose vital data to hackers to exploit. Securing your API's comes with a cost and they must be on top of your priority list for resources to be secured. It is all the more important for REST API based implementation because they do not have security features like WS-security of SOAP based implementation
• Tight Coupling: 2 systems which are connected through API's would become dependent on availability, stability & quality of connected system unless providers are built to process API's asynchronously or act more like store & forward
• Lack of state: This is primarily true in case of REST API's where state must be maintained by the client, which make client complex and prone to issues
• Size of Data: API's need to have quick execution to provide intended benefits. When large amount of data needs to be processed in a single call then API implementation does not bring intended benefit and would require much higher capacity to process large loads
• Costlier in long run: It is important to understand that API driven solution requires you to scale up and down depending on your business needs. As use of your API's will grow, so that cost of scaling them to support larger execution count. The capacity and cost of your environment would be decided by concurrency, throughput & availability needs

Conclusion

API is a powerful tool and it is sure to speed up time to market for your business functions / algorithms, grow your organizations reach, give easy access to data, make automation easier, support easy functionality access for mobile apps development and so much more. API based architecture is one of the most important digital transformation step an organization can take, which will unlock power of data by making it easily accessible.

In the end, make sure to focus on 2 important aspects, first is to select the API that works for your organizations specific business needs and second is to make sure that you understand how to effectively use it.