Survey: APIs Broaden Appeal – From Integration To ‘Fundamental Building Blocks’ for Software

As APIs continue to play a strong role in integration, in 2019 APIs will also become ‘fundamental building blocks’ to enterprise software. This is the finding from a survey from Postman, an API development tools provider. IDN speaks with CEO Abhinav Asthana.

by Vance McCarthy

Tags: APIs, containers, developers, Postman, tools, survey,

Abhinav Asthana, Postman
Abhinav Asthana
CEO
postman


"We’re seeing a fundamental change, where APIs are not just for integration. APIs are driving all types of software innovation -- way beyond integration."

Enterprise Integration Summit
Integration Powers Digital Transformation for APIs, Apps, Data & Cloud
An Online Conference

As we head into 2019, a new survey reveals an expanding role for APIs in enterprise IT.

 

While APIs continue to play a strong role in integration – with both internal and external services and endpoints, APIs are also becoming a more strategic technology for baseline enterprise software development.  The trends are revealed in the survey released this fall by Postman, a provider of API development environment.

 

“We’re seeing that APIs are becoming fundamental building blocks for all sorts of enterprise software,” he said.  Further, as APIs become more crucial for building apps that are innovative, disruptive and quick-to-deploy, API collaboration will grow, Abhinav Asthana, Postman’s co-founder and CEO told IDN.  

 

The findings from the 2018 Postman Community Report (aka 2018 State of the API Survey) is available here. The study was distributed to the entire Postman community, which currently numbers nearly 5 million users of Postman, according to the company.

 

While APIs are already an essential part of software development for web, IoT, mobile and AI applications, more and more developers spend time using them daily. Further, APIs are gathering more attention among those developers who have not used them before. In specific, Postman’s surveys revealed these stats:

  • Nearly 2 in 3 API developers spend a quarter of their week working with APIs.
  • Almost a third of those (30%) spend more than half of their time with APIs.
  • Use of internal APIs (for internal integrations and data services) still makes up more than half of all API usage.
  • Use of “public APIs” and “private APIs” has grown to nearly 50% combined, up from last year.
  • Nearly half of API professionals are back-end developers.
  • Less than 20% of API professionals work in teams.

 

APIs Continue To Attract Integration, Software Developers

The survey finds that the API sector continues to mature, expand their purpose and recruit new developers, Asthana said.

 

“At the start, APIs were primarily seen as integration tooling. You would write your code first and then build an API because you had to give data to somebody else. If you needed to integrate, you knew you needed an API. Now we’re seeing a fundamental change, where APIs are not just for integration. APIs are driving all types of software innovation, way beyond integration,” he said.

 

This expansion in API use and API adopters comes with more as confidence increases in API patterns, security and documentation, the survey added.   That said, the surge in API adoption means there are many API newcomers – and that many are learning on the job, the survey also found.

 

Two related  findings from the survey paint the picture

  • Most API users have fewer than five years of experience.
  • 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 survey also offers a glimpse into the future of API-grounded software architectures. Among Postman developers

  • 43.5% are most interested in working with containers
  • 39% are most interested in working with serverless architecture

 

“As developers continue to gain interest in app architectures that use containers and serverless approaches, API tooling will also so prove valuable, as long as it is smarter, faster and can promote teamwork,” Asthana added. 

 

APIs a Key Foundation for ‘Modular Apps’ – Gateway to Microservices, Containers

When companies and developers move away from building big complex applications and move to using smaller, more modular apps APIs fit that move very well, Asthana explained. APIs fit so well, in fact, that now developers don’t simply wait until the end of the app process to build or define an API – but design with APIs from the start of a project. It’s a trend Asthana refers to as “API First.”

 

Postman Survey

“I think people have realized that there is a lot of value in doing API First, and that's why our survey found they're spending more time with API is in my opinion,” he said. “Developers already using APIs and looking to microservices are now asking ‘Why don’t we just compose our applications with API first? In the future I could just recompose more applications easier,’” he added.

 

In fact, with the growth of API First, the Postman survey documents the growth in API use cases.  “Whole new developer teams are being constructed around this [API First] idea. Teams of five to eight developers are being set up because they can build them more easily. That view is driving this new trend in APIs and makes total sense,” Asthana added.

 

Beyond simplicity and speed, APIs also offer something else: Ways to drive app innovation – without getting too complex about it.  

“We are seeing is that APIs make it very easy to compose applications that do more things,” Asthana said. “So if you are building an application, you can really pull in very powerful features very easily. So that helps you on the consumer side,” he noted. It’s these added benefits that are leading more companies to take an API-First approach to app design and development. 

 

Doing ‘API-First’ Properly Doesn’t Always Require Detailed Documentation   

Another eye-popping benefit from an API-First approach is an ability to cut down on – or even sidestep -- the need to write detailed documentation  -- or even set contracts.

 

Asthana explained it this way:

 

“In my view any API is the contract. So what you write out in a specification file is a representation of that real thing and it might not be complete because it's very hard for a single person or a single team to just document all observable behaviors of your system. The API is the real thing,” he said.

 

To make the point that how an API works in real life – and not on paper (documentation or contract),  Asthana put forth the following:

A common issue that happens is you build an application, let's say using node.js, and you forget to document like a 404 error. So it would actually spit out the default, you know node.js framework error. It will be seen in the wild whether you know it or not. And what happens is that as an API goes out, all the behaviors that the API exhibits become the real contract. 

Generally it's just a fundamentally hard exercise to document everything.  You're always trying to play catch-up in This is my contract and this is what the real API does and I think different teams do different things.

Whether you have the contract well-documented or not really doesn't matter. As API tooling levels-up, these things should be done for you. Your systems can build out the contract. I think they will give you that same outcome much more easily, rather than having humans go and write out five thousand contracts.

When that happens, you can do a cycle of improving that behavior --- all  based on how the API really works in the real world. In addition, you can make that iterative. That's where like versioning and other aspects come in.

Postman’s Drive To Increase Intelligence in API Tooling

This discussion points to Asthana’s view that API tooling is bringing in more intelligence and automation.

 

“Using smart capabilities in API tools will outperform developers who try to document too much or try to define a co0ntract too narrowly,” he said.  Developers are better off paying attention to precisely how APIs perform  ‘in the wild,’ he said,  With real data real API operations, defining contracts at the outset can prove  frustrating – if not inaccurate -- for both API producers and consumers. 

 

Asthana also shared another big API mistake – and it related to API versioning. 

 

“One of the most common mistakes I see development teams doing is they focus so much on that first version or so contract that they don't design the API for change. You should always think of your API in terms of how it will evolve.”

 

This focus on flexibility becomes a key consideration, Asthana told IDN, especially as newer app designs and technologies enter the picture.

“All microservices our APIs. But all APIs are not microservices,” he said. “There's a lot of debate about what a micro in a microservice is. So to me, a microservice ideally should have tight conceptual boundaries.”

 

“Another question: How big should a microservice be? That’s actually a big part of debate. Should we split a microservice into more microservices or should we combine other microservices which have very thin boundaries and assimilate them? I'm seeing that debate actually as a good thing. It helps your architecture evolved and have like tighter conceptual boundaries.

 

“Not all companies would be executing at the same level. in fact, that's what Postman is helping them do. Postman is a collaborative platform designed specifically for APIs,” he said.

While API developers began by working on their own (or with one data or app owner to make a connection), times are changing. Apps are more interconnected and use multiple services. Further, newer technologies, including microservices, containers and even serverless are coming into play.

 

In that context, APIs need to navigate multiple connections, way beyond a simple point-to-point architecture. 

 

“So problems can happen. If you see APIs as a network of machines talking to each other, that results in a certain kind of organizational architecture on top of it.” That meta-layer approach to APIs gives developers (and companies) options.

 

“Now you can go and say ‘I'm going to have a one-to-one mapping between my microservice and the team building that microservice. Or, I could structure my departments and they all have APIs to talk to each other. . . But this knowledge sharing around APIs and how to work together and agree on the rules for all these APIs becomes kind of a hard problem.”

 

“So at Postman, we basically have built this whole collaborative [Postman Workspace] to help developers transition a single user tool to a collaborative environment,” he said. “So if you're debugging an API, you do it together. If you're documenting an API, you can do it together. You can invite people who are in your organization, even if they don't have visibility into what your APIs look like, you can share knowledge with them to work together.”




back