API has become a buzzword, now used outside of technology circles, a noun in itself but what are they? Why are they relevant? How would you use APIs? Building, sharing and even monetizing APIs?
What is an API?
An Application Programming Interface (API) allows communication between applications and is an integration technology. So why is everyone talking about them like they are the next big thing?
Let’s quickly compare with another simple technology, the World Wide Web. (WWW). A web page is nothing more than a way of formatting and serving information so it can be presented to a user. The construct of a web page can be very simple, text with tags. You can distribute web pages using a USB stick, DVD, Email (most emails are actually web page formatted using HTML) or as we most commonly associate with web distribution, using web servers and associated network infrastructure.
A web page is essentially a simple document, transported to the user and rendered using a web browser for the purposes of exchanging information yet it is a fundamental component of our modern world, how we learn, entertain, buy, manage and meet.
APIs provide the same function, though rather than human to human interactions these provide machine to machine interactions, yet the potential and implications go beyond the simplicity of the concept.
A quick history of APIs
API, like human interface computing, is not a new concept but has evolved over time to meet the requirements of software architectures and the demand of interface consumers.
Early integrations would occur within monolithic applications, software components sitting side by side, on the same compute environment, exchanging information.
As the need for external application communication became apparent, exchanging information without the need for human operators, APIs evolved to meet these requirements, largely in the form of technology such as file sharing, message queues, OLE and SOAP, technologies which have positives but would generally see very little standardisation and interoperability were also complex and made re-use difficult. (But still have a place in today’s software architecture).
Come the year 2000 and the REST API was born, finally an integration technology which was the machine equivalent of the WWW for people, a client-server technology that was stateless, real-time and based on HTTP (same as the WWW) allowing simplicity and interoperability.
The REST API is the type of API most are referring to when discussing APIs and although integration has evolved new methods since 2000, these tend to be for specific purposes, generally for communication of systems which serve REST APIs or human information interfaces.
How to utilise APIs?
An API is an interface of an application, so firstly an application is first needed to serve the API. The API could be representative of a function within a Monolithic application stack, it could be a simple microservice with only one simple function, it could be an external software platform like Salesforce and it could also be an external presentation of service, like Open Banking hosted by financial institutions.
APIs differ in functional complexity, some are simple information (GET) APIs that require no attributes, others may allow complex attribute options also allowing writes/sending of information. (POST/PUT/DELETE). APIs may also be secured so only authorised parties can gain access to the function or access only to certain information that can be presented by the API.
An example of a simple API could be the “People in Space Right Now” served by open-notify.org, this API lists the current occupants on the International Space Station. (http://api.open-notify.org/astros.json).
The API provides a simple GET in JSON format from a data source that is manually maintained by the author. Example format of the GET being:
{“message“: “success“,
“people“: [
{“name“: “Sergey Ryzhikov“, “craft“: “ISS“},
{“name“: “Kate Rubins“, “craft“: “ISS“},
{“name“: “Sergey Kud-Sverchkov“, “craft“: “ISS“}],
“number“: 3}
An example of more complex APIs could be that provided by the Open Banking standard, multiple APIs each providing multiple resources, including registration, account information, payment initiation and product information, each secured to only provide the information or allow the submission of information which the consumer has been granted access.
Although the examples are publicly accessible APIs, this integration type can also be used internally, allowing for differing tiers of APIs providing subsets or entire functions.
What can we present as an API?
Where Web Pages use HTML to structure content, REST APIs typically use eXtensible Markup Language (XML), JavaScript Object Notation (JSON) which is probably the most popular or YAML Ain’t Markup Language (YAML) which is gaining in popularity.
The API itself could present a basic function or an entire business capability, an API could be “Loan Application” in a banking context, that service could call other APIs such as “Credit Score”, “Know Your Customer”, “Product Selection Criteria” and “Money Transfer” as part of an automated business process, the responses from these “sub” APIs would inform the output of the “Loan Application” API.
An “Order Status” API may provide status data based on calls to other APIs such as Inventory Allocation API and 3rd party courier status APIs.
Business Intelligence could be obtained through utilising status APIs across your organisation.
External presentation and monetisation
Your organisation builds APIs to programmatically expose business capabilities, whether a simple risk calculator or a complex API such as “Cell Network as a Service”, you may wish to make these APIs available externally and even monetise these APIs.
This could be through direct or indirect monetisation, direct where you charge for use of the feature or indirect where you provide a more convenient means to engage and/or buy your existing products. (Such as quote calculators).
This could be through public offerings or using external APIs to facilitate strategic relationships.
Tiering and combining APIs
Although your initial APIs may be created and utilised under a tactical “non-architected” approach, continuing creation and utilisation without an architected approach leads to difficult to manage, service and unstable Information System environments.
The API architecture approach and the tiering and API combinations defined under that approach will depend on:
- Granularity of features and capabilities.
- Security and service implications.
- Centralised and/or decentralised integration approaches
Some generic approaches:
Service implications would relate more to the Non-Functional requirements and budget realities of the service being exposed as an API. If an API is mission-critical, handling many requests per second and a fundamental component of a value chain, you would likely ensure the API and its dependent systems are built and governed (change and service management) in a way to ensure this level of service.
Security will depend on the level of granular protection required. Simple Network Access Controls (NACLs) may be sufficient for protecting simple although sensitive APIs. Granular access control may be required for more complex APIs, for example using OpenID token exchange and JSON Web Signatures (JWS) to determine and allow the level of access to granular data sets.
Centralised vs decentralised. Centralised is the most common approach where an organisation has centrally hosted and controlled services where there is trust between systems, an example would be a Service Oriented Architecture. Decentralised is becoming more popular, especially within Digital Native organisations, where separate “self-organising” teams develop functions in isolation without holistic awareness, examples would be Domain Oriented Architecture or where integrations are proposed with 3rd Parties.
Whether centralised or decentralised you may wish to cascade APIs, where the presentation/function of an API is dependent upon other APIs, applying differing levels of complexity and access requirements within tiers. This can result in relatively simple System/Utility APIs made available for cascading via business process management, workflow management or orchestration to Process/Domain APIs, which in-turn could be cascaded and security managed to Presentation/End-User APIs.
Avoiding unsustainable API Architectures
Great flexibility can breed unsustainability, this is also true of APIs. Without intentional design and guidance, APIs can be cascaded in a way where weakness in a single API, either in terms of service, security or change can break services which could be mission-critical.
Without governance, an API that was not mission-critical before may be unsuitable for the requirements of a dependent service, a modification to an API, the withdraw of an API version or even basic maintenance could cause unknown and disruptive affects which can be difficult to diagnose.
The image below represents Uber’s services estate with the point to point integrations between those services. Each circle is a piece of software exposing an API or utilising an API. Each line showing an integration. As can be seen, a complex mesh has formed over time. Uber themselves are starting to remediate this situation with a move to Domain Oriented Architecture.
Uber Microservices Architecture Map.
Enabling availability and access of APIs.
How do you make end-users, developers and even potential external parties aware of your APIs? This is generally achieved through centralised catalogues, API stores and API marketplaces. With each of these you have entries for individual APIs, where to find these APIs, documentation for using the API, some repositories may also facilitate the setup of applications, select throttle policies, contain test tools and sandboxes.
This allows the democratisation of the use and creation of APIs, an end-user may combine the outputs of an API with another dataset and publish a new resulting API. It can be easier to track users which utilise these APIs and the usage of APIs themselves, which can facilitate decisions and messaging in relation to service events of those APIs.
Are you about to embark on your API journey? Are you looking to formalise your API architecture to bring stability, resilience and increase re-use? Would you like to discover the potential opportunities APIs may present to your organisation? Café Associates can help.
Richard Smith – Design Partner. www.linkedin.com/in/rsmithgsltd
Previous articles by author https://www.cafeassociates.co.uk/author/richardsmith/