The world of tech, like many industries, is full of jargon. With the exception of “caffeine” whose place of honor is industry-agnostic, all of these pieces of lingo are specific, descriptive, and ever changing. Heard more frequently of late is API-First Development. We like this. We like this a lot. But before we dive deep I wanted to take a second to appreciate what this means to the industry.

API-First Development (AFD) is a focus on building the different pieces of your application as individual APIs. Then have the various parts communicate through these well defined and standardize calls to one another.

Ok, but how is this different than what we do now? Right now developers use talent and guile to allow full applications and systems to talk to one another. Booking systems talk to airport operations systems, your new social media application talks to Google maps, and on and on. This is great but relies on building connections between existing systems. And yes, it is exactly as cumbersome and challenging as it sounds. Hence the talent and guile.

With AFD (like the name would imply) the APIs are thought of first. This is great for so many reasons!

  • Ecosystem Focus.The idea of an application interacting with the world is now front and center. This forces teams to examine and build to the most efficient ways of connecting to systems outside of their company. Now partnerships become a welcome new opportunity.

  • Stronger Architecture. By building the various components of your application as components that interact with one another via APIs, you build stronger individual pieces that scale and operate autonomously. In the short term this means much easier scaling and pushing of information to multiple sources within your application. In the long term this decreases technical debt by forcing the creation of strong component pieces with true API bridges rather than Franken-apps held together by duct tape (and yes, a happy bell rings whenever technical debt is decreased).

  • Faster, Stronger Development. Every time tools and resources can be compartmentalized those that use those tools and resources move faster. (Thank you Adam Smith for, you know,… Economics). Now image your shiny new application built under the AFD paradigm and image everyone else building the same way. Suddenly we have world of application components all with nicely defined APIs that can be plugged into one another easily. When interacting with information or systems is only about knowing the public interface or spec (and not all the gritty inner workings), more interesting systems can be built and built faster.

  • The list goes on… more approachability of building complex systems by less seasoned developers, portability of component pieces, standardization, etc.

Perhaps the right analogy for API-First Development is in how Legos work. By focusing on how the pieces connect rather than on a single end goal (like a Lego Millenium Falcon), the builder can now use the same pieces to make a car, a house, a pirate ship, or anything else they wish. The defined Lego pieces (bricks, wheels, windows, Lego-Men, etc) transcend one single goal and now become the resources for the goals of many diverse builders. This is huge for application development. And unlike Legos, I’ve never hurt myself by stepping on an application left lying out on the floor.

Thanks for reading this. If you enjoyed it, follow me on Twitter, and be sure to check out the BowTie MVP.