Why startups should have an API-first approach: Shamasis Bhattacharya of Postman on how to manage API complexity

“We're living in an API-first world -- Let's start developing like it.”

This thought set the tone for the talk on ‘API First Development for Modern Organisations’ by Shamasis Bhattacharya of Postman, at the 2nd edition of YourStory's flagship tech event Future of Work in Bangalore. Shamasis’ 30-odd-minute long talk, to an audience comprising data scientists, product engineers, developers and entrepreneurs, highlighted how an API-first approach can help manage complexity of work in modern organisations, and why startups should have an API-first approach.

Building software in the digital dynamic

Application Programming Interfaces or APIs have come a long way in a short span of time. If you told developers in 2005 that they could make money off of an API, they'd laugh at you. The notion that you could build just a layer of software — just one functionality — and sell it as a product seemed insane. Today, as APIs take centrestage, we have seen organisations think about APIs in three distinct ways: APIs as services, APIs as interactions, and APIs as products.

The value of software in the digital age comes from how well it talks to other software. What enables this conversation? APIs. They connect the apps, data, and devices that must talk to each other in a connected world.

API-first, therefore, starts with the end in mind. And while traditional IT has focused on APIs as an afterthought or an inside-out approach, digital IT focuses on where value is being delivered to the customer—whether internal or external with an outside-in approach. In other words, API-first thinking happens when we build our software to be part of the broader conversation: the API ecosystem.

“As the digital ecosystem increases in complexity and scope,” said Shamasis, “the baseline expectation from companies follow suit. With the dynamism of digital, also comes need for speed and agility during survival stages. A competitive and crowded market landscape and the and the sheer scale of global scaling-up operations also adds to the complexity.”

APIs and the developer community

Already an essential part of software development for web, IoT, mobile and AI applications, API use continues to grow among developers, and their confidence in both API security and documentation has increased year over year. And most notably, while microservices remain the most exciting technology for API developers, containers and serverless architecture have emerged as the new favorites for this group. A 2018 survey by Postman revealed a diverse area of focus for the API development workforce:

• Nearly two in three API developers spend a quarter of their week working with APIs, and 30 percent of those spend more than half of their time with APIs.
• Usage of Public and Private APIs is nearly 50 percent, and has grown since last year, while internal APIs still make up slightly more than half of all usage.
• Most users have fewer than five years of experience, less than 20 percent work in teams and nearly half are back-end developers.
• The majority of API knowledge is gained on the job or from online resources, while published API documentation and online communities also contribute heavily.

The era of the API-first organisation

“Twilio is a great example of an API-only business,” said Shamasis as he spoke about API-first businesses. “Twilio virtualised traditional telecommunications infrastructure allowing developers to replicate any communications experience using APIs.”

“Some organisations adopt agile software development practices,” he added, “an API-first approach allows other companies to optimise their total development time. For example, Etsy switched to an API-first approach after facing the common challenge of implementing their logic twice.”

Another example of an API-first company is Netflix. Accounting for a large percentage of the total internet traffic, Netflix re-configured their API architecture to allow concurrency. In the process, they distributed their API development so that each client application team was capable of implementing and operating their own endpoints.

When API comes first

“With an API-first approach, instead of starting with code, you could start with design, planning, mocks, and tests,” Shamasis explained. This process is aligned with the popular agile software development principle of iterating rapidly and allows the team and any other stakeholders to weigh in on the proposed direction and functionality, early and often. Gathering feedback at this early stage allows you to make changes more easily before a lot of time and effort is sunk into the project. Using mocks or an API development environment makes the current state of the project more accessible to both technical and non-technical team members.

By also separating the design of the API from its implementation, the architect is constrained only by the data model and business logic. Your API can now evolve uncompromised by any existing user interface or legacy engineering frameworks.

He added, “Once the direction has been solidified, the design then serves as the contract that all teams can begin working towards in parallel, and only then does coding officially begin.”

The perks of going API first

Pausing to flesh out the API may delay valuable building time, but has several benefits that outweigh the delays. These include earlier validation, a clearer abstraction layer, decoupled dependencies, faster growth, and freedom from legacy constraints.

Shamasis Bhattacharya's mantra for battling complexities

Shamasis contended that it’s the API designer’s job to manage complexity by improving learnability and usability, and by reducing confusion. This doesn’t necessarily mean that complexity itself needs to be sacrificed. And when it comes to battling complexities, he recommends following the below:

• Crowdsourcing experience by building plugin models and marketplaces, and

• Streamlining communication and processes by creating independent autonomous teams.

What Postman has for the API-first universe.

Postman is used by 6 million developers and more than 200,000 companies to access 130 million APIs every month. Postman Collections are executable descriptions of an API and are the cornerstones of Postman’s built-in tools.

Postman Workspaces are a giant leap forward in API Collaboration. Changes made to a team workspace sync in real time so every team member is always working off of the most up-to-date version. Team admins can set permissions and manage contributors across multiple workspaces.

Postman’s built-in tools support every stage of the API lifecycle - faster and easier and without the chaos. They run requests, test, debug, create mock servers, monitor, run automated tests, and document your API with Postman’s powerful built-in tools.

Shamasis ended his talk by directing the audience to Postman’s engineering blog on Medium, where he said there would be more tools and detailed information on the Postman approach to APIs.