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.
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
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
Editor's Notes
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