API series - Intro: scope, span & synopsis
Application Programming Interfaces (APIs) are everywhere.
This being true, the Computer Weekly Developer Network now embarks upon a story series designed to examine the mechanics of the API universe, count the number of solar systems currently making up the upper firmament of this technology zone and, crucially, track the likelihood of asteroid belts and cosmic catastrophes in this space.
Before we dig into topics, let’s get one thing straight, we will talk about Application Programming Interface (API) technology, although the term Application Program Interface is usable (and technically, it does express the same thing) we are using the -ing ending as our de facto standard.
What is an API?
An API is a software intermediary that allows two pieces of technology to talk to each other.
More specifically (and let’s use the TechTarget definition here) an API defines the correct way for a developer to request services from an Operating System (OS) or other application and expose data within different contexts and across multiple channels.
Often referred to as the ‘glue’ that binds applications, web services, OSs or smaller application components together, an API is written to a required syntax and is implemented by function calls composed of verbs and nouns.
As we know, a function call is a request made by a program or script designed to perform a predetermined function in a computer system – and where the function call has been created and designed to receive parameters (a value), then the values that the function are requesting are listed inside a functional call operator’s parentheses.
But that’s another story… APIs don’t exist without function calls and now we know why.
In this introductory exposition, MuleSoft’s core definition of an API is also helpful and insightful, “Imagine you’re sitting at a table in a restaurant with a menu of choices to order from. The kitchen is the part of the ‘system’ that will prepare your order. What is missing is the critical link to communicate your order to the kitchen and deliver your food back to your table. That’s where the waiter or API comes in. The waiter is the messenger – or API – that takes your request or order and tells the kitchen – the system – what to do. Then the waiter delivers the response back to you; in this case, it is the food.”
Also, key to what we need to discuss in this space is the importance of API gateways. An API gateway is an API management tool technology that sits in a special position between a software ‘client’ and a set of backend services, which could include a database and/or other applications.
An API gateway works to act as a reverse proxy so that individual applications are able to talk with backend IT systems and so be able to work with the whole host of API calls that are being brought into life in an IT system – it also helps aggregate the services required to fulfil those API calls and then deliver the appropriate results that the system requires.
So many API questions
But even with all this context, we still live in a world where we have a huge number of API questions to ask… some of which could include the below areas:
How do we ‘scale’ API management in the webscale world of cloud computing and the expansive road ahead?
When is an API not an API?
How do we catalogue and manage APIs on a day-to-day basis?
How important are open standards to the life of working operational APIs?
How do we achieve unified monitoring of APIs from a security perspective?
The core API management functions include authentication tools, rate-limiting controllers, analytics functions and ______ what would fill in the blank?
Is a governance control plane needed to keep APIs where they are supposed to be doing the job they are supposed to be doing?
Where does API testing come into the API lifecycle and how should it be carried out?
The most common architectures for APIs are REpresentational State Transfer (REST) and Simple Object Access Protocol (SOAP), both of which technologies work to defines a standard communication protocol specification for XML-based message exchange… what should API users, developers and architects consider in this space?
How do should firms look to monetise (and perhaps productise) their APIs, what does this process involve and what part does it play in the total API lifecycle?
Are APIs products or code?
That was a subheadline and a genuine question i.e. should we think of APIs as ‘products’ or code?
We also want to open up the discussion to cover API security risks (covering areas such as denial of service attacks and the greater attack surface naturally created by the very existence of APIs) today in the modern IT stack.
We also want to examine whether APIs should be chargeable (similar to the way a payment processor works to charge every transaction).
Longer down the API road, we also need to look at maintainability (and how programmers will handle dependencies downstream).
Additionally, let’s hear from anyone with opinions on the challenges associated with Joe Biden’s Software Bill of Materials (explained in this link) and look at how that impacts those who develop and those who consume APIs.
Our intention is to get to a point where we understand more about APIs in the context of modern software application development and be able to go deep for developers, go ground-level for laypersons with an interest in this space and also go big picture for the C-suite boardroom suits who now realise that they need to have an understanding of where APIs sit in our cloud-connected world of always-on computing.
