Downloaded 23 times
Uploaded byNordic APIs
Pain Points In API Development? They’re Everywhere
The document discusses the challenges faced in API development and emphasizes the importance of clarity within organizational development loops. It identifies common problems such as lack of documentation, internal abstractions exposed externally, and a need for better communication across teams. Recommendations include creating transparency, implementing structured processes, and leveraging public APIs for internal applications.
More Related Content
Similar to Pain Points In API Development? They’re Everywhere
Pain Points In API Development? They’re Everywhere
- 1. PRESENTED BY Pain Pointsin API Development Abhinav Asthana Founder & CEO, Postman
- 2. Source: ProgrammableWeb APIs havebecome pervasive. That’s why we are here! Modern Software is built on APIs.
- 3. Postman’s Perspective 5M+ Developers2.5M+ Collections Created
- 4.
- 5.
- 6. APIs are technicalAND business abstractions
- 7. Common problems while buildingAPIs Lots of things can go wrong while building APIs • Internal abstractions being exposed externally • APIs exposing programming language constructs (error messages, data types) • Developers might not understand objects inside your API • Designing only for specific use cases • Not accounting for undocumented surface area - Every observable behavior of the API will be consumed by a developer (Hyrum’s Law - www.hyrumslaw.com)
- 8. Common problems while usingAPIs • Little or no documentation • Just reference documentation • No use cases • No successful case studies • Unclear business rules (rate limiting, pricing, constraints)
- 9.
- 10.
- 11.
- 12.
- 13.
- 14. Why do wehave problems? • Disconnect between loops internally and externally is the source of all problems when it comes to building and promoting your APIs • Similar to building a product but affects APIs more as you can expose internal technical issues externally • Pushing out a public API is a cross disciplinary effort
- 15. How to fixthis? • Review all of your loops • Create transparency through communication channels in these loops • Get a dedicated manager to see through all these • Write stuff down
- 16.
- 17. Put all yourAPIs in one place #1 Tips for INTERNAL APIs
- 18. Count the numberof meetings that happen while you are building your API #2 Tips for INTERNAL APIs
- 19. Tips for INTERNALAPIs Introduce a change in your API and trace impact #3
- 20. Build a maturitymodel for your APIs #4 Tips for INTERNAL APIs 99 80 95 90 100 90 0 25 50 75 100 Quality Agility Availability Resilience Security Performance
- 21. Use public APIsfor internal applications #5 Tips for INTERNAL APIs
- 22.
- 23. Developer-friendly design -look at patterns but don’t overinvest #1 Tips for EXTERNAL APIs
- 24. Clarify versioning guidelines #2Tips for EXTERNAL APIs
- 25. Create walkthroughs -use Run in Postman, Apps #3 Tips for EXTERNAL APIs
- 26. Provide a publicroadmap #4 Tips for EXTERNAL APIs
- 27. Provide a publicissue tracker to catch open bugs #5 Tips for EXTERNAL APIs
- 28. Conclusion 1.Pain points inAPI development come from lack of clarity in the organization's development loops 2.Development loops should be documented and studied - they vary from org to org 3.Feed information back into the development loop and map out changes in the process
Editor's Notes
- #2 Hello everyone, I hope you are having a great time at Nordic APIs. I am Abhinav and I am going to be talking about how to solve the pain points that you encounter during API development.
- #3 Well we are at API World, so we can all agree on how pervasive APIs have become. At Postman, we have a bolder hypothesis. We believe that modern software is built on APIs. There is no software that either does not consume APIs or exposes itself as an API to other software. This has been evident in the growth of APIs both externally as public APIs or internally.
- #4 - We have seen this quite closely at Postman. - In fact, we ourselves have grown with the growth of APIs and Postman hopefully has contributed to the growth of the ecosystem. - Postman has grown to more than 5 million users over the past 4 years. - We see more than 2.5 million Postman Collections created in our platform. - APIs have become the norm for developers and companies today.
- #5 So much so that we at Postman think that every company is also an API company. All SaaS companies today have powerful APIs through which you can operate their entire platform. Some SaaS companies like Stripe are primarily APIs. Major cloud platforms are built on APIs and provide services whose primary consumption interface is through APIs. Companies that we have known for decades are modernizing their infrastructure and providing APIs for 3rd party developers to integrate with.
- #6 Despite this what we have learnt from our community is that APIs are hard to build. While there is a lot of focus on external APIs, in general, very few APIs would qualify in the eyes of developers as easy to use and build upon. Why is that?
- #7 Well, APIs are technical abstractions as well as entities that can abstract out an entire company! When different people come use the same term to mean different things it is a source of problems.
- #8 Not only are there challenges while building APIs, when you share APIs with others, you have to deal with several issues.
- #9 Developers don’t learn through reference upfront - here are all things that our API does vs all the things that our API can do for you
- #10 As we heard about these problems from Postman users and customers I started thinking of a framework to help us think through these problems and ways of solving them. One way that I feel helps get a better picture is seeing the development of an API through the lens of development loops that help take an API from a technical abstraction to a company abstraction.
- #11 The innermost loop is where developers create an API from code. This involves writing and debugging code to building an API. This is where the API emerges as a technical abstraction.
- #12 Once we have the API as a technical abstraction, the API is used as a technical abstraction by folks like QA, DevOps, Integration engineers. Depending on how complex the API is and whether it is meant for an internal audience of an external audience, the level of work here will grow. The end result of that is that the API becomes an abstraction that is similar to a product.
- #13 We see this segment growing pretty rapidly. People in Dev Relations, Sales, Support are all using APIs but they don't look into the internals of the development process of the API. They are concerned with whether the API delivers what it is supposed to - just like the way you would use a product. They would also contribute to aspects like marketing the API or selling the API.
- #14 Finally, when we look at the outermost layer, the API to an external developer looks like this. A great API hides all these layers within it and presents an amazing experience for the developer to use.
- #18 Postman Workspaces example
- #19 Calendar to JIRA
- #20 Mock server example
- #21 Demo the one that we are experimenting with
- #22 Hackathons are a great way to test out public APIs
- #24 Github’s example of REST and GraphQL
- #25 Need an example for versioning. How not to do it? Use Google as an example or have 50 concurrent versions
- #26 Use Okta’s example
- #27 Slack’s example