What exactly is API-First?
All this is really advocating is for the separation of user interface from the programmatic interface (to wit: API), specifically here in the case of the web. It basically espouses to build your web service as an API, and let an independent team of designers (first or third-party) worry about how to expose that in a way that has end-user appeal; it also seems to include API aspects such as versioning, and other concerns.
None of that is really novel, but its certainly very true -- give me a great command-line-first tool (or, better yet, have that command-line interface load the logic from a .DLL and let me do the same) that I or someone else can provide a great UI on top of and I'm a very happy guy. GUI-first applications get in my way when I want to script something the tool does -- I can't do it from a command-line, over SSH, or on a headless server. Likewise, you don't want to hide your great web service or web-app behind its user-facing UI or muddle them together -- it puts you into a walled garden, and sooner or later someone will make the same service available in an open, inter-operable way that will make you obsolete.
Unix/Linux philosophy is based on highly-interoperable command-line tools, and the things you can do with it are extremely powerful. This is just that, but for web services, and with a few things we've learned over the years thrown in.
It basically espouses to build your web service as an API, and let an independent team of designers (first or third-party) worry about how to expose that in a way that has end-user appeal; it also seems to include API aspects such as versioning, and other concerns.
All the web services I've used work like that already. Am I just lucky?
All the web services I've used work like that already. Am I just lucky?
You're on the forefront of the new revolution!
All this is really advocating is for the separation of user interface from the programmatic interface (to wit: API), specifically here in the case of the web. It basically espouses to build your web service as an API, and let an independent team of designers (first or third-party) worry about how to expose that in a way that has end-user appeal; it also seems to include API aspects such as versioning, and other concerns.
It's not that it's a bad idea, it's just not exactly new. Even in a web context, I first heard of this over 15 years ago, and as you rightly point out, people have been stringing together unix command for decades now.
You know, I worked for a principal engineer who advocated very strongly for a cleanly defined API up front.
The difference was that we were working as multiple teams, and if you didn't define the APIs between teams before hand, nobody got any bloody work done. In the dependent-team case, you literally don't have a choice about defining the API (or network protocol) ahead of time.
API surface certainly is important, especially on the "web" (Whereby a web service provides the business logic for a diverse array of web-based and app-based interfaces, across a diverse set of devices with different connectivity and differing abilities to cache content, etc.) Its certainly non-trivial to do so, and IMO the diversity of ways we access the same fundamental service is what's novel this time 'round the wheel. Add to that that often the implementers of these ways and means are third parties, working to optimize the experience for their special device or what-have-you (e.g. I'm pretty sure Netflix didn't write the Netflix app on my Samsung TV) and its clear why a good API is super important -- UNIX did pretty well, and there are strong (though not universal) conventions, but its not a paradise either -- versioning of interfaces used in scripts can be pretty janky, and text isn't always an optimal medium for programs to talk over (though it does have a strong benefit in being a pretty-good lowest-common-denominator).
I imagine it's the same with a web-service like gmail, with many layers of APIs between email storage and email UI. Seeing as they're always rewriting everything, those APIs may as well be seen as the up-front constraints on the next rewrite :)You know, I worked for a principal engineer who advocated very strongly for a cleanly defined API up front.
The difference was that we were working as multiple teams, and if you didn't define the APIs between teams before hand, nobody got any bloody work done. In the dependent-team case, you literally don't have a choice about defining the API (or network protocol) ahead of time.
Even in my job, I define a robust graphics API, and then while the games team builds game-rendering features above it, I'm busy working below it, writing implementations for 5 back-ends :D
While a good discussion could be had in design methodologies, and the role of strong specifications, and of layering, and team designation... I can't help but keep returning to the fact that the OP's article is a terrible, strong-arm sales pitch aimed at non-technical managers of tech teams, trying to trick them into being hyped over a nonsense manufactured trend, which the author intends to profit from. :lol:
terrible, strong-arm sales pitch aimed at non-technical managers of tech teams, trying to trick them into being hyped over a nonsense manufactured trend, which the author intends to profit from.
Sounds like 90% of web tech and business software...
I can't help but keep returning to the fact that the OP's article is a terrible, strong-arm sales pitch aimed at non-technical managers of tech teams, trying to trick them into being hyped over a nonsense manufactured trend, which the author intends to profit from
Well, that sounds like every trend in the last 20 years. Anyone had their team agile-buzzword'ed lately?
