What is an API?

I’m building the world’s largest API Marketplace with 10,000 APIs and 1MN users. The answer to “what is an API?” is more than technical definitions and conceptual explanations. Here’s my view:

Basics:

Application Programming Interfaces (APIs) are ways for computer systems to ‘talk’ to each other over internet protocols (HTTP, SMTP). Think of it as one computer making a phone call to another for a defined query and getting a response.

SOAP vs REST:

There are 2 main protocols- SOAP vs REST. The below graph from google trends compares Google search trends for ‘rest API’ (blue) vs ‘soap API’ (red).

Clearly REST standard is dominant. The main reasons are:

• REST is more flexible and lightweight. Compared to SOAP’s standardized protocol, it’s more responsive.
• REST allows HTML, XML, JSON messaging formats. SOAP only allows XML.

Perhaps the MOST important factor that REST has taken off is that it makes data available as resources, leading to their adoption as public APIs.

REST APIs: From ecosystem building to monetization technology

The first use cases of public REST APIs were by tech companies who used them to extend their service ecosystems. For example, Salesforce CRM API might allow users to plug that data into other analytics tools. Or Facebook created social log-in API to bind more users to their facebook accounts.

Along the way, a really determined guy by the name of Jeff Lawson figured out that REST APIs could also be used for service distribution and applied it to communications (SMS and voice). Twilio was borne out of this idea. I emphasize determination since he established:

• REST APIs as a distribution and monetization technology
• Software developers as a credible buyer segment (since devs are the main users of APIs)

This paved the way for ‘native’ or pure-play API companies to achieve massive success and become some of the most valuable tech brands in the world today. This includes names like Sendgrid and Stripe. It’s hard to believe that 14 years ago, none of the ‘API unicorns’ below existed!

This success has proliferated massive growth of API-based services. Developers and applications have a different problem set when it comes to APIs.

REST API: Cost/Benefit Assessment

Looking at REST APIs as functional blocks for applications (in the same vein as Twilio, SendGrid (product), Stripe (company) and Adyen), they are beneficial in the following ways:

1. Development savings: APIs let you fulfill functions like user authentication and email verification without having to code from scratch.
2. Innovate: APIs let you access cutting edge technology like computer vision, NLP and translation quickly and cheaply. You don’t need specialists for all these different fields.
3. Revenue: APIs can be used to provide functions or datasets for your app that you can monetize behind a paywall.

The risks/costs you have to balance out are:

1. Discovery: Finding what you need. By some estimates there are over 30,000 public APIs (and multiples more internal/private APIs).
2. Dependencies: Accessing a public API means you’re relying on someone else’s system. If they fail, so can your service.
3. Administrative overhead: Managing multiple APIs (X accounts each with it’s own API key, multiple bills to pay and multiple dashboards) will get very painful, especially if you have to do this every month. Fundamentally, this is driven by API providers being specialists in 1 or a few API services.
4. Security: Has the API Provider implemented the right security policy?

What the API Economy needs

This drove my thesis to build an ‘app store for APIs’. It’s now the world’s largest API Marketplace with 10k APIs and 1 MN users.

• DISCOVERY: 10,000 APIs on the platform so you don’t have to go elsewhere.
• ADMIN OVERHEAD:
  • Built-in tooling let’s you test, connect and subscribe to any API on the platform and manage them all with a single API key
  • Accessing all these APIs on one platform reduces mental fatigue and friction for users. You know where to find everything.
• DEPENDENCY: As a proxy layer over each API provider, we get and show data on latency and call success rates

Closing Thoughts: Where does the API Economy go from here?

I’ll end off by sharing some thoughts on what would make the entire API ecosystem better as a whole.

1. ‘APIs as product’ thinking: Enterprises embarking on a public API program today still largely view APIs as the purview of engineering. Best practice is: create a public portal and leave it. This ‘throw paint on the wall’ approach needs to shift towards APIs as products. That means holistic teams including marketers, community builders and commercial thinking.
2. Better API Monetization: In line with ‘APIs as products’, enterprises SHOULD monetize on their APIs. After all, if you have a valuable dataset or technology, why shouldn’t you charge for it? A clear monetization strategy is the only way for API programs to survive.
3. API Aggregators as a GTM vehicle: Creating an API is only step 1. Commercialization involves a whole host things like setting pricing structures, reaching an audience, rate limiting, billing, payments and collections that are tangential if you’re not a native API company. Yes, it’s self serving but it’s also true. It’s why we’ve worked so hard to bring users on to the platform. Access to 1MN users is day 1 value for your API.
4. API logic: If APIs are function building blocks for services, the underlying service provider is just a brand. Who cares who sent your SMS as long as it gets where it should? Your decision criteria is around performance and cost. The ability to chain or merge API logic together allows users to get best quality service at lowest cost. GraphQL offers something interesting in this respect. Standby for RapidQL as well.