It was the second half of 2015 and we were working on the early prototypes of a cloud native, integration service. Our goal was to build a “connector service” which would provide uniform REST APIs to work with any app/service that we had support for. Note that the uniformity was with respect to the experience of the consumer of service and its APIs. The semantics of operations done using the APIs and the native APIs used to implement them were widely and wildly different (pun intended).
Since it was early prototyping days and no one knew the best way to go about it, there were different teams situated in different geos trying to come up with their version of the solution.
My team approached it with an API first mindset where in we designed APIs for:
-
Catalog of supported connectors (In our service)
-
Connecting to the system (Using endpoint and credentials specific to user)
-
Discovering the metadata (Business objects supported, their attributes etc.)
-
Creating/Updating/Deleting an API (To perform action or get events on a specific BO. This was a Lifecycle API for a Business API/Event.)
The other team took a different approach which focused on getting the job done quickly and not spending too much time thinking through the APIs.
When we tried explaining our API driven design approach through calls, emails, slack, ppt, docs etc. it was dismissed as too complex, unnecessary and so on.
While we believed in the value of our approach we didn’t know how to communicate it in a way that makes sense to the other team.
So we decided to do a live demo to understand what was complex or unnecessary in the whole sequence.
And we chose Postman for the demo. A collection was created with neatly named requests for the different steps - List connectors, create connection, discover metadata, create API etc.
In the demo, I along with my team went through the collection, step by step showing how the end to end flow will work. It took only a few minutes to explain the whole sequence and actually show it working. The people on the other side got it. In fact they appreciated it. We got an agreement to proceed with our API first design.
I became a fanboy of Postman and that was just the beginning. Over the years I have lost count of the projects, pocs, demos that I have used Postman for.
Many of us may have used Postman for learning, trying, testing, mocking, documenting, debugging APIs. It does all of this. In 2015 it did something more than this for me. I used Postman to tell a story. And people listened. To be more precise I used Postman to state facts and it helped people see facts and swap their biased/unreal story for an objective and realistic one.
Tell your (API) story - with Postman.