When it comes to deployment of API Gateways, there are a couple of well-known patterns, that of the Internal Gateway and External Gateway (described in several resources including here).

These two deployments essentially reflect the considerations of offering endpoints up to less secure network segments such as the internet (external gateways) and trusted network zones (internal gateways). But in addition to the physical deployment within a network, these deployments are likely to host APIs with different characteristics, reflecting levels of trust, and emphasis on enterprise decoupling/abstraction (internal) –  the reason why APIs are sometimes associated with the idea of SOA 2.0. Compared with security sensitivity, and potentially monetization or at least usage metrics to help protect specific attack vectors.

These deployment patterns can be seen in the following diagram.

Both the internal and external gateways are reflective of interest in the origin of the API traffic. However a rarer 3rd pattern does exist.

Outbound Gateway

This pattern of crops up when you need to consider the ability to manage how internal solutions connect to outside services, for reasons such as:

• Track which external entities are being called and which internal solutions are triggering them,
• Ensure that appropriate privileges to allow data to leave an environment are involved,
• good auditing of what data is leaving an organisation,
• impose data redaction/masking,
• When 3rd party services incur a cost, sometimes it is deemed necessary to track and attribute charges. For example banking APIs may be charged per transaction so it could be desirable to track the call origin so costs can be attributed to internal cost centres based on use (but maximize effectiveness by sharing a single client account).

Often these controls are achieved via a basic web proxy for outbound traffic, however web proxies are a lot more general purpose as a result make it a lot harder to harvest and impose such controls in comparison to the capabilities of the gateway which can slice and dice the analytics, have the means to better interact with the payloads and apply security rules.

With gateways able to perform contextual routing as well, the use of a gateway means we can potentially avoid accidentally wiring an outbound call to a partner organisations’ non-production environment. If you’re handling personal data these kinds of controls are extremely helpful.

Anti-Pattern

Additionally, we do encounter an AntiPattern with API gateway use. This comes back to the point about internal gateways – SOA 2.0. If a gateway is viewed as part of a SOA 2.0 is very easy to slip into the thinking that the gateway can and should perform business-related logic like a service Bus (e.g. OSB). The problem is adopting this approach of incorporating into an API business logic – you risk several things:

• spreading your business logic across multiple technology layers making it difficult to maintain in a consistent manner (you wouldn’t put part of your orchestration logic in a Java app and part of it in SOA Suite by choice),
• APIs should conceal how business logic is applied, incorporating business details into a gateway as a published endpoint, actually raises the chances of this being revealed,
• Business logic tends to be more computationally intensive, as a result, you risk impacting your throughput and possibly creating unintended back pressure (i.e. create service timeouts at the service consumer) because the gateway won’t be scaled like the backend.

By all means allow the gateway to call out to business logic to help it determine routing, security rules – but if it is a business rather than a technical consideration it is better out of the gateway than in.  Of course, we do need to understand what constitutes business logic. The rough rule of thumb I apply is – if there is commercial impact or rules change based on how a company works rather than on a technical basis then its business logic.