Every enterprise application starts life able to answer one question well: how does it talk to everything else? Ignore that question long enough and the answer defaults to point-to-point integration — application A calls application B directly, application C calls both, and eighteen months later the organisation has an integration topology that nobody can draw on a whiteboard from memory, let alone safely change.
API strategy is the discipline that prevents this outcome. It is not primarily a technology choice between REST and GraphQL — though that choice matters — it is the decision to treat integration as a managed, governed capability rather than an emergent side effect of however each project happened to solve its immediate connectivity problem.
The Three Dominant API Patterns
REST (Representational State Transfer). The default enterprise API pattern for over a decade, and still the right choice for the majority of use cases. REST APIs are resource-oriented, stateless, and cacheable, with broad tooling support and a large talent pool that already understands them. REST's limitation is over- and under-fetching — a client often needs to make multiple calls to assemble the data it actually needs, or receives far more data than it needs in a single response.
GraphQL. Solves REST's fetching problem by letting the client specify exactly the data shape it needs in a single query, resolved server-side across potentially many underlying data sources. This makes GraphQL genuinely powerful for front-end teams building complex UIs against many backend services — particularly mobile applications, where minimising the number of round trips matters directly to user experience. The trade-off is complexity: caching, rate limiting, and query cost control all require deliberate design effort that REST provides largely for free through HTTP semantics.
Event-driven architecture. Departs from the request/response model entirely. Systems publish events (an order was placed, a payment was processed) to a message broker or event stream (Apache Kafka, AWS EventBridge, Azure Event Grid), and any interested system subscribes and reacts independently. This decouples systems far more thoroughly than REST or GraphQL — the publisher does not need to know who is listening — and is the correct pattern for high-throughput, asynchronous, multi-consumer scenarios. It is the wrong pattern for a simple synchronous request that needs an immediate response, where it adds unnecessary complexity.
The organisations with the most mature integration architecture do not pick one pattern exclusively. They apply REST for straightforward resource access, GraphQL where front-end teams need flexible data aggregation, and event-driven patterns for decoupled, asynchronous, high-volume flows — and they have an explicit decision framework for which pattern applies to which scenario, rather than leaving it to individual team preference.
API Gateway Architecture
An API gateway is the single managed entry point that sits between API consumers and the underlying services — handling authentication, rate limiting, request routing, protocol translation, and observability in one governed layer rather than requiring every backend service to implement those concerns independently.
The gateway is where API strategy becomes operationally real. Without one, every team building an API also has to solve authentication, throttling, and monitoring independently — inconsistently, with variable security rigour, and with no organisation-wide visibility into what APIs exist or how they are being used. With a well-implemented gateway, those concerns are handled once, consistently, and centrally observable — while backend teams remain free to build the services themselves using whatever pattern fits their use case.
The gateway also becomes the natural home for the API product management function that mature organisations eventually need: a defined process for publishing an API to a developer portal, versioning it without breaking existing consumers, deprecating old versions on a defined timeline, and treating internal APIs as products with consumers, not just as technical interfaces.
Vendor Landscape — Enterprise Integration Platforms
| Platform | Model | Strength | Best for |
|---|---|---|---|
| MuleSoft (Salesforce) | iPaaS + API management | Enterprise integration breadth, Salesforce-native | Large enterprises with complex, heterogeneous system landscapes |
| Apigee (Google Cloud) | API management + gateway | Strong analytics, monetisation features | Organisations treating APIs as external products |
| Kong | API gateway (open source + enterprise) | Lightweight, cloud-native, Kubernetes-friendly | Engineering-led organisations wanting gateway flexibility |
| AWS API Gateway | Cloud-native gateway | Deep AWS ecosystem integration, serverless-friendly | AWS-centric enterprises, event-driven and serverless architectures |
| Azure API Management | Cloud-native gateway + management | Deep Azure/Microsoft ecosystem integration | Microsoft-centric enterprises |
MuleSoft remains the enterprise default for organisations with genuinely complex, multi-system integration landscapes spanning legacy and modern systems, particularly where Salesforce is already a core system of record. Kong and the cloud-native gateways (AWS, Azure) suit organisations with strong internal engineering capability who want more architectural control and are comfortable assembling capability rather than buying a complete platform.
What to Do Next
Three questions that reveal integration architecture maturity in any organisation:
1. Could you produce an accurate, current inventory of every API and point-to-point integration in your environment today? Most enterprises cannot — which means nobody can reliably assess the impact of changing or retiring any single system.
2. When a new integration need arises, is there a default pattern and a managed gateway to build it through, or does each team solve connectivity independently? The second path is how point-to-point sprawl accumulates, one reasonable-seeming decision at a time.
3. Are your APIs versioned and governed with the discipline of a product — with a deprecation policy, a developer portal, and defined consumers — or are they informal interfaces that break silently when someone changes them? The gap between these two states is usually the gap between an integration architecture that scales and one that becomes the organisation's biggest constraint on change.
The next post in this category covers DevSecOps — how security moves from a final gate before deployment to an engineering discipline embedded throughout the delivery pipeline these APIs travel through.
