Technology for Decision Makers: Understanding APIs, REST, and MicroServices

APIs power nearly every modern digital experience, from mobile apps to enterprise systems. But the term API has evolved dramatically over the past few decades. What started as a way for software to talk to other software on the same machine has grown into a global ecosystem of interconnected services running across the internet.

This post walks through that evolution — from early local APIs, to SOAP and XML, to REST and JSON, and finally to microservices and service‑oriented architecture. If you’re a technology leader or decision maker, understanding these concepts helps you evaluate systems, plan integrations, and make better architectural choices.

What an API Really Is Today

API stands for Application Programming Interface, but the meaning has broadened over time.

Originally, APIs were simply libraries or system calls that allowed software to interact with the operating system — things like creating files, opening windows, or connecting to a database.

Today, when most people say “API,” they mean a web API: a URL that an application can call over the internet to retrieve or send data.

For example:

• A user visits www.cnn.com to read the news.

• An app might call something like: http://service.domainname.com/Accounts/124411234/Purchase   to retrieve purchase information for a customer.

APIs are now the backbone of modern applications, enabling everything from mobile banking to ridesharing to cloud services.

A Brief History of APIs

Local APIs and ODBC

Before the internet became the default integration layer, APIs lived inside your computer.

A great example is ODBC (Open Database Connectivity) on Windows. ODBC allowed software like Excel to connect to databases such as Microsoft Access or Oracle. Vendors could write drivers to extend ODBC, enabling three different tools to exchange data seamlessly.

This was powerful — but it all happened on a local network.

CORBA: Early Internet‑Scale Integration

As the internet grew, companies wanted to exchange data across organizations. One of the first major standards was CORBA (Common Object Request Broker Architecture).

CORBA enabled secure, direct, code‑based communication between systems. Before CORBA, many companies exchanged data by sending CSV files over SFTP — a slow and error‑prone process.

CORBA was used heavily in B2B environments and in large enterprise systems like SAP Business Objects. But it had major drawbacks:

• Hard to implement

• Difficult to find developers

• Complex, proprietary standards

This complexity set the stage for the next evolution.

SOAP: A Simpler Way to Integrate

Microsoft developers, frustrated with CORBA’s complexity, created SOAP (Simple Object Access Protocol). SOAP was built on technologies developers already understood:

• HTTP

• XML

• SMTP

When .NET and Visual Studio .NET were released, SOAP became a first‑class citizen. It made publishing remote APIs far easier and quickly spread to Java and Apache ecosystems. By the early 2000s, SOAP was widely used for B2B integrations and large websites.

One of SOAP’s biggest advantages was asynchronous calls. Older web technologies loaded data one step at a time — a single‑threaded approach that simply couldn’t scale for sites like Amazon. SOAP allowed multiple operations to run simultaneously, dramatically improving performance.

SOAP’s Weakness: XML

SOAP relied heavily on XML, which was extremely verbose. A simple financial record might require dozens of lines of markup. As data volumes grew, XML became too “chatty,” consuming bandwidth and slowing systems down.

Developers needed something lighter.

JSON Changes Everything

JSON (JavaScript Object Notation) offered a cleaner, more compact way to represent data. The same XML example could be expressed in a fraction of the space using JSON.

This shift paved the way for REST.

REST: A Modern Architecture for APIs

REST — Representational State Transfer — isn’t a protocol. It’s an architectural style that defines how APIs should behave on the internet.

REST emphasizes:

• Resources (like Accounts or Purchases)

• Meaningful URLs

• Standard HTTP actions

For example:

Code

GET    /Accounts/124411234/Purchase
PUT    /Accounts/124411234
PATCH  /Accounts/124411234
DELETE /Accounts/124411234/Purchase

REST commonly uses JSON or binary JSON, but it can also return XML, YAML, CSV, or even HTML.

Typical REST responses include:

• 200 – Success

• 201 – Created

• 401 – Unauthorized

• 403 – Forbidden

• 404 – Not Found

• 429 – Too Many Requests

REST became the dominant API style because it’s simple, scalable, and works naturally with the web.

Microservices and SOA: Scaling Beyond Monolithic Apps

As applications grew more complex, organizations needed ways to break large systems into smaller, reusable components. This led to Service‑Oriented Architecture (SOA) and later microservices.

The Core Idea

Move business logic out of monolithic applications and into independent services that communicate over standard protocols (HTTP, MQTT, etc.).

This allows:

• Faster development

• Easier reuse

• Language‑agnostic systems (Python services talking to Java services talking to C# apps)

• Independent deployment and scaling

Why Microservices Improve Resilience

Microservices are intentionally small and focused. If one service fails, the rest of the system keeps running. Instead of one giant application crashing, you might lose 1% of functionality while 99% stays online.

Why Microservices Are Portable

A well‑designed microservice includes:

• Its code

• Its web server

• Its dependencies

• Its database (or at least its own schema)

This makes it easy to move, copy, or scale.

In fact, starting one of my own Python microservices is as simple as:

Code

python DataLoader.py

That single command launches the web server, database, dependency checks, and request handlers.

A Note on Architecture Opinions

Microservices are one of the most debated topics in software architecture. Two architects can look at the same system and propose completely different microservice boundaries — and both might be valid.

That’s part of what makes the field so interesting.

Wrapping Up

APIs have come a long way — from local system calls, to CORBA, to SOAP, to REST, and now to microservices. Each step in this evolution reflects the same goal: enabling software systems to communicate more efficiently, reliably, and at scale.

For decision makers, understanding these concepts helps you:

• Evaluate vendor claims

• Plan integrations

• Modernize legacy systems

• Build scalable architectures

• Avoid costly mistakes