Product
BlogDeveloper ResourcesPricingCompany
Enterprise-ready Single Sign-on
Katanémo supports SSO for OIDC and SAML compliant Identity providers
Katanémo supports SSO for OIDC and SAML compliant Identity providers
.png)
Being API-first can unlock explosive growth for software start-ups and offer leverage - in terms of quality of development and a better user experience. For example, Etsy switched to an API-first approach after facing the common challenge of implementing their logic twice.
But what does it really mean? Much like the (overused) term serverless computing confuses some people in the cloud industry, being API-first has a nuanced meaning. I wanted to share some recent conversations with developers, engineers and CTOs building the next great SaaS companies, and how they described this term to me.
APIs, while ubiquitous in our daily consumption, still feel nebulous and amorphous. The temptation to use a popular web framework, a Postgres/MySQL database and a hosting provider feels like the path of least resistance. But the world's leading businesses like Twilio or Algolia, have launched as API-first businesses. There are several reasons to being API-first:
Above I have described functional and technical benefits of an API-first approach. But over the years, my view has converged to a single core idea: APIs can insert themselves in any workflow - they create for leverage and customization in ways UI components and workflows can’t.
This means functionality (like stripe payments) can be inserted into domain specific clients without the need for retooling and the redesigning of UIs. This has sparked an incredible amount of innovation, and API-first companies (like Stripe , AWS, Plaid etc) have enjoyed breakthrough success having others build on top of them (vs. have their UI integrated with others). But going from "we have APIs" to "we are an API company" is a shift in the mechanics of software development and business goals.
You can be API-first if your business commercializes APIs and provides APIs as a product. But API-first also describes an approach for API developers to define and design APIs schema before development. After my conversations with peers, my view is that being API-first is a mindset. Ask yourself: "will we deliver the most value for our customers by building dependable, robust and secure APIs".
This doesn't preclude you from writing a quick prototype, where API paths, resource definitions, operations are layered later on. The latter is incredibly important if you want to foster developer-led growth. But separating mechanics from principles, helps in building quickly without losing sight of the business goals.
Twilio virtualized traditional telecommunications infrastructure allowing developers to replicate any communications experience using APIs. The business recently announced Twilio Build, a partner program designed with an API-first approach.
Twilio’s unique API-first cloud platform is tailor-made to support an ecosystem of partners that are differentiated by the innovations they deliver for their customers.
- Ron Huddleston, Twilio
Some organizations adopt an API-first approach to optimize their total development time. For example, Etsy switched to an API-first approach after facing the common challenge of implementing their logic twice. Besides increasing extensibility for new devices and features, Etsy’s optimized their platform’s performance by enabling concurrent API calls previously limited by their PHP code base.
All of the code that was built for the website then had to be rebuilt in our API to be used by our iOS and Android apps.
- Stephanie Schirmer, Etsy
Another example of an API-first company is Netflix. Accounting for a large percent of total internet traffic, Netflix re-configured their API architecture to improve performance and enable UI engineering teams within Netflix to optimize client applications for specific devices. The end result is a fault-tolerant, performant platform that puts control in the hands of those who know their target applications the best.
A single team should not become a bottleneck nor need to have expertise on every client application to create optimized endpoints. Rapid innovation through fast, decoupled development cycles across a wide variety of device types and distributed ownership and expertise across teams should be enabled.
- Ben Christensen, Netflix
To create leverage, APIs should be treated as a long lever over a fulcrum. If you look at the Etsy example above, all client (user, device, etc.) interactions converged to a single API surface area. Users make API calls via the UI, and other client/automation scenarios route to the same surface area because all business logic is compressed neatly behind API calls.
Today, engineering teams have separate groups for building new functionality and scaling their APIs. While dedicating resources shows commitment to an API-first approach, it can result in losing the leverage and cohesion that APIs were meant to create in the first place.
For example, APIs tend to have separate administrative experiences. API calls tend to get tracked and logged separately from calls initiated by a user via a UI, which can result in losing tracing fidelity when debugging issues. Access rules for API clients are defined separately, which means that developers have to build and operate permissions and security controls in two different places, etc.
Some of the workflows that apply to API management will be different, but the overall experience should be cohesive. Users and administrators should not be forced to hop between tools to get a particular administrative job done in your application. They should be able to on-board, secure and audit the application experience in a unified way.
If APIs are treated as the source of truth for functionality, then you can use an API definition to create leverage and cohesion. The API spec can be used to generate server stubs and save development time, or scale APIs via popular API Gateways that improve the user experience. And you can even leverage an API definition to build a great user management and security experience for your app.
For instance, OpenAPI is an interface definition language for describing, producing, consuming and visualizing RESTful APIs. The spec captures resources, paths and operations supported by an application. And Katanemo helps developers build slick user management, security and auditing capabilities for their apps by submitting their OpenAPI (or GraphQL) spec to us.
If you don’t know what Katanemo is - it unifies user, machine and enterprise identity with a fine-grained security and sharing service so that developers can focus on their core competency. We help developers unlock adoption via a single user sign-up, and effortlessly scale usage via thousands of enterprise users using Single sign on (SSO) features. We enable developers to offer automation via API keys, and help them build critical sharing and security features that leverage their API schema.
Incidentally Katanemo itself is API-first, and uses Katanemo to power its multi-modal identity, security and sharing experience. You can read more about how we solved this circular dependency problem via APIs.
While a collective measure of global API consumption is hard to come by, consider the following stats.
The growth is a sure indicator that we are in an API-First era, where well-functioning API ecosystems are crucial for businesses to stay competitive. For a long time, Jeff Bezos has held that increasing your rate of experimentation is necessary for successful invention. APIs enable that fully.
APIs drive operational and business leverage, and they should serve as the foundation for your application experience (user, administrative, security or otherwise).
