April 22nd, 2022 | 4 MIN READ

What Does It Mean to be API-first?

Written by author_profile_images Bryan House

Bryan is the SVP of Product and Customer Success at Elastic Path. Previously, Bryan was the Chief Commercial Officer at Neural Magic, a deep learning software startup where he ran Product, GTM, and Customer Success. An Acquia founding team member, he helped lead the company to $170+M in revenue. His expertise spans machine learning, digital experience platforms, and open source technology. 

api_first

If you’re building a commerce platform, why reinvent the wheel when the right APIs will do? In his essay, APIs All the Way Down, Packy McCormick suggests that instead of building from scratch, companies can gain a competitive advantage from leveraging APIs. According to McCormick’s argument, by building a commerce platform out of APIs, there are two main ways to differentiate: By creating custom solutions paired with API-based components, or by organizing API-based components in a novel or interesting way. (I’ll talk more about how that can work later.)

The issue for many companies is the abundance of commerce APIs, which create an unnecessary perception of difficulty. The old way of thinking is based on the illusion of simplicity, wherein one vendor controls the entire commerce stack. Unfortunately, a monolithic software stack creates inertia and an inability to move fast enough to keep up with changing technologies and shopper preferences. As a result, commerce teams are forced to look beyond the monolith to achieve their business objectives – shattering the illusion of simplicity that drove their purchase of a monolithic solution in the first place.

That’s where a solution like Elastic Path can help, as it provides the logic and building blocks for getting started with an API-first commerce ecosystem. We make it simple to select and integrate the best tools for your business requirements and follow best practices to unleash the combinatorial power of APIs, as opposed to drowning your business and technical teams in complexity.

But how do you know if the technology you select is truly API-first? Many companies attempt to disassemble legacy monoliths and repackage or refactor them as microservices-based, API-first platforms. This approach adds unnecessary complexity, and flies in the face of API-first, cloud native principles meant to accelerate innovation.

In part one of this two-part series, I’ll cover what it means to be API-first. In part two, we’ll dive into what differentiates an API-first company from dressed up middleware.

 

See How Elastic Path Delivers Unique Customer Experiences

The Elastic Path Demo Library features multiple demos that showcase the power and scale of our products.

Go to Demo Library

The Rise of the Request/Response Model

An API-first approach means thinking of an API as the most important user for an application. In an API-first company, the APIs are often the first thing to be developed, and all new functionality should be exposed as an API. This approach is much different than “code-first,” where developers create an application first, and insert the API at the end. Legacy commerce vendors that are retrofitting their software to work with APIs fall in the code-first category. This approach can be an issue if the original application isn’t structured in a way that makes it simple for the API to access data.

API-first isn’t as simple as adding an API to the end of an overly complex system. As Chris Sperandio wrote while at Segment, “APIs are eating the value chain.” In the old enterprise software business model, companies bought packaged applications to streamline certain functions of their business, and these vendors charged extra for external API connectivity. Companies were forced to adapt to the way software vendors did business. Today, software is too interconnected to play that way.

Instead, a request/response model is taking over. API-first companies exist entirely between the HTTP request and response. As Sperandio writes: “Companies like Stripe and Twilio set themselves apart not only by the sheer amount of operative complexity they’re able to put behind an API, but because of how elegant, simple, and downright pleasant their APIs are to use for developers. In doing so, they give developers literal superpowers.”

The packaged enterprise software suites of the past few decades don’t function well in this Request/Response model because they aren’t built with APIs in mind. They’re built as self-contained ecosystems. That means their users are missing out on everything great about an API-first ecosystem: an improved developer experience, higher performance storefronts, reduced costs, faster time to market, and the ability to easily integrate with countless other “best-for-me” services.

Stay tuned for part two of this series, where I’ll explore what this means within ecommerce, and what differentiates an API-first company from dressed up middleware.

Share on

ecommerce_demo_library

Thanks for signing up!

You'll receive a welcome email shortly.

By submitting this you agree with our privacy policy.