Pain Points In API Development? They’re Everywhere
•Als PPTX, PDF herunterladen•
2 gefällt mir•980 views
There’s an inherent tension for organizations doing API development: how to keep both your API developers as well as your infrastructure happy, at the same time. Decoupling front-end and back-end development allows parallel development, and helps keep your front-end, middle-end, and back-end efforts working asynchronously. This speeds progress, but requires far more – and far better – collaboration to be successful. Even an independent developer working with APIs requires good collaboration tools. In this talk, Abhinav Asthana will provide tips on how to improve in API development using collaboration tools like executable API descriptions, API mock servers, and documentation. He will include specific examples of how companies (such as VMware, Coursera, and AMC Theatres) have used collaboration to attain more agile development, to onboard developers, and to ensure input from all participants/stakeholders.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Pain Points In API Development? They’re Everywhere
Ähnlich wie Pain Points In API Development? They’re Everywhere (20)
Mehr von Nordic APIs
Mehr von Nordic APIs (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Pain Points In API Development? They’re Everywhere
- 1. PRESENTED BY Pain Points in API Development Abhinav Asthana Founder & CEO, Postman
- 2. Source: ProgrammableWeb APIs have become pervasive. That’s why we are here! Modern Software is built on APIs.
- 3. Postman’s Perspective 5M+ Developers 2.5M+ Collections Created
- 6. APIs are technical AND business abstractions
- 7. Common problems while building APIs 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 using APIs • Little or no documentation • Just reference documentation • No use cases • No successful case studies • Unclear business rules (rate limiting, pricing, constraints)
- 14. Why do we have 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 fix this? • 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. Tips for INTERNAL APIs
- 17. Put all your APIs in one place #1 Tips for INTERNAL APIs
- 18. Count the number of meetings that happen while you are building your API #2 Tips for INTERNAL APIs
- 19. Tips for INTERNAL APIs Introduce a change in your API and trace impact #3
- 20. Build a maturity model 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 APIs for internal applications #5 Tips for INTERNAL APIs
- 22. Tips for EXTERNAL APIs
- 23. Developer-friendly design - look at patterns but don’t overinvest #1 Tips for EXTERNAL APIs
- 24. Clarify versioning guidelines #2 Tips for EXTERNAL APIs
- 25. Create walkthroughs - use Run in Postman, Apps #3 Tips for EXTERNAL APIs
- 26. Provide a public roadmap #4 Tips for EXTERNAL APIs
- 27. Provide a public issue tracker to catch open bugs #5 Tips for EXTERNAL APIs
- 28. Conclusion 1.Pain points in API 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
Hinweis der Redaktion
- 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.
- 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.
- - 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.
- 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.
- 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?
- 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.
- Not only are there challenges while building APIs, when you share APIs with others, you have to deal with several issues.
- 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
- 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.
- 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.
- 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.
- 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.
- 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.
- Postman Workspaces example
- Calendar to JIRA
- Mock server example
- Demo the one that we are experimenting with
- Hackathons are a great way to test out public APIs
- Github’s example of REST and GraphQL
- Need an example for versioning. How not to do it? Use Google as an example or have 50 concurrent versions
- Use Okta’s example
- Slack’s example