olly - Fotolia
Developers: Eat your own dog food when you build an API
It's not enough to simply build an API. If you don't "eat your own dog food" before distributing your API, you are setting yourself up for failure. Zachary Flower explains why.
The startup development lifecycle demands compromise. There's just too much to do, and not enough resources to get it all done "right," so developers have to cut corners when it is appropriate. Unfortunately, building an API for products is more of a business decision than a technical one, and that's where corners get cut.
The challenge with building an API for an existing product is that business requirements almost always come first. We are often forced to compromise the quality of the product in order to keep up with the needs of the business, and while that's par for the course with startup application development, it is the absolute worst way to approach API development.
The single most important thing to do when developing an API is consume it. "Dogfooding" is a popular term used in the startup community to describe the act of a company regularly consuming its product in order to better serve their customer base. It is extremely important to "eat your own dog food" when it comes to API creation because it provides developers a way to integrate the core functionality of your business into their own products. If the API doesn't work in the same way, or as well, as the primary product, then the developers, and their users, are going to have a negative experience. This makes everybody look bad.
Dueling codebases
If you don't eat your own dog food when building an API, then you are going to end up managing two separate codebases that serve largely the same function. The first codebase, the primary product, will be where the majority of development happens. As a result, it will be cleaner and more feature rich than the second codebase, the API.
The API, having already been dubbed the "second" codebase, will very quickly become a no-man's land. Updating it will be seen as a chore, something akin to data-entry rather than actual development, because methods will be copied wholesale from the "primary" codebase. Since features and bug fixes will lag behind the primary product, which will leave your consumers -- the ones that stick around, at least -- feeling shortchanged and maybe even betrayed by their fellow developers.
API development will eventually succumb to procrastination and ultimately come to a complete stop in order to allow the team to better focus their resources on the primary product.
Right or not at all
When you build an API, a good rule to follow is to avoid developing an API if you aren't prepared to rewrite your entire back end in order to eat your own dog food. The decision to develop an API should be given the same thoughtful consideration you would make before you build any new product. In this case, you are effectively committing to build two new products, because not consuming your API isn't an option.
When your API is the official back end of your own product, it is very easy to keep your code DRY -- Don't Repeat Yourself. Features get developed directly for the API, which gives you the ability to release features to your consumers immediately. This also makes it significantly easier to test new features in the primary product before releasing them to the API consumers. When the producers also consume the product, then all problems that exist in the API become mission critical. Bugs get ironed out immediately, because they affect everybody equally across the board.
As a developer that frequently consumes third-party APIs, I've found that you can always tell which ones are considered part of the core product and which ones are afterthoughts. It doesn't take an expert to identify a quality product, and there is an obvious polish that comes from developers that are confronted with their product directly: a clear attention to detail that is lacking in afterthought APIs.
