We usually describe an API as a bridge.
One system has some data.
Another system wants that data.
The API sits between them and says:
“You can talk to each other now.”
It is a useful metaphor.
It is also incomplete.
An API is not merely a bridge between software systems.
An API is an economic mechanism.
It determines who can participate in a platform, what they can build, what resources they can access, how quickly they can innovate, what they have to pay, and sometimes even which businesses are possible in the first place.
This is why some APIs become infrastructure.
They stop being “features” and become markets.
Developers build businesses around them. Startups depend on them. Entire industries integrate them into their workflows. Entrepreneurs who never met the API provider personally can generate revenue because a few HTTP endpoints exist somewhere on the internet.
That is a fascinating transformation.
A few lines of code can become an economic relationship.
Consider what happens when a company exposes something through an API.
Before the API exists, the company might have a capability locked inside its own organization.
After the API exists, that capability becomes programmable.
And programmable things can be composed.
Composable things can become products.
Products can become businesses.
Businesses can create markets.
Markets create economies.
That is the deeper story of APIs.
The API Is an Economic Boundary
Software architecture is full of boundaries.
We have processes.
Services.
Modules.
Databases.
Networks.
Authentication layers.
APIs.
These boundaries are usually discussed in technical language.
But every boundary has economic consequences.
Suppose Company A owns a payment infrastructure.
Without an API, the infrastructure may only serve Company A's own applications.
Company A has a capability.
With an API, that capability can potentially serve thousands of external developers.
Now something interesting happens.
Company A is no longer simply building software.
It is leasing access to infrastructure.
The API becomes a programmable doorway into the company's capabilities.
The economic relationship might look like:
Developer
|
| API Request
v
+----------------+
| API |
+----------------+
|
v
+----------------+
| Infrastructure |
+----------------+
|
v
Economic Value
The developer doesn't need to own the infrastructure.
They don't need to build payment rails.
They don't need to operate data centers.
They don't need to negotiate directly with banks.
They don't even need to understand the entire underlying system.
They simply consume a capability.
This is one of the most powerful ideas in modern software.
APIs turn infrastructure into something that can be rented through code.
APIs Reduce the Cost of Starting a Business
Think about what it meant to build a software company twenty years ago.
You needed servers.
You needed networking.
You needed databases.
You needed payment infrastructure.
You needed email systems.
You needed authentication.
You needed analytics.
You needed monitoring.
You needed complicated integrations.
You needed specialists.
Today, much of that infrastructure can be accessed through APIs.
You can call an authentication API.
You can call a payment API.
You can call a mapping API.
You can call a messaging API.
You can call an AI API.
You can call a cloud storage API.
You can call an analytics API.
Suddenly, a small team can assemble an application from capabilities created by thousands of engineers elsewhere.
This changes the economics of entrepreneurship.
The startup no longer has to build everything.
It can compose.
And composition is economically powerful because it dramatically lowers the cost of experimentation.
Imagine a developer in Lusaka building a logistics application.
They don't necessarily need to construct an entire payment system from scratch.
They don't need to build mapping infrastructure from scratch.
They don't need to create an email delivery network.
They don't need to train a large language model.
They can combine APIs.
The architecture might look like:
+----------------+
| Logistics App |
+-------+--------+
|
+--------------+--------------+
| | |
v v v
Payments Maps Messaging
API API API
| | |
v v v
Payment Location Delivery
Network Services Platform
The developer is effectively assembling an economy from programmable components.
That is much bigger than “integration.”
APIs Create Markets for Capabilities
An API takes a capability and makes it consumable.
That capability could be:
- payments
- identity
- search
- translation
- geolocation
- communication
- artificial intelligence
- financial data
- logistics
- storage
- analytics
- verification
- commerce
Once exposed through an API, that capability becomes something other people can build upon.
This is essentially a marketplace.
Not necessarily a marketplace where people browse products visually.
A marketplace where machines negotiate capabilities programmatically.
That distinction matters.
Traditional marketplaces might look like:
Buyer → Marketplace → Seller
API marketplaces look more like:
Application → API → Capability Provider
The transaction happens through software.
And sometimes it happens millions of times per day.
A request is made.
A service responds.
Usage is measured.
Billing happens.
Value moves.
The API has become part of an economic machine.
The Developer Is Often the Customer
One of the most interesting shifts in API economics is that the person using the product may not be the final consumer.
The developer is often the customer.
This creates a strange chain.
Imagine:
API Provider
|
v
Developer
|
v
Startup
|
v
End User
The API provider sells infrastructure to the developer.
The developer uses the infrastructure to build a product.
The startup sells that product to users.
The end user may never know that the API exists.
Yet the API is part of the product's economic foundation.
This creates what we might call indirect monetization.
An API doesn't necessarily need millions of direct users.
It may only need thousands of developers who build products used by millions of people.
That leverage is enormous.
One API Call Can Represent an Economic Transaction
Consider a payment API.
A request might look conceptually like:
POST /payments
With some payload:
{
"amount": 100,
"currency": "ZMW",
"customer": "customer_123"
}
Technically, this is just an HTTP request.
Economically, it could represent:
- a customer buying food,
- someone paying school fees,
- a business paying an employee,
- a tourist booking accommodation,
- a farmer purchasing equipment,
- a company paying a supplier.
The API call is tiny.
The economic event is not.
This is one of the strange properties of software.
Small technical actions can represent enormous real-world consequences.
A database insert can represent a loan.
An API request can represent a purchase.
A webhook can represent a completed transaction.
A token can represent access to a service.
A successful HTTP response can trigger an entire supply chain.
The protocol is small.
The economy behind it is huge.
APIs Create Network Effects
APIs can also create network effects.
Suppose an API has ten useful integrations.
Developers build applications around those integrations.
More developers join.
The platform gains more capabilities.
More capabilities attract more developers.
More developers create more applications.
More applications attract more users.
More users create more demand.
The cycle continues.
More APIs
↓
More Developers
↓
More Applications
↓
More Users
↓
More Demand
↓
More Developers
This is why APIs can become strategic assets.
The API itself might look boring.
Perhaps it is just:
GET /users
POST /orders
GET /products
But those endpoints can create an ecosystem.
The important thing isn't the endpoint.
The important thing is what other people can build because the endpoint exists.
The Real Product Is Often the Ecosystem
A company might think its API product is:
“We provide access to our data.”
But developers might see something completely different.
They see:
“I can build an entirely new business without recreating this infrastructure.”
That difference in perspective is important.
The API provider sees a service.
The developer sees a building block.
The entrepreneur sees a business opportunity.
The customer sees a useful application.
The investor sees a market.
Same API.
Different economic interpretations.
This is why API design is partly product design.
And product design is partly economic design.
Good APIs Create Optionality
One of the most underrated economic properties of APIs is optionality.
When a company exposes a capability through a stable API, it gives developers options.
They can experiment.
They can integrate.
They can automate.
They can create products that the original API provider never imagined.
This is extremely powerful.
The API provider cannot predict every possible use case.
And it doesn't have to.
Instead, it provides primitives.
Developers discover the possibilities.
This resembles programming language design.
A programming language doesn't tell you exactly which application you must build.
It provides primitives.
Variables.
Functions.
Types.
Loops.
Memory.
Concurrency.
The programmer composes them into something new.
APIs work similarly at a higher architectural level.
They provide economic primitives.
API Design Is a Form of Economic Design
Consider an API with strict limits.
Maybe developers can make:
100 requests per hour
Another API allows:
1,000,000 requests per hour
These are not merely technical configurations.
They influence what businesses can exist.
A rate limit can prevent a real-time application from being viable.
A generous rate limit can enable it.
Pricing can determine whether a startup can afford to launch.
Authentication requirements can determine whether integration takes five minutes or five months.
Documentation can determine whether thousands of developers adopt the platform or abandon it.
Latency can determine whether a service can power real-time applications.
Reliability can determine whether businesses trust it.
Backward compatibility can determine whether companies build long-term dependencies.
API design therefore shapes economic possibility.
The API Contract Is a Business Contract
We often talk about APIs as technical contracts.
For example:
GET /customers/{id}
returns:
{
"id": 42,
"name": "Derek"
}
But the real contract is deeper.
The developer is implicitly asking:
- Will this endpoint remain available?
- Will the response shape remain stable?
- Will authentication continue working?
- Will pricing change?
- Will rate limits change?
- Will latency remain acceptable?
- Will the provider maintain the service?
- Will breaking changes be announced?
- Will my application still work next year?
These are business questions disguised as engineering questions.
When a developer builds deeply on your API, they are making an investment.
They are creating switching costs.
They are building dependency.
They are trusting your company.
That means API stability becomes a form of economic credibility.
Documentation Is Economic Infrastructure
Bad documentation doesn't merely annoy developers.
It destroys economic value.
Imagine an API with incredible capabilities but terrible documentation.
Developers encounter:
Authentication failed.
No explanation.
They search forums.
They read outdated examples.
They guess.
They retry.
Eventually they give up.
The API technically works.
But economically, it failed.
Now compare that with:
POST /payments
Required headers:
Authorization: Bearer <token>
Required fields:
amount
currency
customer_id
Errors:
400 — Invalid request
401 — Invalid credentials
402 — Insufficient balance
409 — Duplicate transaction
The second API is easier to understand.
Ease of understanding reduces integration costs.
Reduced integration costs increase adoption.
Increased adoption increases economic activity.
Therefore:
Documentation is not just developer experience. It is economic infrastructure.
APIs Create Developer Economies
Some of the world's most interesting software ecosystems are effectively developer economies.
Developers build:
- plugins,
- extensions,
- SaaS applications,
- mobile applications,
- automation tools,
- analytics products,
- integrations,
- consulting businesses,
- developer tools,
- entire startups.
around APIs.
The original company doesn't necessarily build those products.
Its ecosystem does.
This creates a fascinating distribution of innovation.
The platform provides the primitives.
The ecosystem provides the creativity.
That can be more powerful than trying to build everything internally.
Open APIs Can Democratize Infrastructure
There is also a deeper social dimension.
APIs can democratize access to infrastructure.
Historically, powerful infrastructure was expensive.
If you wanted to build a large-scale financial service, telecommunications platform, mapping system, or analytics platform, you needed substantial capital.
APIs can lower that barrier.
A small developer can access capabilities previously available only to large companies.
This does not eliminate inequality.
Infrastructure providers still control important resources.
But APIs can redistribute access.
The interesting question becomes:
Who gets to build?
And increasingly, the answer can be:
Whoever can program against the infrastructure.
This is why API availability can have consequences beyond software engineering.
It can affect entrepreneurship.
Education.
Financial inclusion.
Research.
Media.
Commerce.
And economic mobility.
The African Opportunity
This is particularly interesting for African technology ecosystems.
Africa does not need to recreate every piece of global infrastructure independently.
That would be enormously expensive.
Instead, African developers can compose.
A developer can combine:
Payments API
+
Mobile Money API
+
Maps API
+
Messaging API
+
Identity API
+
AI API
and create something locally relevant.
The real innovation may not be inventing every primitive.
It may be composing global primitives with local knowledge.
This is a powerful model.
Imagine someone building agricultural software for Zambia.
The application could integrate:
Weather
+
Payments
+
Mobile Money
+
Maps
+
Market Prices
+
AI
+
Logistics
The individual APIs aren't necessarily African.
But the product can be.
The value comes from understanding the local problem and composing infrastructure around it.
This is one reason API ecosystems can accelerate emerging technology markets.
They reduce the amount of infrastructure that entrepreneurs must reinvent.
APIs Are Composability Machines
The deeper technical idea here is composability.
A good API is not merely usable.
It is composable.
Suppose you have:
Identity API
and:
Payment API
and:
Notification API
and:
Analytics API
Individually, each is useful.
Together, they can create a financial platform.
This is similar to mathematics.
Numbers become powerful because operations can be composed.
Functions become powerful because functions can be composed.
Software becomes powerful because services can be composed.
Economies become powerful because capabilities can be composed.
The API is the connective tissue that makes this possible.
APIs Turn Software Into Lego
There is a useful analogy here.
Think about LEGO.
A brick isn't particularly impressive.
But if the bricks have standardized connection points, millions of combinations become possible.
APIs work similarly.
The endpoint is a brick.
The contract is the connection mechanism.
The developer is the builder.
The application is the structure.
The ecosystem is the city built from those structures.
The important property isn't the individual brick.
It is the standardized interface between bricks.
This is why APIs are so powerful.
They standardize composition.
Standards Create Markets
Whenever interfaces become standardized, markets tend to become easier to build.
Consider what happens when everyone agrees on:
HTTP
JSON
OAuth
Webhooks
OpenAPI
REST conventions
Not every API uses every one of these perfectly, but common conventions reduce cognitive overhead.
A developer who understands one API can often understand another.
That creates portability of knowledge.
And portable knowledge has economic value.
If developers had to learn an entirely different conceptual model for every service, integration would be expensive.
Standards reduce that friction.
Reduced friction increases participation.
Participation increases markets.
So standards are not just technical conveniences.
They are economic accelerators.
APIs Can Become Moats
There is another side to this story.
APIs can create economic power.
Once thousands of applications depend on an API, the provider gains influence.
Consider an application that depends on several external services:
Application
├── Payment API
├── Email API
├── Maps API
├── AI API
├── Storage API
└── Identity API
If one provider suddenly changes its pricing or removes an endpoint, the application may have to change.
This creates dependency.
Dependency creates switching costs.
Switching costs can create competitive moats.
Therefore, APIs don't just create ecosystems.
They can also create platform power.
The same interface that enables innovation can create concentration.
That contradiction is worth thinking about.
The API Economy Has a Hidden Tax
Every dependency introduces a cost.
Suppose your application depends on ten APIs.
You now have ten external systems to monitor.
Ten authentication mechanisms.
Ten billing relationships.
Ten sources of latency.
Ten potential outages.
Ten versioning strategies.
Ten sets of terms and conditions.
Your architecture has become more capable.
But also more distributed.
This is the API economy's hidden tax.
More APIs
↓
More Capabilities
↓
More Composability
↓
More Complexity
The same abstraction that makes development easier can make system architecture harder.
This is why experienced engineers worry about dependency graphs.
Your application is no longer a single system.
It is a network of systems.
And your API dependencies become part of your operational reality.
API Failures Become Economic Failures
Suppose a payment provider goes down.
The application may still be running.
The database may still be healthy.
The servers may still have CPU capacity.
The frontend may still load.
But customers cannot pay.
The API outage becomes a business outage.
This is why distributed systems engineering matters so much.
Retries.
Timeouts.
Circuit breakers.
Idempotency.
Caching.
Queues.
Fallbacks.
Observability.
These aren't merely technical patterns.
They protect economic activity.
For example, idempotency is often taught as a distributed systems concept.
But consider:
POST /payment
The client sends the request.
The network times out.
Did the payment happen?
The client doesn't know.
It retries.
Without idempotency, the customer could be charged twice.
Now a tiny distributed-systems problem has become a financial problem.
The technical architecture directly protects economic trust.
APIs Create Invisible Labor Markets
There is another phenomenon hiding inside API ecosystems.
APIs create demand for people who know how to integrate them.
Entire consulting businesses exist around:
- API integration,
- cloud migration,
- payment integration,
- data integration,
- API security,
- developer experience,
- middleware,
- automation,
- system integration.
This means APIs create jobs beyond the companies that operate them.
The economic footprint of an API can therefore be much larger than its revenue.
A company might earn money from API subscriptions.
But developers, consultants, agencies, startups, and service providers may earn money because the API exists.
The API becomes an economic primitive.
APIs Are Becoming Interfaces for Artificial Intelligence
Now consider the rise of AI.
AI systems themselves increasingly interact with software through APIs.
An AI model might call:
Search API
Payment API
Calendar API
Database API
Maps API
Email API
CRM API
This changes the role of APIs again.
Historically:
Human → Application → API
Increasingly we can imagine:
Human
↓
AI Agent
↓
API
↓
Real-world action
The API becomes the action layer for software intelligence.
An AI model can reason about what needs to happen.
The API allows it to happen.
This could make APIs even more economically important.
Because intelligence without action is limited.
An AI system that can understand a problem is useful.
An AI system that can execute workflows across APIs is an economic actor.
That distinction is enormous.
The API Becomes a Machine-Readable Economy
Imagine an AI agent tasked with:
“Find me the cheapest flight, book a hotel, arrange transportation, and send the itinerary.”
The agent might interact with:
Flight API
Hotel API
Transport API
Payment API
Messaging API
The agent isn't simply retrieving information.
It is coordinating economic activity.
The APIs become the interfaces through which software participates in markets.
That suggests something profound.
The future internet may not only be a web of documents.
It may increasingly be a web of capabilities.
Machines won't just read pages.
They will invoke services.
They will negotiate.
They will transact.
They will coordinate.
APIs are the machinery underneath that future.
The Most Valuable API May Be the One Nobody Notices
The best infrastructure often becomes invisible.
You don't think about DNS when opening a website.
You don't think about TCP when sending data.
You don't think about database transactions when clicking “Buy.”
You don't think about the payment API when purchasing something online.
That invisibility is a sign of successful abstraction.
The API disappears.
The capability remains.
This is the ultimate goal of infrastructure:
Make complexity disappear without making capability disappear.
The user sees:
Buy Now
Behind that button might be:
Frontend
↓
API Gateway
↓
Authentication
↓
Order Service
↓
Payment API
↓
Fraud Detection
↓
Banking Infrastructure
↓
Notification API
↓
Analytics
The button is simple.
The economy behind it is not.
APIs Change What “Building a Company” Means
The old mental model of a software company was:
Build the application.
The newer model is:
Compose capabilities.
A modern startup may own relatively little physical infrastructure.
Its competitive advantage may come from:
- workflows,
- data,
- brand,
- distribution,
- domain expertise,
- user experience,
- algorithms,
- community,
- proprietary APIs,
- orchestration.
The company is effectively sitting on top of a massive stack of external capabilities.
This creates a strange situation.
A tiny startup can operate at enormous scale.
But it can also inherit enormous complexity.
The company may be five people.
Its dependency graph may contain hundreds of services.
That is the paradox of modern software.
The organization becomes smaller while the system becomes larger.
APIs Turn Infrastructure Into Liquidity
There is an interesting economic analogy here.
Liquidity makes assets easier to exchange.
APIs make capabilities easier to consume.
Before an API:
“We have a payment system.”
After an API:
“You can invoke payment capability programmatically.”
The capability becomes more liquid.
It can move across applications.
It can be incorporated into workflows.
It can be sold per request.
It can be bundled into products.
It can be distributed globally.
This is why API-first companies can scale differently from traditional software businesses.
Their product isn't just software.
Their product is programmable access to capability.
The Economics of “As a Service”
We have seen this pattern everywhere:
Software as a Service.
Infrastructure as a Service.
Platform as a Service.
Database as a Service.
Payments as a Service.
Identity as a Service.
AI as a Service.
The common idea is simple:
You don't own the capability. You consume it.
APIs are often the mechanism that makes this possible.
They convert ownership into access.
And access can be priced.
Per request.
Per user.
Per transaction.
Per gigabyte.
Per token.
Per minute.
Per month.
This creates completely new pricing models.
APIs Create Usage-Based Economies
Traditional software often asks:
“How many copies did you sell?”
API businesses can ask:
“How much did you use?”
That distinction changes incentives.
If you pay per API call, the provider benefits when your application grows.
Your success becomes partially connected to their revenue.
This can create alignment.
A startup grows.
API usage grows.
API revenue grows.
The API provider becomes economically attached to the startup ecosystem.
This is a powerful business model.
But it also creates risk.
If your application suddenly becomes successful, your infrastructure bill can grow dramatically.
The same API that helped you scale can become one of your largest expenses.
APIs Don't Just Connect Businesses
They connect business models.
A payment API connects commerce to software.
A mapping API connects geography to software.
An AI API connects intelligence to software.
A messaging API connects communication to software.
A logistics API connects physical movement to software.
This is where APIs become truly interesting.
They are not simply connecting databases.
They are connecting different economic domains.
Finance
↕
Software
↕
Commerce
↕
Logistics
↕
Communication
↕
AI
APIs are the interfaces between these worlds.
The Future Belongs to Composable Economies
The next generation of software may be defined less by standalone applications and more by ecosystems of interoperable capabilities.
Imagine a developer building a business by composing:
Identity
+
Payments
+
AI
+
Search
+
Logistics
+
Messaging
+
Analytics
No single provider owns the entire experience.
The developer becomes the orchestrator.
The user experiences one product.
Underneath it is an economy of APIs.
This is similar to how modern cities work.
You don't build your own electricity grid before opening a restaurant.
You connect to existing infrastructure.
You don't build your own telecommunications network.
You connect to existing networks.
You don't build your own banking system.
You connect to financial infrastructure.
Software is moving in the same direction.
Infrastructure becomes composable.
Capabilities become rentable.
Interfaces become programmable.
But There Is a Problem: Who Owns the Interfaces?
If APIs become economic infrastructure, ownership becomes important.
Who controls the API?
Who controls pricing?
Who controls access?
Who controls data?
Who controls authentication?
Who can revoke access?
Who can change the contract?
These aren't purely technical questions.
They are questions of economic power.
An API provider can potentially become a gatekeeper.
Developers might build entire industries on top of a platform they don't control.
That makes API governance increasingly important.
A healthy ecosystem needs trust.
It needs predictable pricing.
It needs versioning policies.
It needs transparent deprecation.
It needs security.
It needs portability.
It needs alternatives.
Otherwise, an open-looking API ecosystem can become a collection of centralized choke points.
API Design Is Ultimately About Trust
At the deepest level, an API is a promise.
You send something.
The system does something predictable.
You receive something predictable.
That predictability creates trust.
Trust allows dependency.
Dependency allows investment.
Investment allows ecosystems.
Ecosystems create economic activity.
So the chain is:
API Contract
↓
Predictability
↓
Trust
↓
Dependency
↓
Investment
↓
Ecosystem
↓
Economy
This is why API reliability matters so much.
A developer isn't just integrating an endpoint.
They are betting part of their business on that endpoint continuing to exist.
The Best APIs Become Boring
This might sound strange.
But the most economically valuable APIs are often boring.
They don't constantly change.
They don't surprise developers.
They don't require heroic engineering.
They simply work.
Request.
Response.
Predictable error.
Stable contract.
Good documentation.
Reasonable latency.
Reliable infrastructure.
That is beautiful.
In software, boring infrastructure is often a sign of maturity.
The API becomes invisible.
Businesses grow on top of it.
Nobody celebrates the API.
They celebrate the businesses it enabled.
And perhaps that is the highest compliment infrastructure can receive.
APIs Are Economic Infrastructure
We should therefore stop thinking about APIs as merely technical interfaces.
They are infrastructure for digital economies.
They determine:
- who can access capabilities,
- how cheaply they can access them,
- how quickly they can innovate,
- how systems can compose,
- how businesses can integrate,
- how markets can form,
- how developers can participate,
- and how software can interact with the physical economy.
An API is a technical contract.
But it can also be:
a business model,
a distribution channel,
a platform,
a marketplace,
a developer ecosystem,
a competitive moat,
an infrastructure layer,
and eventually an economic network.
That is why API architecture deserves more serious thinking.
When you design an API, you aren't merely deciding whether the endpoint should be:
GET /users
or:
GET /customers
You are deciding how another organization will interact with your capabilities.
You are deciding what can be automated.
You are deciding what can be composed.
You are deciding what businesses can be built.
You are deciding what kinds of economic activity your system permits.
That is much bigger than software design.
The API Is the New Railroad
There is an old lesson from infrastructure history.
When railroads were built, they didn't merely transport people.
They created entire industries around transportation.
Factories emerged near railways.
Cities grew around stations.
Markets expanded.
Supply chains changed.
Businesses became geographically connected.
The infrastructure created economic possibilities that did not previously exist.
APIs can play a similar role in the digital economy.
They connect capabilities instead of cities.
They connect databases instead of warehouses.
They connect services instead of rail stations.
They connect developers instead of merchants.
But the fundamental principle is similar:
Infrastructure creates possibilities.
And possibilities create economies.
Final Thought
The next time you see an API, don't just see:
GET /something
See the economic machine behind it.
See the developer who can build a startup because that endpoint exists.
See the customer who can access a service because the startup exists.
See the infrastructure provider earning revenue from usage.
See the integrations creating new businesses.
See the jobs created around the ecosystem.
See the data flowing between organizations.
See the financial transactions triggered by software.
See the AI agents that may eventually invoke those APIs autonomously.
An API looks like a technical interface.
But underneath the JSON is a much bigger idea.
It is a mechanism for turning capabilities into composable economic resources.
That is why APIs don't just connect systems.
They connect businesses.
They connect markets.
They connect developers.
They connect industries.
They connect ideas to execution.
And eventually, they connect software itself to the economy.
The most important question about an API is therefore not:
“What does this endpoint return?”
The more interesting question is:
“What becomes possible because this endpoint exists?”
Because that is where the real value lives.
Not inside the request.
Not inside the response.
But inside everything that other people can build between them.
APIs are not merely the language machines use to talk to each other.
They are becoming one of the languages economies use to compose themselves.
Top comments (0)