Introduction

This discussion is intended to hash out the core ideas/concepts/entities for the Overlord API Management project.  The intent is to start with just the core, required entities and expand out from there as needed.  For any API Management requirement we should be able to understand which concepts/entities are impacted/relevant.

Components

First, the API Management project is broken up into two core backend components:

API Management

This component allows users of the API Manager webapp to create and manage Applications and Services/APIs (see below).  This is the management component, it does not expose any API endpoints or govern any API requests.

Gateway

This component is the "runtime" piece of API Management - it is responsible for exposing physical API endpoints that client applications will invoke.  These API endpoints are governed by Policies configured by the users of the API Management component when the Services/APIs were created and configured.  This component is intended to be a high performance system designed to allow high throughput (low overhead) of inbound API requests.

Entities

When managing APIs and the applications that invoke those APIs, the following entities are useful (note that "Service" and "API" are synonymous):

Organization - the top level structure used to group together Applications and Services with the set of users who are allowed to manage them.  Important: this does not enable any sort of relationship between an Application and a Service it might wish to invoke.  Instead, an Organization that contained both Applications and Services simply implies that a particular group of people (an Organization) is managing both a set of Services that can potentially be consumed some Application as well as one or more Application that itself will potentially consume some Services.  In other words, a single Organization may be developing both a set of Services and zero or more Applications - though these may not, in fact, be related to each other.

User - represents someone who can log into the API Manager web application in order to manage Applications, Services, or both.  Users can be members of zero or more Organizations, allowing groups of users to jointly manage Applications and Services.

Application - exists within an Organization and represents a client app which would like to invoke zero or more Services exposed by either the same Organization or some other Organization.  When first created, the Application does not have the ability to invoke any of the managed Services.

Service - represents an API being exposed by some external back-end system, for which we would like to introduce governance/management capabilities.  Services also exist within an Organization.

Plan - another entity that exists within an Organization, a Plan represents a Service Tier for a Service or group of Services.  When an Application requires access to a Service, it must connect with that Service through a Plan.

Contract - when an Application requires access to a Service (i.e. permission to invoke a Service) it must make a connect with/reference to that Service by creating a Contract with it.  The Contract is a connection between an Application and a Service via a Plan.

Policy - the backbone of Gateway functionality, Policies are executed every time a client application invokes a physical endpoint exposed by the Gateway.  Policies can be configured in three places:

• Application
• Service
• Plan

When the Gateway endpoint is invoked a Policy Chain is created by aggregating the Policies configured at each of the above levels.  This Policy Chain is then executed in sequence starting with the inbound Request and ending with the API response.

Message was edited by: Eric Wittmann (fixed copy/paste error in diagram)