This blog is based on a presentation from Kemp IT Law’s July 2021 Webinar, ‘APIs: legal aspects of the digital world’s connectivity accelerant’. You can see the webinar here.

Lawyers are generally familiar with APIs (application programming interfaces). They’re sets of standardised requirements enabling data to be communicated efficiently between different pieces of software. At one end of the spectrum, an API is just a simple document that says if you follow these rules when you’re programming, your two pieces of software will be able to communicate. At the other end, they can be complex software development kits, software based routines, protocols and tools. There’s a wide range of things to consider and that’s an important concept to grasp.

Historically, the developer used an API to ensure that an application written for one computer would run on another using the same operating system. It’s really an efficiency tool to enable one bit of work to be reused many times. The application calls on the OS through the API to use the OS’s functions through data transmission, exchange and access. Contrast APIs with drivers, which enable communication between the OS and the hardware it sits on; and compilers, which translate programs from human readable (source) code to machine readable or executable (object) code.

Today’s APIs have come on a long way.  Technical standards for APIs typically address four things:

• data transmission: the rules, the protocols – handshake for how data is transmitted securely – for example, using HTTP or HTTPS.
• data exchange: the format in which data is exchanged, the requirements of the message, and the fields – for example, XML and JSON.
• determining data access: the rules around who is authorised to access what data; and
• the rules around API design – like REST, SOAP and RPC.

APIs can be closed or private. If they’re closed and completely private, then they’re only for use within an organisation. At the other end of the spectrum you’ve got fully open, publicly available APIs. There are also many different kinds in between.

APIs today range from the APIs that big tech companies make available – Amazon, Microsoft, Facebook and Google – through to more specialist APIs. For example, everyone uses Google Maps as an API: you can download the SDK and customise or integrate it into your system. Google WAZE – the driver route mapping platform – operates in a similar way. Stripe is a good example – a payment processing and E-commerce platform that enables customers to integrate accepting and making payments into their online businesses. Salesforce, the well-known CRM platform, enables the Salesforce CRM to be customised and integrated into customers’ existing work flows. Twilio does a similar thing for communication systems.

A couple of quotes show whey APIs are so important:

“Modern APIs are the foundation of new business processes and the lifeblood of consumer-centric innovation” (Snaplogic).

“The API universe will drive innovation across all industries and expect to see nearly every industry be reinvented by an API” (Bessemer Venture Partners).

Today, a typical app is powered by around 20 APIs and APIs account for 80% of web traffic. This is largely the user’s device querying the backend server and data exchange between the two, but that’s a huge amount of work that’s attributable to APIs.

Three key things are driving this trend – open source, microservices and ‘cloudification’.

APIs are increasingly open sourced. In its API technical and data standards (v2 – 2019) the UK Government, an evangelist for public sector open source, exhorts government departments to:

“make sure your APIs satisfy the requirements of the Government’s Technology Code of Practice by ensuring they follow the Open Standards Principles of open access, consensus based open process and royalty free licencing”.

Second, APIs are becoming miniaturised through microservices and service APIs. Microservices adopt the technology of large scale SOA (service oriented architecture). Here, software is built (architected) around a middleware bus that matches (orchestrates) the process (service) that the customer requires from the available software on the menu. The bus takes down what the customer wants, goes away, brings back the functions that are available, bundles them up and then supplies them to the customer. Microservices are SOA, but on a much smaller scale: lightweight, limited, independently deployable SOA software where functionality is broken down into much smaller fragments and each individual functionality is treated separately. Service APIs tie or glue the pieces together and enable them to operate as one. The application becomes a suite of small integrated, SOA based reusable services.

Third, the ‘cloudification’ of APIs enables APIs to be managed from the cloud, from soup to nuts, right the way through the process. As you have more APIs, their management becomes a bigger burden and the cloud takes up the strain. This is happening through EiPaaS – Enterprise Integration Platform as a Service, typically a suite of cloud based integration services that enables integration within and between different cloud services, software applications and datasets. A key part of this is API publishing, where the EiPaaS publishes the full range of capabilities to manage the Platform.