Talking about fundamentals of API design with Ankit Sobti, CTO of Postman

Ankit Sobti, is the Co-Founder and CTO of Postman, an API Development Platform used by over 8 million developers around the world. He is very passionate about APIs and has given many talks on the topics around them.

We got a chance to interview him and understand his views on fundamentals of API design and here is a transcript of the interview with him, edited for brevity.

Tell us about the journey of Postman

Abhinav, Postman’s CEO and Co-Founder, and I started our careers together in 2009 at Yahoo. We got introduced to the idea of APIs and their usage at scale. We would build front-end systems on top of internal APIs that would change frequently rendering the front-end unusable. Over the years, the problem of “What is the latest state of a continually evolving API” resonated with us.

Abhinav built the first version of Postman, a simple GUI replacement for cURL as a Chrome extension, which he open-sourced on Github and published to the world.

I would often stay at his place and help him build out extensions to the Postman application. The project saw massive traction, we had more than 50,000 users in the first 6 months since Postman launched and we pretty much learnt more about REST, HTTP and APIs through a burgeoning community that LOVED the product and resonated with the underlying problem statement.

In 2014, we observed the significant opportunity Postman had to meaningfully impact the world. We had more than Half a Million engaged users at the time, in almost every single country in the world, and the underlying problem of Collaboration while developing and consuming APIs still remained. We then started Postman the company, to solve this problem and many others as APIs become increasingly critical to the way businesses operate.

What made Postman so successful?

3 things:

1. Focus on a great User Experience for Developers – we have always held the opinion that DevTools need to have great UX, much like the best consumer products.
2. Collaboration – APIs are inherently collaborative and designed for Production and Consumption. Yet, the tooling that existed before Postman, for collaborative developer workflows, was often clunky and broken. Postman changed that by building Collaboration as a first-class citizen.
3. Community – A strong, concerted focus on community– listening to users and their feedback – the positive and especially, the negative has been essential to Postman’s success.

.

What is the current focus of the company, and what are you trying to achieve today?

We are increasingly cognizant of the fact that APIs are now used by many different personas beyond developers - Product Managers, Leadership, Marketing, Finance, Sales etc.

We want Postman to be the Single Source of Truth for APIs, built for the entire life cycle and the many different personas. We intend to achieve this by continuing to build an open platform, along with our community and partners, that integrates with any tools or systems that exist in our consumers’ workflows.

How do you see your business growing?

We will take bigger, bolder bets in the API ecosystem addressing the many concerns and business problems that exist for the aforementioned personas. We believe that now, we have the base organizational infrastructure to achieve this.

What are your top two priorities as the CTO of Postman?

Lead, grow and manage the Engineering team to achieve product & business objectives while ensuring the quality, availability, security, resilience and performance of the system – we define this as Engineering Maturity.

Secondly, I own the technical architecture of the organization and its evolution. When you double the traffic to your systems every six months, you observe an order of magnitude increase in scale every eighteen months. Hence, you need to design, plan and rearchitect constantly.

I'm a strong believer that technical architecture design is isomorphic with organization design, so we try to ensure that we put the right people to solve the right set of problems at the right time.

I also lead the Data Science team and focus on enabling the organization

to make high-impact decisions quickly, with a “sufficient” amount of data.

Your company is growing, your ambitions are also growing, and you're trying to increase the impact of your company, this is not an easy job. How do you scale yourself as an individual?

I seek insights continually from peers in the industry who have faced similar changes and conquered them. The good part about Postman is that because of the prevalence of the product, the recognition in the industry and the hard-earned goodwill, we have a solid network that we are able to regularly leverage. We are able to learn from people who have solved problems at scale and from the ecosystem, at a higher order of magnitude than ours and bring that back into the way we operate the company. While doing this I am always conscious of not blindly copying “what” someone did or “how” they did it, instead of focusing on “why” they did something and understand the context that drove the why. Imitation without the “why” will almost always lead to a suboptimal solution.

Secondly, I try to be highly curious and read (books) voraciously. The books I read are not necessarily technical or business, but are often philosophy, psychology, history as well. I strongly believe that information becomes knowledge under the relevant context. I also re-read the books that mean the most every two years. I feel that's important because the underlying assumptions and context evolve and you end up learning something new each time.

Thirdly and lately, I've been implementing this idea of Succession Planning consciously every 6 months. Succession planning is thinking through how the organization would function without you, documenting those gaps, and starting to fill them in. This, while ensuring the maturity of the processes and the product remain intact. This is a great exercise to run on a regular cadence to identify things I could be delegating, in the process, scaling myself and others in the organization around me.

As a novice API designer, what is the methodology or approach for someone to learn the art of API design?

Let's talk about what an API is first with an example. If you look at a business to developer companies (B2D) such as Stripe, the core product they sell is their API. If you are integrating with the Stripe API, you get the ability to collect payments from all around the world. You also get out-of-the-box is obfuscation of credit risk, fraud production, credit card regulation, payment processing and so on, across multiple geographies, in jurisdictions that you no longer need to account for. APIs allow me to focus on my core competencies as a business.

APIs need to be viewed as Products where you design the API, conduct consumer research, prototype, validate and iterate.

So when you start to design an API, you shouldn't start with "What are my routes going to look like?", "Should my API be RESTful or GraphQL?", the first and foremost concern should be “who will be using this API and why”, what value are they seeking that your API Product should offer to make them better at the job they need to do (Read “Jobs to Be Done”).

Once you have those answers at the surface, you would start prototyping the product, creating specific examples, validating with past/potential consumer, seeking feedback and iterating. At Postman, we (obviously) use Postman to create mock servers, to quickly prototype APIs and start integrating and seeking validation early on in the development process. This allows us, as a company, to remain nimble and identify integration points and issues arising within them early on. From there on we start looking at architecture and code, "What are the resources that I need?", "What is the database structure?" etc. The first thing I recommend is to understand who your consumers are, what they want and why they want it. This is how you create a Consumer-Driven API. You start to think about "Consumer-driven API" when you think about APIs as products.

Why do people design bad APIs?

Adam Judge, author of “The Little Black Book of Design” once said “The alternative to good design is always bad design. There is no such thing as no design”.

Sometimes developers tell you that they are not designing the API; they are just building it. There's no such thing as No design. Without an underlying set of principles, 5 developers contributing to the same API will mean an amalgamation of 5 different designs.

Another reason is people don't think about consumers when they are building these APIs; they are just building out these APIs because they are thinking in terms of abstractions that exist in the code, and APIs are just wrappers on top of this code. You need to look at API as a product. A bad product is one that does not serve the needs of the consumer, which is the same thing with an API.

Good API design does not expose the internals of the system, it doesn’t reflect how your code or database is structured. You need to be thinking in terms of how your consumers expect to interface with the API. Even if you're not strictly RESTful or you don't have the most elegant interface in which you are going to communicate, as long as you are satisfying the use case that your consumers are facing, it'll be satisfactory API design.

Much like with a Product, API design is not just about designing the API interface; It's also about how you document the API, how you teach the consumer to use the API, how do you manage the API over its entire lifecycle of existence, is the intuitive enough for consumption. Once people get more comfortable with your API, they seek a different kind of documentation than the one when they get introduced to the API for the first time. Good API Design also acknowledges the existence of a continuing relationship between the consumer and the Product (API), dedication to making small, useful improvements that are driven by understanding how your consumers are using your API.

Can you recommend a few resources that could help people to become better API designers, collaborators and integrators?

I have learnt a lot about APIs through the blog apievangelist.com. It’s an outstanding resource to understand the “business, technology and politics” of APIs, as its author Kin Lane puts it. I recommend the blog wholeheartedly. Kin recently joined Postman as the Chief Evangelist and has continued his fantastic work on apievangelist.com and also on Postman’s official blog.

A book I highly recommend on the topic is Continuous API Management. The book talks about the many aspects of API development through the API’s continuously evolving life cycle.

What are the new trends you see in the API design and development? Who are the top players? How is this space evolving?

I see many enterprises now adopting the philosophical mindset of "Consumer-Driven APIs" and "API as a product" that I discussed earlier, using tools like Documentation and Mock Servers.

API Specification formats have gained prominence in the last few years – Swagger, that evolved to the OpenAPI Specification being the most popular one.

GraphQL is one technology I am quite intrigued about. We are exploring GraphQL for our own use cases within Postman. I like the fact that it forces you to think in terms of graphs, and I think that's a natural evolution of how you think about resources and dependencies between them. But again, all of this is important only when you can think in terms of the consumer first.

What are your thoughts on HTTP based APIs with JSON payload and Protobuf based APIs with gRPC payload in the context of building microservices?

We use a combination of HTTP-based protocols for our own Microservices architecture. And for some instances, we are exploring gRPC, as well but in my opinion, communication protocols are often secondary to how you define what a Microservice and its boundary are. The choice of the protocol should be determined by the use case that you intend to solve.

I've gone through this journey over the past three or four years. We went with a Microservices architecture pretty quickly, at the time of inception of the company itself. If I had to go back in time, I probably would not have done that because it adds a lot of management and operational overhead in terms of execution and I don’t believe we were ready for this back in the day.

Lately, I have wholeheartedly adopted Domain-Driven Design as a principle to define Microservices boundaries. The first thing I do is look at what problems you are solving for your end consumers, what are the different personas for which you are solving, why do they need these problems to be solved. This again brings you back to the "Jobs to be Done" framework. You need to identify who are the users, what are the problems they are facing, and what do they need to do? And then you start identifying what business domains that you are solving your problems. There's no one approach to that because that is contextual to the way that your business operates, the industry, and how you want your business to run. The invariant here being the problems that your (potential) users are facing. Corresponding to that, you start thinking about the business domains around which you create your Microservices architecture. And the rule that I follow is that once you have a clearer understanding of what these problem domains are, you assign resources to be solving those particular problems. Microservices reside within those domain boundaries.

Ideally, a Microservice should not cross over multiple domain boundaries. You may choose to have multiple microservices within a singular domain boundary, and obviously, the domains interface with each other through APIs. But it is important to keep the domain boundary separation.

Another approach that I've seen companies do well is Monorepos. Companies like Google & Facebook work on massive single repositories. Monorepo doesn't mean a Monolith; it means you have a single repository and may even have a single deployment unit. Effectively, a Microservice is an implementation of the business context that you are creating within the domain.

With that in mind, you look at what problems you are solving for your end-users; if you are building for high-volume systems optimized for speed, you use binary protocols like Thrift. In many use cases, a simple RESTful API would suffice as long as you are consciously making sure that the domain logic resides within the domain boundary.

We would like to know about the Postman community and what role do they play?

Postman’s community is our most valuable asset. We’ve learnt a lot from the community about APIs & their evolution, through the many, sometimes ingenious, use cases the community throws at us.

Developer communities are hard to build, Postman has one of the biggest ones in the world. Business to Developer (B2D) companies like Postman need to leverage community as a competitive advantage, one through which you learn and engage.

.

---