Skip directly to search

Skip directly to content

 

API Management

 
 

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.

 

Related Articles

  • 30 October 2020

    API Management

  • 23 July 2019

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

  • 25 June 2019

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

  • 14 May 2019

    Edge Services

  • 28 January 2019

    Internet Scale Architecture

 

From This Author

  • 14 May 2019

    Edge Services

  • 28 January 2019

    Internet Scale Architecture

Most Popular Articles

8 Tips for Sharing Technical Knowledge – Part 1
 

Software Engineering | Laurentiu Spilca | 12 November 2020

8 Tips for Sharing Technical Knowledge – Part 1

API Management
 

Architecture | Gareth Badenhorst | 30 October 2020

API Management

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

Agile | Thomas Behrens | 22 September 2020

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

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

Architecture | Radu Vunvulea | 25 August 2020

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

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

Architecture | Radu Vunvulea | 18 August 2020

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

A Virtual Hackathon Together with Microsoft
 

Innovation | Radu Orghidan | 08 July 2020

A Virtual Hackathon Together with Microsoft

Distributed SAFe PI Planning
 

Agile | Florin Manolescu | 30 June 2020

Distributed SAFe PI Planning

The Twisted Concept of Securing Kubernetes Clusters – Part 2
 

Architecture | Vlad Calmic | 09 June 2020

The Twisted Concept of Securing Kubernetes Clusters – Part 2

Performance and security testing shifting left
 

Testing | Alex Gatu | 15 May 2020

Performance and security testing shifting left

 

Archive

  • 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 February 2020

    Service Meshes – from Kubernetes service management to universal compute fabric

We are listening

How would you rate your experience with Endava so far?

We would appreciate talking to you about your feedback. Could you share with us your contact details?