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.

Our team thinks about meaningful use cases first and makes all functionality available via API in parallel.