Key takeaways from the annual Postman and Smartbear reports
Every year, Postman surveys industry members to get a picture of the API industry — to understand who is working with APIs, how they are getting their work done, and where they see the industry going. More than 13,500 developers, testers, executives, and others took the 2020 survey and provided insights on everything from how they spend their time to what they see as the biggest issues and opportunities for APIs.
This year’s Smartbear survey contained 52 questions and collected a total of 3,536 responses. The primary audience for the survey were end users of the open source and commercial versions of the Swagger, SoapUI and ReadyAPI tools. The findings presented are based on the completed responses from over 1,500 developers, architects, QA professionals, operations engineers, and product leaders from more than 16 different industries globally.
In this article we will look at two annual State of the API reports, both respected within the industry, to gain insight into the following:
- What do users require of APIs?
- What are the obstacles to consuming APIs?
- What are the obstacles to producing APIs?
- What are the obstacles to producing API documentation?
The focus here is on respondents’ expectations and needs of APIs.
When respondents were asked in the Postman survey what factors are considered before integrating with an API, reliability was the most important factor, at 71.6%, followed closely by security, performance, and documentation, which all came in slightly less (but all above 70%).
In the Smartbear survey respondents were asked to list the top three most important characteristics that they need in an API. Ease of use (68%), accurate and detailed documentation (63%), and responsiveness / performance (47%) were the characteristics listed most by respondents.
Respondents’ indication of the importance of reliability and performance is no surprise. What stands out is the high level of importance assigned to documentation. The implication is that, without the availability of accurate and detailed documentation, prospective consumers of an API might opt for another API instead.
Obstacles to Consuming APIs
The focus here is on respondents’ actual experience of consuming APIs.
The Postman survey asked respondents about the biggest obstacle to consuming APIs: lack of documentation is seen as the biggest obstacle to consuming APIs (54.3%), by a very wide margin. Other top obstacles to consuming APIs are lack of knowledge, complexity, and lack of time, all cited by a little over one-third of respondents.
When Smartbear asked about the biggest obstacles to ensuring API quality, limited time due to workload (52%), increasing demands for speed of delivery (45%), and lack of skills or experience (34%) were indicated most by respondents.
Respondents from both surveys indicated that lack of time is the biggest obstacle in producing APIs. Lack of resources, knowledge and skills were also identified as significant obstacles. The implication is that developers producing APIs need tools to help them produce APIs faster and easier.
Obstacles to Producing API Documentation
Smartbear’s question about the biggest obstacles to ensuring API documentation quality resulted in most respondents (64%) indicating that limited time due to workload is their biggest obstacle, followed by documentation being out of sync with the actual API implementation (47%) and lack of personnel (29%).
As with producing APIs, the biggest obstacle to producing API documentation is lack of time. The implication is that either more people are required to focus on documentation, or better tools are needed to assist development teams in producing API documentation.
Low-code: The Future of APIs?
The reports indicated that API documentation is viewed as an important requirement for choosing an API to integrate to. Additionally, producers of APIs have identified lack of time (and resources) as the biggest obstacle to completing an API project. Tag this alongside the elimination of rewriting authentication code, parsing logic, and the other mundane aspects of writing code that integrates with an external service, low code is certainly something to consider. If a platform or tool allowed you to substantially reduce engineering time and dollars spent and still produce a high-quality API, would you use it?