(Reading time: approx. 4 minutes)
A public API (application programming interface) is code that allows third-party developers to access, integrate or extend your application’s features programmatically. Third-party extensions most commonly take the form of plug-ins and applications.
Many of the most successful applications and platforms on the market today can credit their success to their public APIs. Companies like Google, Apple, Facebook and Foursquare benefit greatly from their public API and invest in them heavily.
So how can a public API help your startup? And more importantly, how can you build a good one?
It’s all about customer acquisition
The life blood of every startup is its customers. A public API is a powerful customer acquisition tool because it allows the underlying software to solve a wider range of problems.
A developer community extending your product means that there are more apps or features solving more problems for more people.
Every app in the Apple and Android marketplace is available because Apple and Google have a public API. Each app is another sales pitch to a prospective customer because each gives customers a reason to find the iPhone or Android phone useful. If either Apple or Google had decided not to publish an API and had a less attractive selection of apps, which phone would you buy? My guess is the one with the public API and the wide variety of apps.
Would your product be more useful to a wider group of customers if apps and plugins were created on top of it? Would this make your product more competitive?
My guess is yes.
The importance of customer loyalty
As an API publisher, you have two sets of customers, the developers using your API and the end users of the products they build. Both are equally important.
Developers invest heavily in learning and using APIs. A well-designed API encourages developers to build more things with it. The more things they build the more invested they become in your API and, therefore, your company.
Customers are the folks using all those apps built using your API. Customer loyalty has to be earned continuously. Customers are loyal to products that are perpetually improved to serve them better. In 2002, IE held an 85% share of the browser market while Firefox held 3%. Today, IE has 43% and Firefox 28%. Why did so many people change browsers? Comparing the release schedules highlights the reason this shift was inevitable. Over the past 10 years, Microsoft has delivered 3 major releases of IE while Mozilla has released 8 major releases of their browsers, each containing better speed, efficiency and tooling for their users.
How did Mozilla, a non-profit-foundation, afford to develop so many features fast enough to outpace the biggest software company in the world? They didn’t. They relied on the developer community to use their API (open-source) to design and build features and tools. Browse the hundreds of Firefox extensions and compare them to the handful of IE extensions and you’ll get the picture. Which product would you find more useful?
Have an innovation incubator
Engaging and inspiring a developer community around your product will result in new and useful ideas for your product that you and your team could not have come up with alone.
Time Magazine recently ran an article about the 50 Best iPhone Apps of 2011. Looking through that list I realized, it is highly unlikely that a single company could own the majority of that list. No single company has the developer resources, artists, subject matter experts and ingenuity in-house.
It will improve code quality
Whether you decide to publish an API or not, applying good API design will improve the code quality of your product. This is because most of your product is made up of private API calls between components. When it comes down to it, all programmers spend a lot of their time writing private APIs.
To know whether or not your team needs to apply better API design principles, ask the developers on your team if your product’s API (public or private) is as easy to use as an SDK for a core language like Java or Ruby.
A clean and understandable API, public or private, lowers the cost of adding features and supporting existing ones. The end result is an improved user experience.
Helps with scalability
All of the aforementioned benefits cannot be accomplished in-house. Google and Apple don’t publish developer community statistics so I’m going to use GitHub as a benchmark. GitHub is an open-source developer community that has approximately the same number of projects as Google and Apple have mobile apps. As of April 2011, GitHub has over 1 million members. Can you imagine a software company capable of running a development shop that big?
The good news is you don’t have to. By designing a solid, useful and public API you can leverage all of these benefits with little additional effort, if you are writing good code to begin with.
Steps to building a strong API
APIs come in different flavours, embedded client-side libraries, server-side libraries and web services to name a few. Regardless of the type you choose to implement, you can apply the following principles to build a good API.
1. Focus. An API should do a small set of things really, really well. Keep the list of calls small.
2. Before implementing, create API stubs and write a few test extensions and plugins that approximate real-world user stories.
3. Adjust the API design based on your findings from step 2 and start building.
4. With each design decision ask yourself ”will this API be simple to understand and use?”
5. With each design decision ask yourself “can I change the underlying implementation without affecting existing API clients?”
6. With each design decision ask yourself ”how does this affect performance?”
7. Begin implementing the API but continue writing different example apps and extensions with greater complexity and realism.
Simple. Simple. Simple. It is vital to keep the API simple. From the conceptual level right down to the method signatures, a developer should just ‘get it’ even without reading your documentation (which should also be meticulous). Remember, once developers start using the API, it will be impossible for you to remove things from the API without affecting the apps built on them. So err on the side of simplicity. It’s easier to add calls and method parameters if the need arises down the road.
Designing and building a good API is a big topic. I will cover it in greater detail in a future post.
Do you have any experiences using good or bad API that you’d like to share?