---
published: true
layout: post
title: 'Trappings of Individual API Patterns and the Benefits of a Diverse API Toolbox'
image: https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/trappings-of-individual-api-patterns-and-the-benefits-of-a-diverse-api-toolbox.png
date: 2026-10-09
author: Kin Lane
tags:
  - API Design
  - REST
  - GraphQL
  - MCP
  - Events
  - Education
  - Literacy
  - APIs
---
One thing you see in a lot of the storytelling around APIs over the years is that people easily get trapped within the creative confines of a single API design pattern. Some of these trappings are of our own doing, where other times it is out of our control within the places we work. Regardless, the quickest way to break out of the limitations of a single API design pattern is to read and learn, but also to play around with and onboard with the different APIs available across different industries and sectors.

REST is definitely the largest API design prison out there, which simultaneously triggers many people to assemble a single API design prison around their reality to avoid even having to properly learn about REST API design patterns. REST is the simplest, cheapest, and most ubiquitous API design pattern out there. In response to this, you see new design patterns emerge like GraphQL and MCP to help people "break free" or "avoid" REST. People get so passionate and dogmatic about their API design pattern of choice, they often neglect to see that their API design pattern is often much older and has been around a lot longer than they are aware of. But with a shiny new name, a fresh wave of venture capital, and a bullhorn in the echo chamber, people are good at locking themselves into a single pattern.

I see this reality as a result of vendorism, and a lack of fundamental education and literacy regarding HTTP and API fundamentals. People are given a single directive involving a single API pattern and they get wound up and set loose. Without doing due diligence on what is already out there. Without talking to domain experts about what is already out there. And often not even talking to customers (or listening to them) about what they have already invested in. I like to pick on GraphQL and MCP in these stories, but honestly I have seen every API pattern suffer from this problem. It is less about the patterns than it is about how we do business in the tech sector, and how we invest in education. Whatever the root cause is, it is damaging to be locked into a single pattern, and you will find it liberating to possess a diverse API toolbox in your work.

When it comes to integrations, whatever your application, there is not a single API design pattern to rule them all. Even within a single application, it can help immensely to adjust your interface to meet the needs of your consumers over time. You might start with one API pattern and evolve into another. You might not need events early on, but you will once you scale. You might be better off starting with a graph, then investing in specific resources, while you also shape what events are emitted. When you change projects, products, teams, or jobs, you will be much better off if you possess a diverse API toolbox rather than being locked into a single set of protocols and patterns. It can be comfortable to stick to what you know. However, you have over 25 years of API patterns being laid down on top of the web to choose from. Yes, the AI application is dominating the conversation today, but tomorrow might be very, very different. Pick your head up and take a look at the other API patterns out there today. You never know what you might learn.