Your API is always the best. Of course it is. However, not everyone will see the value your API delivers without a little enlightenment. Sometimes the value of an API is missed in isolation when you are just looking at what a single API can do. To help developers, as well as business users understand what is possible it can help to connect the dots between your API and other valuable 3rd party APIs. This is something you see from API providers who have integration pages showcasing the different integrations that are already available, and those who have invested in making sure their API is available on integration platform as a service (iPaaS) providers like IFTTT and Zapier. If a new user isn’t up to speed on what your API does, it can help to put it side by side with other APIs they are already familiar with.
Being aware of not just the industry you are operating an API within, but also complimentary industries is what we should all be striving for as an API provider. The most competitive API providers all have integration pages demonstrating the value that an API provides, but more importantly the value it can deliver when bundled with other popular services their customers are already using. This means that API providers have to be solving a real world problem, but also have done their homework when it comes to understanding a real world version of this problem that other people face. Or simply have enough consumers of an API who are demanding that are also demanding integrations with other commonly used platforms. Regardless of how an API provider gets there, having an awareness of other platforms that companies are depending on as part of their operation, and ensuring that your API solutions are compatible and interoperable by default just makes sense.
I find that playing with a complimentary API in Postman helps you think about the moving parts of an API in a way that helps you see more of the capabilities and potential of the API, rather than just the API resources. Twitter and GitHub are two good examples of this. When I just think about each of the APIs, I don’t get much inspiration about what is possible. However, after I open up the Postman collection, begin browsing around the available API paths, hitting send on some of the requests, I begin to see more opportunity, and find new inspiration for what is possible. I enjoy dissecting an API, and laying out all the gears on the workbench with Postman. It helps if an API providers has already done the hard work for me of crafting a reference collection for their API, but either way getting my hands on each individual API request is a great way to light the fire underneath my imagination about what is possible with an API.
After breaking down a couple of complimentary APIs you find yourself able to see a uch bigger picture of business interoperability and integration. You start to better understand what is possible with an API, and how those possibilities apply in your real world of business operations. By evaluating Twitter and GitHub side by side I have come up with entirely new ways of engineering how I pull and index data from Twitter by defining API collections that pull data from Twitter and publish to private repositories on GitHub for further indexing and evaluation as part of my API discovery pipeline. I’m not interested in storing the tweets for too long, I am more interested in indexing the API references and any URLs that are present. After shifting how I use Twitter and GitHub I began to think differently about how I publish my blog content using my own blogging API, further matching up API capabilities across my business platform, and optimizing how I collection, store, manage, and migrate my content and data using internal and 3rd party APIs.
To be a good API provider I strongly believe you have to be an experienced API consumer. Having robust reference collections for the APIs you depend on is essential to exercising your API consumer muscles. By having these complete API collections, combined with working keys, tokens, and authentication as part of supporting environments, I am able to play API matchmaker more frequently. If I have to on-board with an API every time I go to use it, it is unlikely I will ever understand what that API does. However, if I have a working Postman collection and environment for an API in one of my Postman workspaces ready for use, I am more likely to be exploring, learning, and re-enforcing my understanding of what value that API brings to my API workbench, while also actively using individual capabilities of an API in my API-driven business workflows. Something that just feeds and strengthens my ability to not just be an API provider, and consumer, but also as an API matchmaker—connecting the dots between the most important APIs across my business operations.
