Every year, we survey the Postman community to get a picture of the API industry and to understand who is working with APIs, how they are getting their work done, and where they see the industry going. Over 10,000 developers, testers, and executives took our 2019 survey and provided insights on everything from how they spend their time to what they see as the biggest issues and opportunities for APIs.
APIs go beyond those who code—it's not just a developer's game anymore. More non-developers are working with APIs than in prior years and there is greater diversity in where people work.
When it comes to developing APIs, there is a dichotomy of experience. A small, but significant segment of developers have 10 or more years of experience, compared to more than three-quarters who have 5 or fewer years of experience.
While more than half of respondents shared that their organization employs more than 25 developers, nearly three-quarters are assigned to teams of 10 or less, indicating that most teams are structured to be more responsive and agile. As teams grow in size, so do the complexity and number of APIs they work on.
While more time is spent working with internal APIs, and this segment has remained steady, there is a shift from using public APIs to using partner APIs when compared to prior years.
There is a great discrepancy between how people spend time, and how they feel they should spend time. Manual testing and debugging consume far more time than desired.
Documentation could be better—a lot better. Over half of those taking the survey felt that API documentation was below average or not well documented. That said, survey respondents shared specific and actionable insights to improve documentation.
Microservices, containers, and serverless architecture are among the most exciting technologies for developers in the next year.
While more developers work with Application Programming Interfaces than anyone else in a typical organization, APIs reach many more people than those who code. Working directly with APIs has become part of a surprising number of positions, including technical writers and executives, and this diversity appears to be part of a larger trend. Last year, 58.6% of respondents identified as either a front-end or back-end developer, compared to only 46.6% this year.
Not only are the roles of those who work with APIs diverging, so are the areas where they work. Agile development and microservices lead the way, followed by API/technical support, and various disciplines in testing and integration.
People are working with APIs in multiple industries. The majority of respondents (52.3%) stated that they work in technology, followed by 41.2% who work in business and/or IT services. Banking and finance round out the top 3, trailed by healthcare, retail, and manufacturing. Finally, the bottom three industries are comprised by government/defense, advertising/agencies, and nonprofits. Quite a few folks (11.6%) shared that their organization didn't match these categories and selected "Other," as their industry. This distribution of industries closely maps what we found in 2018.
When it comes to developing APIs, there is a range of experience levels. A significant segment of developers, 12.2%, have 10 or more years of experience, compared to 78.2% of developers who have 5 or fewer years of experience. With so many new developers joining the ranks each year, industry veterans may find it challenging to bring them up to speed quickly.
API teams tend to be 10 members or less, with nearly three-quarters of individuals stating that they belong to groups of this size. Large teams are rare; only 1.7% of those taking the survey reported that 50 people or more belong to their team.
Comparing team size to the number of developers organizations employ, we find the inverse is true. Over half of companies employ more than 25 developers, giving us insights into team structures. While many organizations employ substantial numbers of developers, they are broken into much smaller teams to align with organizational needs.
When we asked how much time respondents spend working with APIs, we found that 37.3% spend less than 10 hours per week and 35.7% spend 10 - 20 hours per week. The remaining 27% spend more than 20 hours per week, compared to 31.7% in 2018. Interestingly, the portion of the population spending the most time is not shrinking because they're working on APIs less, but rather the population as a whole is changing—with more new job roles and areas joining the API ecosystem.
What do people do in the time that they spend on APIs? More time (26.1%) is spent on development than any other task, followed by debugging and manual testing (22.2%), automated testing (11.4%), and designing and mocking APIs (11.2%). Other tasks make up less than 10% of time each, including managing others (9.1%), API documentation (7.3%), API monitoring (5.7%), publishing APIs (3.6%), and writing about APIs (3.3%).
When people compared where time is actually spent with where it should be spent, the good news is that API development tops both lists. However, there is one large disconnect; respondents spend far more time—70% more—on manual testing and debugging than they feel like they should. Instead of testing or figuring out why an API isn't working, they feel that time should be spent on designing and automating testing.
Overwhelmingly, individuals gain API knowledge by working with APIs on the job and through colleagues. This is followed by a nearly even mix of published documentation and online resources / classes. Seeking information from online communities rounds out the top four methods.
Most developers and team members work with only a handful of APIs, while a smaller segment works with a large number of APIs. About 13% of those taking the survey report that they work with more than 50 APIs, and not surprisingly, as the number of APIs increased, so did the average number of people on their team.
Survey respondents shared that the majority of the APIs (52.8%) they work with are internal, only used by their teams and organizations, which is on par with our findings in 2018. While internal APIs have remained steady, there has been a shift from public APIs to partner APIs over the last year. In 2019, 28.4% of APIs used were shared only among integration partners, compared to 25.7% in 2018. Meanwhile, the percentage of time spent on public APIs openly available on the web dropped from 21.8% to 18.8%.
When it comes to API performance, close to half of respondents feel that their APIs do not break, stop working, or materially change specification often enough to matter. The other half of respondents felt that breakages and changes occurred on a monthly (28.4%), weekly (15.7%), or daily (3.2%) basis. The silver lining? Only 3.5% of respondents shared that breakages and changes occurred too frequently.
While API security is a hot topic—driven by frequent reports of API security breaches and misuse—the industry feels differently. Nearly three-quarters of respondents feel that their APIs are, "very secure," or have "above average security." Only 2.4% stated that their APIs were not at all secure.
Documentation could be better—a lot better. Over half of those taking the survey felt that API documentation was below average or not well documented. Compared to 28.2% of respondents who felt that documentation was above average or very well documented, this suggests a compelling reason for teams to spend more time documenting APIs.
What does it take to improve documentation? Our respondents had insights into that, too. The most helpful enhancement API producers can make is to provide better examples in the documentation (63.5%), followed by standardization (59.4%), and sample code (57.8%). API consumers also find real-world use cases, better workflows, additional tools and SDKs helpful, although to a lesser extent.
Microservices, containers, and serverless architecture are among the most exciting technologies for developers in the next year, cited by 53.9%, 45.5%, and 44.0% of respondents respectively. Slightly less exciting, but still on developers' radars, are OpenAPI 3.0, GraphQL, HTTP 2.0, and WebSockets.
Every industry has its own way of speaking—from technical terminology to jargon to humorous slang. We asked respondents to share which phrases they use, which are their favorite, and which they've never heard. The winner? "Deprecate"—a label given to tools, protocols and features that are being replaced with newer versions—took the top spot.
We also asked which of these phrases have made the leap to being understood by others outside of our industry. Not surprisingly, deprecate took the top spot here, too; it's often necessary to explain to non-technical friends and family why they need to upgrade. Another popular term is "happy path," or a default scenario with no errors or exceptions.