Many enterprise IT departments have become big fans of an “API-first“ strategy. I think that in general, this is a bad idea. (Thread)
37
251
46
592
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.
4
12
2
103
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.
2
3
44
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.
1
3
34
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.
1
9
1
54
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.
4
17
1
69
(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)
1
1
27
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.
Apr 15, 2020 · 9:28 AM UTC
13
27
2
81
