Many enterprise IT departments have become big fans of an “API-first“ strategy. I think that in general, this is a bad idea. (Thread)
When you start with APIs, you really have to have a very good grasp of what that API’s users will need. You typically don’t. Instead, you try to come up with things that will “obviously” be re-usable, and end up with things that are not even useful.
Most often, APIs are shaped, and almost always restricted, by the capabilities of underlying systems they encapsulate. That’s great if these are great. They typically aren’t.
An API-first strategy assumes that great applications can be built by “just” “orchestrating” the capabilities exposed through APIs. That’s true for some applications, but not for many, and typically not for great ones.
Unless APIs are the actual product you provide to your outside customers, the horizontal divide created by putting an API boundary between your end users and the business logic (and the resulting Conway’s law effects) will create lots of pain and little value.
In many cases, an API-centric strategy is a sign of the strategists not wanting to have to deal with actual end users and their needs. It’s much easier to create re-usable services that someone else has to assemble, and even easier to create a meta-strategy for that.
(On the plus side, an API-first strategy works great if you have an API gateway product to sell, or want to legitimize legacy systems that are slowing you down by putting a “bi-modal” or “two-speed IT” sticker on them)
I blame most of the disasters in modern enterprise IT strategy on the fact that it’s people like me – backend architects with way too little focus on UI/UX aspects – who have been put at the controls for far too long.
You need a strategy for modular application delivery, not only including, but starting from, end-user needs. APIs are a meaningful means to an end for that. Starting with them is going to end badly, independently from your choice of protocol or data format.
