Hello everyone, I'm Chris Nesbitt-Smith, a consultant from cns.me working in partnership with the Central Digital and Data Office (CDDO). Today, I've been asked to demystify APIs or Application Programming Interfaces and explain how they are essential to the future of public services.

By the end of this talk you'll hopefully come away knowing: - What an API is - How an API works - When an API is used - Where APIs are used - Why APIs are used, and specifically why they are essential to underpin the future integration of government services - And if I can still pronounce API at the end after repeating it so many times without existential doubt.

I'm going to be directly and indirectly citing Platformland by Richard Pope a lot in this talk, which is a fantastic book that I strongly recommend everyone gift yourselves and a colleague a copy of this Christmas.

In this case a direct excerpt from the book: The idea of APIs has roots in an early computer: the British EDSAC of the late 1940s. Reusable subroutines that solved common problems, such as calculating a logarithm were stored on punched paper tape and organized in a filing cabinet along with instructions on how to use them.

So, what exactly is an API? An API, or Application Programming Interface, well you can think of it as a contract or set of rules and protocols that allow different software applications to communicate with each other.

Or more visually an API could be seen as a bridge connecting two different software systems, enabling them to share data and functionalities seamlessly with a defined boundary.

Before we dive deeper, let's cover some key terms, concepts and buzzwords you'll come across when discussing APIs.

First, we have the client and the server. The client is the application or system that makes a request, while the server is the one that provides a response

This could perhaps be a web browser and the server could be a webserver such as gov.uk.

Servers often act as clients, so you can have a very long and complex chain of servers and clients. It is turtles all the way down.

for example a contact form on a website will take a request from the browser, store that in a database, and then send a notification

Often the detail isn't that important, but the outcome is they underpin all the digital services we use today, whether we know about them or not.

Next, we have requests and responses. The client sends a request to the server, and the server sends back a response. This exchange is the fundamental interaction in APIs.

An endpoint is a specific point where the API can access the resources it needs, often represented as a URL.

Think of it as the address where you send your request.

An API gateway acts as a single entry point for a set of APIs. to stretch the metaphor a little, perhaps think of this as a building with many units, if you send a request to the building, your letter can be ultimately routed to the correct unit. These are put in place often to help manage, secure, and scale services.

There are various types of APIs that you might hear about. So let's go through some more buzzwords you might encounter, don't worry I won't be testing you at the end, it might just help join the dots when you hear about them in the real world.

RPC, gRPC and SOAP you probably won't come across, but they are low level mechanisms for communication between systems, that are not often used directly.

REST is an architectural style that uses standard HTTP methods. It is how everything works on the web today, for example your browser issues a GET request to retrieve data, a POST request is used to send something or carry out an action like submit a form. You'll often find that APIs are described as RESTful, which is a way of saying they are built using REST principles. Most other things you'll come across are built on top of REST.

GraphQL is a query language for APIs, allowing clients to request exactly what they need quite specifically, and to get back a very specific response. This is great for performance and reducing over-fetching or under-fetching of data, in that there is no need to retrieve more data than is needed for the task at hand, however can have a higher maintenance burden.

Next, lets move on to Data Formats. APIs use various data formats to exchange information, while these could include a variety such as images, pdf, word files or even video.

The most common you'll find is JSON, which is a lightweight data-interchange format that's relatively easy for humans to read and write. The slide here shows what this actually looks like, where we've got a Person object with a name, age, city and detail of their children, the indentation and new lines are not required, but are often added for readability.

Here is that same data, but in XML format this time. If you've ever looked at the source code of a webpage, you'll have seen XML before, XML is what HTML (HyperText Markup Language) is built on top of. It's older than JSON but still used, especially in SOAP APIs and of course for HTML.

CSV is a simple format for storing tabular data, much like a spreadsheet.

Some APIs might return data in plain text format. It's human-readable but lacks structure.

You may not need to know the details of JSON vs. XML, but understanding that data can flow between systems in these standardized formats helps ensure services are consistent, scalable, and interoperable. You'll be pleased to know that's the end of me talking about abstract jargon and concepts, now lets move on to how APIs are actually used in the real world.

To take a famous example, Amazon in 2002 issued what is now commonly known as the "Bezos API Mandate" or "Amazon API Mandate", that is often credited for their ability to scale. Jeff Bezos known for his brevity, issued this mandate with just seven points.

All teams will henceforth expose their data and functionality through service interfaces.

Teams must communicate with each other through these interfaces.

There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.

All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

Anyone who doesn’t do this will be fired.

Blunt and to the point, however 22 years on it is still the case, and allowed a bookstore to become a multi trillion dollar company, entering new markets, launching new products and services several times a week. Other bookstores, retailers, hyperscale cloud providers, supermarkets, movie studios, streaming services, consumer hardware manufacturers, marketplace providers, satellite operators, etc are of course available.

Just as Amazon used APIs to break down internal silos and scale new services rapidly, government can use APIs to reduce duplication, improve service delivery, and share data more seamlessly across departments.

APIs enable seamless data sharing between departments without duplication, of what you might be used to where a department provides a copy of their data to another department, which is a point in time snapshot.

You can find a catalogue of many uk government APIs published at api.gov.uk

For example, I can look up events in my local police area, in this case I'm looking at Victoria, London, and I can see there is a property marking event coming up where I can go get my phone or bike marked, while I could obviously find this from the website, the API allows for other applications to access this data, for example a bicycle manufacturer or phone provider could query this central API and notify their customers who are registered in the area along with also looking up local crime stats, cycle routes and traffic. If I'm going to receive marketing information, it may as well be relevant to me, so recommend I invest in a better bike lock, or that I'm more cautious than normal when walking while doom scrolling my phone.

Personally for me, I found that my local council provide an API for their bin collection days, including when they move for bank holidays and strike days, so before I go to bed the night before collection my smart home speaker who's name begins with an A or G can remind me.

Or my accounting software can submit my VAT return without me having to log in to a separate system.

My local garage sends me a notification to invite me for a MOT when its due

So as a citizen, government exposing publicly owned data can simplify my interaction with government, often by me not having to even know I'm actually interacting with government.

The increasing ubiquity, maturity and capability of APIs are crucial for scaling public services effectively, ushering in new proactive interactions where government services are ambient provided rather than purely reactive services that must be sought out.

In other words, success looks like a consumer can get on with their day without having to keep a mental model of how government is structured, the fact that DVLA and DWP are separate entities is no longer relevant.

For example, in the not to distant future Sarah, a busy mother to 3 young children can move in to a new area, and instead of visiting multiple websites, for council tax, gas, water, electricity, broadband, bin collection, recycling, banking, credit cards, tax, school registrations, mail redirection, any relevant benefits she's entitled to, GP and dentist registrations, and everything else, these can all proactively be promoted to her.

DVLA cite their API first strategy as a key part of the success in working with the Home Office to help police doing roadside checks, DVSA to make sure drivers are eligible to take a theory test and to carry out instant driving licence checks at the roadside, and to work closely with HM Courts & Tribunals Service to digitise paper-based prosecutions.

The Department for Education were able to leverage APIs to move their school attendance tracking system during the pandemic from quarterly reporting to multiple times a day, which was a key metric and included in the daily COVID-19 briefings and was leveraged to make realtime policy decisions.

APIs are essential at organizational boundaries, but if you leverage them well, they can be used to connect services within a single organisation to deliver scalable, and secure dividends, powering the future of our digital services and removing the rigidity in the boundaries.

It's worth clarifying that not all APIs are created equal, and there are many challenges to be overcome, including the fact that APIs are not always well documented, that the data they return is not always consistent or accurate, and security is and adherence with policy is complex to say the least.

In conclusion: • APIs are essential building blocks for modern digital services. • They enable seamless data sharing and reduce duplication. • They are a strategic asset, not just a technical tool. • Government is leveraging APIs for better, more integrated citizen experiences. • And the future is proactive, “invisible” government services powered by APIs.

Thank you once again for your attention.

Before I wrap up, I'll get in trouble with my team if I didn't give Get Cloud Certified this Autumn a plug which I think might have a day or two you can still sign up in. Which is a fantastic initiative run by some of my colleagues who've negotiated a massive range of courses and certifications that are free for all civil and public servants to take, I'll put the link in the chat and make sure its circulated afterwards too.

I've been Chris Nesbitt-Smith Like subscribe whatever the kids do these days on LinkedIn, Github etcetera. talks.cns.me contains this and other talks, they're all open source. Go buy Platformland: An Anatomy of Next-Generation Public Services by Richard Pope, he does a far better job of explaining with a lot more detail and incredibly well researched real life examples and case studies.

Let's open the floor for any questions, heckles, corrections or comments.