Sign in to follow this  
Alpha_ProgDes

What exactly is API-First?

Recommended Posts

Alpha_ProgDes    6935
So I read this link: http://techcrunch.com/2015/09/27/the-future-of-coding-is-here-and-threatens-to-wipe-out-everything-in-its-path/
And it seemed like a whole lot of nothing. So I googled the term. And the first 3 links were still vague. I get it's a "new" approach to developing software. But why should I buy into this? Is there a takeaway from this paradigm I should be getting and embracing?

I'm going to keep googling. But I was hoping that someone had a more concrete, concise explanation of this new API-First thing.

Share this post


Link to post
Share on other sites
Aardvajk    13207
Ugh.

I also had a Google, as I was curious. Seems like drivel written by journalists without any actual real-world development understanding to me, but I'm happy to be corrected on this.

The idea that we have traditionally focused on the back-end, then developed the API as an afterthought seems pretty bogus to me.

Share this post


Link to post
Share on other sites
Brain    18906

Well after reading up on this it seems a bit daft to me for all but huge projects.

 

It's like writing an engine before you have any game to use it.

 

Basically you write the api first indenting to use that api to write your website so that extending the service to apps, desktop programs, etc can be easily done through that api.

 

That is all well and good but IMHO (as a business solutions developer with many years under my belt) it could result in a massive drain on resources. A library can easily be wrapped by a Web api using various dcom such as xmlrpc. It's one thing to write a reusable library (sensible) but another to go creating a Web api, kind of like "build it and they will come".

 

This is my own opinion and might not necessarily reflect reality smile.png

Edited by braindigitalis

Share this post


Link to post
Share on other sites
TheChubu    9454

Self fulfilling prophecy. Author talks big about nothing, nothing becomes something because of what the author said. Bam, traffic.

 

Next year you'll be hearing about API First manifesto or something...

Share this post


Link to post
Share on other sites
phil_t    8084

It's like writing an engine before you have any game to use it.

 

Actually I'd say it's like the opposite. Write (or prototype) your game to figure out what you need, and then build/use the engine that best accomplishes those needs.

 

But really, the headline is total clickbait and the article is just drivel. This isn't the "future" of coding. It's the future, present and past. The large software company I used to work at has been API-focused for at least a decade. This is nothing new. Design the APIs to ease and enable coding scenarios, and not as "artifacts" of the underlying implementation.

Edited by phil_t

Share this post


Link to post
Share on other sites
Ravyne    14300

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.

Share this post


Link to post
Share on other sites
Nypyren    12074

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?

Share this post


Link to post
Share on other sites
ChaosEngine    5185

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. 

Edited by ChaosEngine

Share this post


Link to post
Share on other sites
swiftcoder    18437

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.

Share this post


Link to post
Share on other sites
Ravyne    14300
Having a solid, well-designed, strongly-versioned I
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).

Share this post


Link to post
Share on other sites
Hodgman    51333

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.

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 :)

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:

Share this post


Link to post
Share on other sites
alh420    5995


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...

Share this post


Link to post
Share on other sites
swiftcoder    18437


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?

Share this post


Link to post
Share on other sites
SimonForsman    7642

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?


Unfortunately no, our team got agile-made-up-word'ed instead since the company is innovative and unique. (I like the innovation but the made up words are confusing, with the usual buzzwords you can at least sort-of understand what the suits are referring to) Edited by SimonForsman

Share this post


Link to post
Share on other sites
TheChubu    9454


I'm always gobsmacked at the number of people in software companies who can with a straight face extoll the virtues of agile development, while actually using a purely waterfall planning process to feed into a vaguely Kanban-like priority queue for the dev team.
Hahaha so true.

Share this post


Link to post
Share on other sites
rpiller    839

Just had a conference today and they talked about micro services. Seems the trend these days is to push a lot of little web api's and then make your products like legos by picking the services you need to complete the project. So literally your app could be made up of 20 different web api's, where each does their very own very specific task. As a developer I like this approach because you can really break the tasks down for your team and keep things very specific and simple to work on. Just better make sure when you change an api you are really careful since it could be used in a hundred different apps.

Edited by rpiller

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this