How to explain what an API is – and why they matter

Explaining what an API is can be surprisingly difficult. It's striking to remember that they have been around for about as long as we've had programming languages, and that while the "API economy" might be a relatively recent term, APIs have been enabling innovation for decades. But how to best describe them to someone for …

[amanfromMars 1]

Take a Bow and the Applause if the Cap Fits ....

El Reg is great example of a remote, relatively secure and readily available virtual API trading in quite a vast and oft unusual and eclectic array of trades/skillsets negating the need for one to build anything/everything in-house oneself even if it be sought/wanted exclusively for oneself.

[John69]

Is the terminology correct here? An application programming interface is a description of how a service works. An application programming application can implement an API and provide a service from an endpoint.

[Anonymous Coward]

Righ but, this article is for people < 30 years old.

"One early and famous example of an API... Google Maps API."

That's "early" if it was released while you were in high school, otherwise....

Not sure which EXTERNALLY complexed STRING based API came first, but x.500 had a very overly complexed one and of course SQL has always had an external API that can be at least as complexed as the longest string value.

As a old enthusiast programmer, "API" to me is all nearly internal using shared memory, for example drivers. Externally, well, technically 'la -al | grp whatever' counts as a complexed API.

[Warm Braw]

Beware the wolf in sheep's clothing.

APIs are hardly new. Early computer systems had "layered products" - teleprocessing monitors and database systems for example - that allowed "companies to access functionality supplied by others". Everyone who has used an e-mail client has used an API. HTTP is an API itself. Nothing revolutionary in principle to see here.

Arguably, the least important thing about the Google Maps API was the API. Mapping applications existed before Google Maps: what stopped them being more widespread was the cost of licensing the maps. What stopped the applications being interchangeable between different geographical regions was the subtly different projections used by different mapping organisations. Google Maps only enabled "a whole host of innovations" because Google sucked up the cost of mapping the globe and produced a global mapping resource using the same co-ordinate system which it allowed people to use at no cost. The API is simply noise compared with the economic transformation - except that it's the mechanism by which Google retains control over its investment.

And that's the key thing about the new API economy - you hand over your data and possibly also a payment and get some service in return. But you lose control of your data in the process. While many of these service providers may be benign, they're going to find out a lot about you and your competitors and that could put them in a position of significant power. And, of course, the more third-party APIs you're using the more vulnerable your business is to a technical or financial failure of any one of them - and you're on the hook for future price hikes unless you're prepared to go through the pain of regular service migrations.

And as soon as anyone can build a solution by plugging together a few building blocks there's no intrinsic value in it, it's simply a race to the lowest margin.

As for the car analogy, well, all those standard parts have led to just 14 manufacturers dominating the world's automotive industry. So maybe it's all down to money after all.

[bombastic bob]

Re: Beware the wolf in sheep's clothing.

API as a marketeering buzz-term. Now with MORE TIERS!

This reminds me when $CEO decided that TIERS were good, and MORE of them were better. It's a *FIVE* TIER SOLUTION! I was supposed to implement that. right...

So, is that "NEW TIERS, NOW with APIs"? Or, is it "NEW APIs, NOW with TIERS"?

I think *I* am in tears...

[Dr Paul Taylor]

screen scrubbing

In the 1970s APIs were called modular programming. It was the essence of Unix.

Problem is, the teenagers who implement a lot of the gizmos on the Web care more about making their sites look pretty than providing information to others.

Besides this, there is a widespread attitude that "no robots must be allowed in", ie under no circumstances should other sites be allowed to build on "my" information.

For example, when Jamie Jones and I were implementing istopbrexit.info, I thought "we've got the user's postcode and that of this meeting, let's tell them how to get there". A site called traveline.info seemed to be providing passable public transport information, but I couldn't see how to feed postcodes to its interface.

When I enquired, they told me I had to pay £500 for a license. This is a pretty stupid attitude, because if they provided a simple API, more people would find out about their site (and see their ads).

As for Google maps, it's only for Californians who never get out of their cars. It lacks any detail for pedestrians. streetmap.co.uk is far superior in Britain and increasingly openstreetmap.org across the globe.

(We took istopbrexit.info down when the disaster happened, but also because the major anti-brexit organisations were determined to compete with me instead of cooperating, and for personal reasons. Unfortunately, the domain name was taken over by a porn site.)

[A.P. Veening]

Re: screen scrubbing

Unfortunately, the domain name was taken over by a porn site.

I would qualify that as business as usual. Whenever the registration of a website with a decent amount of traffic lapses or it otherwise becomes available, it will be taken over by a porn site.

[amanfromMars 1]

Refused Novel Access can be Universally Problematical ...

....... for All Denied Future Sensitive Secure Intelligence

And that's the key thing about the new API economy - you hand over your data and possibly also a payment and get some service in return. But you lose control of your data in the process.

Another key thing about the newer and the newest of API economies ...... All your data handed over is surely worthy of payments to both raw and rare sources for services to be rendered in return. And whenever well done, is such a reward extremely generous and gratifying and the minimum absolute default awarded for continuing supplies of excellence in the data you control and master which is lost to/in others/one is decided/inclined/advised to deny from or rescind in others.

[Norman Nescio]

APIs have been around since the dawn of computing

They are just a documented way of handling the arguments in a subroutine call.

What's new-ish is the ability to run subroutine calls across a public network*, where you don't necessarily have ownership or control of the far end, and potentially paying for the privilege. This enables monetisation of (micro-)services, and a network effect of many people using the same API operating on common shared data. A bit like one fax machine being useless, two being of limited utility, but connect fax machines to a public telephone network and you suddenly have a new way of sending information around.

*Remote procedure calls have been around since the early 80s, and were an academic curiosity before then. New-ish in the history of computing. Possibly just discovered by Marketing?

[docmechanic]

Great description of the emerging market segment catering to "API first" organizations. Whether or not you feel that REST was an inflection point in the availability and wider usage of APIs, this piece nicely describes why that market segment is humming right now.

[bazza]

The Car Building Analogy is Flawed

Because, there have been different outcomes.

The proposition is that if you offer an API, you can sell that multiple customers, as an alternator manufacturer might sell to more than one company.

Thing is, if you study the automotive sector, it’s nothing like that.

Suppliers who enter the Toyota sphere of influence end up supplying only Toyota. This is because doing business with Toyota is really, really very good, they’re very large, and who’d want to do business with Ford as well?

Honda have a reputation for doing an awful lot themselves.

The US manufacturers had a habit of driving suppliers into bankruptcy by not paying bills, which is why when the Japanese arrived in the US a lot of suppliers stopped supplying US companies.

Bosch do everything in Germany. Similarly in Italy and France. Traditionally everything British used everything Lucas had to offer, but that’s a period best kept in the dark.

Every single deal is going to be different, successful or pointless, or over or underwhelming. What might start out looking pointless could become a gold mine. Or, set up to supply a big time customer and you might go bust in the process. The point is that to sell an API you have to have the resources to deliver it, and a thing that no one else can reproduce. If you solve the resource problem by relying on, say, scalable cloud providers you’re just a middleman, ripe for being cut out, because as we well know APIs can be freely replicated…

The real value in business is always control of the end customer base… If you provide only an API, you’re not the most valuable bit of the business.

[Norman Nescio]

Re: The Car Building Analogy is Flawed

Traditionally everything British used everything Lucas had to offer, but that’s a period best kept in the dark.

If you were using Lucas for lighting, that was not difficult!

https://mossmotoring.com/prince-darkness-joseph-lucas/

[Anonymous Coward]

....and no mention of Oracle vs Google?

.....so it's not not enough to "explain what an API is"...............

.....it's also required to explain what "the name of the API is"......as well!

Larry Ellison thinks that he can copyright THE NAME.......

.....even if the code called by THE NAME happens not to belong to Larry!!

Wonderful!!

Welcome to world of APIs......and commercial greed!

Link: https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc.

[martinusher]

A monetizing trend

Ever since the Marketing/Legal people because aware of APIs they've been thinking of a way to monetize them. Its obviously prime territory for an IP land grab but you do get the impression that what they'd really like is the virtual equivalent of a coin mechanism on each API call -- pop a coin into the slot, you get to use the API or those particular calls.

It seems that greed has no bounds.

[Anonymous Coward]

I'm sorry

To shoot this article down, but it's not seeing the forest for the trees.

Firstly, as everyone else have already pointed out, APIs have been around since two applications needed to talk to each other to run cooperatively.

Secondly, someone above have the insight that what's relatively new is being able to do that cooperative work across heterogenous machines controlled by different actors, with interactions occurring in an ad hoc manner X509, rsh, SMTP or finger are examples of APIs, although we call them protocols.

One that I never understood was the PhD guy who started calling HTTP, REST. He went like "Look! If you use a POST verb in your request you can send data to the server and the application at the other end will (should) understand the request to be non idempotent and…" Aber keine Scheiße, Herr Sherlock! That's straight off the HTTP RFC. :)

[Claptrap314]

Re: I'm sorry

The big deal about REST was that it allowed a standardized way to organize an API. Without REST (as I am #*$(&@@ experiencing RIGHT NOW), the entire API document has to be carefully studied to understand what a particular call does. With REST, you can feel your way through, and scan most of the document.

Of course, REST led to OpenAPI & Swagger, which means that you often DON'T have to read the API documentation at all!

What was (and is) obnoxious about REST is that there are classes of interactions that don't fit the REST paradigm, and, so far as I see, there is no clean way to handle those cases.

[Anonymous Coward]

Re: I'm sorry

> What was (and is) obnoxious about REST is that there are classes of interactions that don't fit the REST paradigm

That's because the "paradigm" is a particularly bad one. I recall reading excerpts of this guy's thesis back in the day and I didn't think it was PhD material. Undergraduate stuff at best.

> REST led to OpenAPI & Swagger

OpenAPI *is* what used to be called Swagger. Good for taking advantage of documentation generators to get nicely formatted pages. Shockingly bad for specifying real-life APIs.

> which means that you often DON'T have to read the API documentation at all!

I really wouldn't recommend that approach.

[bombastic bob]

Re: I'm sorry

sometimes making up your own API is easier (rather than using someone else's concept).

curl http://localhost:1234/function/param1/param2 <-- simple to implement and parse

(this would return back success, errors, query results, whatever like any URL to a web server would, ideally as plain text)

No need for XML, PUT, POST, JSON parsers, or whatever... unless you WANT to have it return XML or JSON or whatever. Pretty straightforward and flexible and do what you want. Not *entirely* RESTful but much better, In My Bombastic Opinion.

(such an API invoked by a set of a simple web pages can do some amazing things, where simple code quickly forms request URLs from user input, implementing it on the back-end in PHP rather than as JavaScript in the client, and use off-the-shelf web server and PHP - or if you wanted to, do a javascript query, whatever and have your API return XML. Pretty fast to do xml as sprintf() and return it. Oh yeah, I would implement the server part in C. In fact, I *HAVE* !!! SEVERAL times!!!)

[bombastic bob]

Re: I'm sorry

if you think of REST as a guideline in which you can be as flexible a you want, not so bad. Just do not restrict yourself to XML or JSON and it suddenly becomes VERY easy to implement both as a server and on the UI end.

[Anonymous Coward]

Re: I'm sorry

> if you think of REST as a guideline in which you can be as flexible a you want,

Yeah but then it's called HTTP. That's where the real merit was. Simple, logical and very effective.

REST is just someone else who comes along and adds a layer of bullshit on top of it, a bit like Scrum master™ types.

[LybsterRoy]

Re: I'm sorry

This resonates with me as I'm trying to understand the OAUTH2 RFC