<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=4958233&amp;fmt=gif">
 
RSS Feed

Architecture | Gareth Badenhorst |
30 October 2020

SUMMARY

In this article, the third in my series on Internet Scale Architecture, I will discuss API management. This covers the design, documentation, and implementation of web APIs and their runtime deployment in a secure and scalable fashion. It also includes aspects such as monetising APIs as well as usage and performance reporting. The previous instalments in this series are an introduction to Internet Scale Architecture and a discussion of edge services.

INTRODUCTION

Years ago, I helped operate a B2B platform. We exposed an enterprise service to external consumers via a variety of mechanisms, including SOAP web services, EDIFACT over AS/2, and even via sFTP. I know this must sound unbelievably barbaric to readers of the twenty-first century, but it is true, nonetheless. The process for onboarding new consumers was roughly like this: We received an email from a developer in the consuming enterprise saying “Hi, I’m Fred Foobar from Acme corporation, can you send me the URL for your test environment and give me some credentials to test with? Oh, and can you send me some interface docs, please”. If you guessed that we didn’t have more than a hundred consumers, you would be right.

Now, if you want to operate at internet scale, you’re not only going to have to deal with the runtime scalability of the platform, but you will also have to scale the operational aspects of your platform, which includes solving issues like these:

  • How do I efficiently onboard new consumers?
  • How do I make it easy for them to use the platform?
  • How do I give them access tokens, so they can access the services that I have authorised them to access?

The short answer: You need an API management platform!

API MANAGEMENT PLATFORM CAPABILITIES

Firstly, here are some examples of API management platforms:

  • Apigee (Google)
  • 3-Scale (Redhat)
  • Mulesoft API Manager
  • TIBCO
  • Microsoft APIM
  • AWS API Manager

Generally speaking, an API management platform offers the following capabilities:

  • API gateways – components that proxy traffic from consumers to services that implement APIs. Traffic can be checked for appropriate authorisation, throttled, and have transformation performed on message payloads before being sent to the back-end service.
  • Developer portal – a web portal for developers to view documentation on your APIs, download SDKs to develop with, register their applications, and request access to secure APIs
  • API lifecycle management – to manage the development, deployment, publishing, and versioning of APIs
  • API analytics – to receive real-time data about the performance and usage of your APIs
  • API monetisation – to manage service plans, billing, and charging for the use of your APIs

Most API management platforms provide the above-mentioned capabilities as Software as a Service (SaaS). However, some allow on-premises deployments or hybrid models in which some components, especially API gateways, run on the premises, with the rest of the components running as SaaS. Apigee is a good example of this.

API MANAGEMENT PLATFORM EXAMPLE

A good example of an API management platform that I am familiar with is Apigee, which has been acquired by Google.

Figure1
Figure 1: Apigee overview

As a prominent example of an API management platform, I will explain Apigee’s main components in a bit more detail below.

API Proxy

These runtime artefacts are deployed to Apigee API gateways and responsible for proxying requests from consumers to back-end services. Their rules are defined in an XML format to execute policies in a pipeline or flow at either the proxy endpoint, which encapsulates entry to the proxy, or at the target endpoint, which encapsulates access to the back-end service. The proxy and target endpoints are separated to allow us to include policies to operate on the requests and responses as both flow from the client to the endpoint. Here is an example of a flow for the proxy endpoint:

Figure2
Figure 2: Proxy endpoint flow

The green box shows the different policies that have been defined. We are also shown a preflow for the proxy endpoint (highlighted in blue). Finally, the red box shows the policies that are applied in this flow: one to verify an API key and another to return a cached API response if available. The proxy definition is available in XML source form, so that it can be stored in a source code repository.

Figure3
Figure 3: Target endpoint flow

For the target endpoint, the blue box shows the URL of the back-end service that implements the API, in this case a simple mock service. The red box shows the application of a ResponseCache policy to cache the result of the service call. 

Overall, there are more than thirty policies that can be applied in categories like traffic management, security, mediation, and extension.

API Products 

API products are a key concept in Apigee. They are collections of API proxies, including API resource paths on the proxies and access rights, with a quota of service calls that may be made. This construct allows us to build service plans, for example, free tiers that allow a limited number of service calls and then various paid tiers permitting more frequent access depending on how much the consumer is willing to pay.

Let’s assume that I have an ecommerce site selling widgets, for which I have proxies for widgets that maintain the vehicle information including an online catalogue and orders to view, submit, update, and cancel orders. I might create an Orders_bronze product that has

  • widgets API proxy with / catalogue resource with READ access
  • orders API proxy with / resource with READ, WRITE access
  • quota of 5 API calls per second

whilst an Orders_gold product used by a major broker would have

  • widgets API proxy with / catalogue resource with READ access
  • orders API proxy with / resource with READ, WRITE access
  • quota of 1000 API calls per second. 

Apps

An app is a collection of API products with credentials for each product. These are intended for consumers of the APIs managed by the platform. If a developer wants to use one or more API products, they can request access via the API management platform, and if the request is successful, they are granted the necessary API secrets or access tokens. You will want to make this process as simple and automated as possible, especially if you have internet scale numbers of consumers.

Many API management platforms support monetising your APIs. This means they allow you to take payment from a prospective user for the use of higher-tier API products (e.g. the Orders_gold product in the example above). This is done when the user creates an app which includes relevant API products and will often involve the user supplying credit card information to allow charges to be levied for the use of the API.

Developer Portals 

Apigee allows administrators to build one or more developer portals to publish documentation on APIs via markdown and through API specs. Many developer portals also offer sandbox testing environments for consumers to test their API clients. Examples of great developer portals (not necessarily Apigee ones) can be found at devportalawards.org.

CONCLUSION

We explored how apps make it easy and scalable for consumers to obtain credentials for our services, and how developer portals facilitate easy access to quality API documentation and testing infrastructure. We also encountered the benefits of having your API gateway’s running in an elastically scalable SaaS. All in all, I hope this short tour through the features of Apigee has helped further your understanding of how an API management solution addresses the challenges of managing APIs at internet scale.

Gareth Badenhorst

Senior Architect

Gareth Badenhorst is a Lead Solution Architect and Design Authority in Endava with more than two decades experience in IT. He has a background as an engineer and still enjoys getting his hands dirty whenever possible. He has travelled the journey from traditional service oriented architectures to microservices and has had a recent focus on the end to end architectural concerns. Gareth likes music, movies and microservices. He also rocks the best mustache this side of Movember.

 

From This Author

  • 14 May 2019

    Edge Services

  • 28 January 2019

    Internet Scale Architecture

 

Archive

  • 13 November 2023

    Delving Deeper Into Generative AI: Unlocking Benefits and Opportunities

  • 07 November 2023

    Retrieval Augmented Generation: Combining LLMs, Task-chaining and Vector Databases

  • 19 September 2023

    The Rise of Vector Databases

  • 27 July 2023

    Large Language Models Automating the Enterprise – Part 2

  • 20 July 2023

    Large Language Models Automating the Enterprise – Part 1

  • 11 July 2023

    Boost Your Game’s Success with Tools – Part 2

  • 04 July 2023

    Boost Your Game’s Success with Tools – Part 1

  • 01 June 2023

    Challenges for Adopting AI Systems in Software Development

  • 07 March 2023

    Will AI Transform Even The Most Creative Professions?

  • 14 February 2023

    Generative AI: Technology of Tomorrow, Today

  • 25 January 2023

    The Joy and Challenge of being a Video Game Tester

  • 14 November 2022

    Can Software Really Be Green

  • 26 July 2022

    Is Data Mesh Going to Replace Centralised Repositories?

  • 09 June 2022

    A Spatial Analysis of the Covid-19 Infection and Its Determinants

  • 17 May 2022

    An R&D Project on AI in 3D Asset Creation for Games

  • 07 February 2022

    Using Two Cloud Vendors Side by Side – a Survey of Cost and Effort

  • 25 January 2022

    Scalable Microservices Architecture with .NET Made Easy – a Tutorial

  • 04 January 2022

    Create Production-Ready, Automated Deliverables Using a Build Pipeline for Games – Part 2

  • 23 November 2021

    How User Experience Design is Increasing ROI

  • 16 November 2021

    Create Production-Ready, Automated Deliverables Using a Build Pipeline for Games – Part 1

  • 19 October 2021

    A Basic Setup for Mass-Testing a Multiplayer Online Board Game

  • 24 August 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 3

  • 20 July 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 2

  • 29 June 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 1

  • 08 June 2021

    Elasticsearch and Apache Lucene: Fundamentals Behind the Relevance Score

  • 27 May 2021

    Endava at NASA’s 2020 Space Apps Challenge

  • 27 January 2021

    Following the Patterns – The Rise of Neo4j and Graph Databases

  • 12 January 2021

    Data is Everything

  • 05 January 2021

    Distributed Agile – Closing the Gap Between the Product Owner and the Team – Part 3

  • 02 December 2020

    8 Tips for Sharing Technical Knowledge – Part 2

  • 12 November 2020

    8 Tips for Sharing Technical Knowledge – Part 1

  • 30 October 2020

    API Management

  • 22 September 2020

    Distributed Agile – Closing the Gap Between the Product Owner and the Team – Part 2

  • 25 August 2020

    Cloud Maturity Level: IaaS vs PaaS and SaaS – Part 2

  • 18 August 2020

    Cloud Maturity Level: IaaS vs PaaS and SaaS – Part 1

  • 08 July 2020

    A Virtual Hackathon Together with Microsoft

  • 30 June 2020

    Distributed safe PI planning

  • 09 June 2020

    The Twisted Concept of Securing Kubernetes Clusters – Part 2

  • 15 May 2020

    Performance and security testing shifting left

  • 30 April 2020

    AR & ML deployment in the wild – a story about friendly animals

  • 16 April 2020

    Cucumber: Automation Framework or Collaboration Tool?

  • 25 February 2020

    Challenges in creating relevant test data without using personally identifiable information

  • 04 January 2020

    Service Meshes – from Kubernetes service management to universal compute fabric

  • 10 December 2019

    AWS Serverless with Terraform – Best Practices

  • 05 November 2019

    The Twisted Concept of Securing Kubernetes Clusters

  • 01 October 2019

    Cognitive Computing Using Cloud-Based Resources II

  • 17 September 2019

    Cognitive Computing Using Cloud-Based Resources

  • 03 September 2019

    Creating A Visual Culture

  • 20 August 2019

    Extracting Data from Images in Presentations

  • 06 August 2019

    Evaluating the current testing trends

  • 23 July 2019

    11 Things I wish I knew before working with Terraform – part 2

  • 12 July 2019

    The Rising Cost of Poor Software Security

  • 09 July 2019

    Developing your Product Owner mindset

  • 25 June 2019

    11 Things I wish I knew before working with Terraform – part 1

  • 30 May 2019

    Microservices and Serverless Computing

  • 14 May 2019

    Edge Services

  • 30 April 2019

    Kubernetes Design Principles Part 1

  • 09 April 2019

    Keeping Up With The Norm In An Era Of Software Defined Everything

  • 25 February 2019

    Infrastructure as Code with Terraform

  • 11 February 2019

    Distributed Agile – Closing the Gap Between the Product Owner and the Team

  • 28 January 2019

    Internet Scale Architecture

OLDER POSTS