APIFirst

API First Design

API is the acronym for Application Programming Interface, which is a software intermediary that allows two applications to talk to each other. For example, a Customer Relationship Management (CRM) system might need to communicate with the Billing system to access product catalog information. This communication would be done via API calls. It should be clear from this example, that a rich set of APIs is essential to integrate multiple Enterprise Resource Planning (ERP) and back office systems. A true software platform needs to be architected using API first principles in order to facilitate frictionless integrations between multiple systems.

API First Approach

API First design is based on the notion that the API is the primary building block of the application. In other words, for any given deployment project, your APIs are handled as “fist-class citizens” to say the least.


All product functionality is exposed via an API. This also means that if you can do something via the user interface, you will be able to do the same through the API. A true API first design really starts with the API as the starting point and developing APIs that are consistent and reusable, which can be accomplished by producing an API description language, to establish a contract for how the API is presumed to behave. In addition, The API should be built keeping in mind the requirements of both internal and external clients.

Benefits of an API-First Approach

An API-first approach to building products has many underlining benefits in which organizations can take advantage of. First, development teams have the opportunity to work in parallel, as the API-first approach consists of establishing a contract. With an established contract between services, which is followed by teams across an organization, it allows teams to work on multiple APIs at the same time. No updates to an API are required to be released before moving on to the next API.


Second, an API-first approach can reduce costs of developing new apps. Development teams no longer have to start from scratch, which is time consuming, as APIs and codes can be reused for many different future projects. The API-first design allows for problems and discrepancies to be solved prior to any code being written, which in turn eliminates complications when its time to integrate APIs with applications.


Lastly, an API-first approach can increase the speed to market. The granular process of building an API can be automated by utilizing tools that allow you to import API definition files. In addition, API-first gives you the advantage of adding new service offering and technologies to applications without having to re-architecture the entire site.

Design Thinking with APIs

Companies that are designed focused spend a significant amount of time curating the user experience to ensure the resulting solution is easy to use and delights the end user. This includes among other things a big focus on user research, A/B testing, wire framing and prototyping to make sure no stone is left unturned in providing a seamless user experience.


In a similar fashion, an API first design goes through the same due diligence, except in this case the end user is the API developer. An API is one that is self descriptive - the end user ideally shouldn’t have to read endless amounts of documentation to figure out what your API does or how to use it. But having that structured documentation is invaluable for times when you need it.

 

API should not lag product functionality

A key priority in an API First Strategy is to ensure that the Functionality in the Product does not lag the underlying API. This is easy to achieve with an API first approach. The API becomes a first-class citizen of the product and product features are built on top of the underlying interfaces. This is very different from an API second approach, in which a REST or SOAP API may be bolted on after the fact. What tends to occur over time is that the API cannot keep up with feature development. When managing scope creep, companies will tend to de-prioritize API functionality over feature development resulting in an API set that is a pale shadow of the underlying product functionality.

API Diagnostic

Part of a good API first design is to ensure a sufficient amount of logging capabilities are provided in the platform that can aid in diagnostics and troubleshooting. Success and failure response codes along with the appropriate API metadata should be logged and accessible through the interface. The correct type of diagnostics can provide immense value in understanding and interpreting failure scenarios and the associated resolution options.

An Application vs A Platform

When thinking about components of your ERP and back office systems, you need to consider whether you are purchasing an application or a true platform. Each component of a back office system does not operate in isolation which is why systems that are designed as platforms allow for easier integration in a back office ecosystem. A billing system for example might be dependent on a CRM system for order information, while an accounting system might be dependent on the billing system for GL information. The integration and automation of often disparate back office systems continues to remain a big source of headache for most businesses.


LogiSense Billing has been envisioned as an API first platform. All product functionality is based on a rich set of APIs. A CRUD style RESTful interface exposes this functionality to internal and client facing applications to facilitate seamless integrations with other applications. A rich set of diagnostic and logging capability is exposed through the admin console to aid in auditing API calls. The system supports synchronous and asynchronous API processing along with the ability to chain multiple API methods in to single transactions.

 

About the author
Chris Brown

Chris Brown

Chris has over 20 years of experience in the telecommunications industry dealing with Fortune 2000 enterprises and service providers globally. As Senior Technology Fellow Chris interacts in the market and internally providing: technical leadership and vision, mentorship, and creative problem-solving. Chris is also our Director, Pre-Sales and Solutions Architecture, where he is responsible for a team that helps customers understand the technical value LogiSense can provide as well as guidance and industry consulting to ensure their business is prepared for success in rapidly changing markets. During his tenure at LogiSense, Chris has acted as a Senior Software Developer, Director of Technology, Director of Solutions and now Director of Pre-Sales and Solution Architecture. Chris holds a Bachelor of Science degree in Computer Science from the University Of Western Ontario.