Last week I published a post entitled Opinion Time: Should Developers ALWAYS Build an API?. I got quite a bit of useful feedback on that post, and so I decided that I needed to publish a followup post so that I could parse and interpret all the different opinions you lovely readers gave. I was expected something of a heated fight, or at least a good match, but it turned out to be a slaughter. One side clearly and convincingly won the argument: almost all of the commenters on the original post agreed that building an API is a good idea, most of the time.
What’s An “API” Anyway?
Before we can even ask if we should always build an API, perhaps we should figure out exactly what that means.
API stands for Application Programming Interface, a wildly generic term on its face. When I wrote the Opinion Time post, I was thinking of an API as being a separate, stand alone service or data store which could be consumed by another application; commenters have rightly pointed out that my definition of an API was far too narrow:
…I think that in this case you’re incorrectly thinking that your two opinions disagree with each other. They don’t.
Yes, you want separation of concerns. You’re right. That is “always” good.
Yes, you want to avoid YAGNI. You’re right. That too is almost “always” good.
But in both cases, there is a matter of how far you push it.
Does your “API” have to be a separately deployable HTTP endpoint? Could your API just be a second set of controllers in the same application?
Perhaps your “API” is as simple as a “repository layer” in a separate class library in the same solution as your MVC UI site.
Travis brings up another good point: we want, need, separation of concerns in our apps. In a world where no single idea can be always good or always bad, separation of concerns is one of the few concepts that is consistently valid and accepted. So wouldn’t building an “API” (for whatever that means) be a good thing most of the time?
Experience Trumps Theory
Another commenter had a personal experience that led him to the same conclusion as Travis:
At one point I would [have] thought that we do not always need an API for every application. However recently I have a project of moving an existing application without an API have it interact with a new system/front end. Now the task of writing the API to fit within the existing structure of the old program and interact with the new system/front end has become quite a task.
For me I will always want this separation using an API.
In fact, quite a few people had personal experiences that led them to the same conclusion:
Just this year, our organization decided to “open” our systems up to a third party for the first time - in terms of exposing an external API.
What we’ve discovered is that, even where we don’t have the exact right APIs already developed for this third party, the systems which already have the API separation are proving trivial to amend to fit the requirements. Whereas the monoliths (of which we have several) are proving problematic to provide APIs for.
– Damien
Need To Be Flexible
A couple people pointed out that the real reason we would to build an API was flexibility, including the potential to refactor to new technologies as they become available:
I am pretty firmly in the API ALL THE THINGS camp. In my experience, you can never predict when you may be asked to expose functionality you’ve built to something other than the original application. Just today, I was approached about exposing functionality … from an app written four years ago to a third party.
Building with an API from the ground-up allows that future flexibility. As others have noted, adding an API layer after the fact is almost always going to be more difficult/time-consuming. It also helps to ensure that separation of concerns is baked in to the architecture.
Solve A Problem, Not All Problems
One commenter preached caution when deciding what standard to build your API against:
I second David Fowler: “If you have an abstraction with a single implementation then you don’t have an abstraction.”
As long as the API has only one consumer, it’s entire job should service that consumer. Make it REST-ish, sure, but don’t bend over backwards to meet some arbitrary ideal standard. Need to use POST as an RPC (Remote Procedure Call)? Go right ahead. Clean it up when you need to.
#research #api #almost #build