Front / Mark Wilson
Sometimes at client sites, I see a separation of APIs advertised on an API Gateway based upon consumer type. Sometimes, this is unavoidable, but there should be a core set of APIs and a general push to create APIs that are reusable. Reusability of APIs is a foundational building block of API Governance, which is in turn part of API Management. Let’s not limit the ability to create reusable APIs by putting artificial barriers such as API Consumer Type in place.
A typical, large organization has several different types of API Consumers. Likewise, a SaaS product would want to support multiple types of API Consumers for maximum applicability. These could possibly include:
- Single Page Applications (SPAs)
- Mobile Apps
- Traditional Web Application
- Native Desktop apps
- System-to-System Communication (Internal to Organization)
- B2B Systems Integration
To support an API that could potentially be called by any or all of these, the API Gateway will have to support the following for each application type:
- CORS
- Authentication
- Authorization
There are many other things that API Gateways do, but these are interesting because they may differ by application type.
For example, CORS only needs to be supported for SPAs or other Javascript applications running in the browser. This requires the API Gateway or the API Provider to generate the correct header responses for OPTIONS method calls.
For authentication support, if OAuth2 / OIDC is used, then for the different application types, different OAuth2 Authorization Grants or OIDC Authentication Flows are needed.
For authorization, ideally, the authorization mechanism would be the same across the different API Consumer types. The details of how this is done are going to be highly specific to your use case, but at a high-level there would have to be some type of credential mapping phase between the authentication step for each API Consumer type and the common authorization step. This could potentially look like the following diagram.
Combine multiple API Consumer types with a desire to support multiple user communities and we have multiple new dimensions of requirements to take into account when designing our APIs and supporting systems (API Gateway functionality).
It’s going to be much easier to design this into the system in the beginning than to add it after the fact — like so many other things.
To some extent this this ties into the Backends for Frontends API design pattern.