AWS API Gateway: A Brief History

To fully understand AWS API Gateway, let’s first understand the concept of API management and how API Gateways formed.

The Origin Story

In the early 2000’s the concept of API management began to take shape with the rise of Service-Oriented Architecture. More and more companies needed ways to manage and secure their interfaces, leading to the early versions of API Gateways.

To most readers, these early versions of API gateways would appear different from the REST API Gateways you recognize today. In the past, they were management tools to organize and secure SOAP services.

What is SOAP?

SOAP or Simple Object Access Protocol is a protocol used for exchanging structured information. SOAP relies on XML for its messaging format and uses different Application Layer protocols like HTTP, SMTP or TCP to transmit these XML messages.

The primary goal of SOAP was to define a method of communication between software applications that were running on potentially different operating systems and programming languages.

SOAP was widely used in industries that required strict security and communication standards like financial services, telecommunications and healthcare. (Some of these industries still use SOAP today)

Here’s a short example of a SOAP Request:

First we have a SOAP envelope, a header (optional) and a body with the actual request data:

POST /StockPriceService HTTP/1.1
Host: www.example.com
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://www.example.com/GetStockPrice"

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <soap:Body>
    <GetStockPrice xmlns="http://www.example.com/stock">
      <TickerSymbol>AAPL</TickerSymbol>
    </GetStockPrice>
  </soap:Body>
</soap:Envelope>

Then the server processes the SOAP request and returns back a SOAP response with the SOAP envelope, header (optional), and a body with the response data.

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <soap:Body>
    <GetStockPriceResponse xmlns="http://www.example.com/stock">
      <GetStockPriceResult>
        <Price>150.50</Price>
      </GetStockPriceResult>
    </GetStockPriceResponse>
  </soap:Body>
</soap:Envelope>

One difference between a SOAP request and its RESTful successor is that SOAP generally used HTTP POST for sending messages. The specific action or method being requested is encapsulated within the SOAP envelope, not implied by the HTTP verb. That’s why SOAP can also use other transport protocols like SMTP.

The Rise of REST APIs

During the mid 2000s REST (Representational State Transfer) APIs started to gain lots of traction for their simplicity over SOAP.

REST APIs were stateless, made use of HTTP methods explicitly, and had the ability to use JSON for data representation. This made them much lighter and faster compared to SOAP.

Here’s a short example of a REST API call:

First, the client makes a HTTP GET request:

GET /books HTTP/1.1
Host: api.bookstore.com
Accept: application/json

The server then processes the request and returns with the data in JSON format along with a status code of 200 OK:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 123

[
  {
    "id": 1,
    "title": "Book1",
    "author": "Sample Author1",
    "year": 2022
  },
  {
    "id": 2,
    "title": "Book2",
    "author": "Sample Author2",
    "year": 1980
  }
]

These advancements marked a period of dedicated API management solutions, which included API Gateways as the key component.

The Turning Point

In 2010, the mobile app market experienced a dramatic surge, prompting companies to develop backend services to support this expanding ecosystem.

These backend services gave rise to micro-service architecture, which increased the complexity and volume of API usage.

This turning point made it essential for API Gateways to become versatile enough to provide a single point of entry for managing, securing and routing these API calls.

AWS API GATEWAY

In 2015, AWS launched its own version of an API Gateway. It was aimed at providing developers with an easy way to expose their backend services.

This Gateway allows you to support a wide array of API types, including REST, SOAP, WebSocket and HTTP APIs. This allows you, as a developer, to create all encompassing API-driven solutions. It provides you the flexibility to choose your preferred standards and protocols while benefitting from the robust features AWS API Gateway offers.

This style of middleware allows you to fine tune things like traffic management, authorization and access control, monitoring, and API version management.

Moreover, AWS API Gateway seamlessly integrates with other AWS services, such as AWS Lambda, enabling serverless architectures that can scale automatically with demand.

In essence, AWS API Gateway ensures your API-centric solutions in the cloud are future-proof. This aligns with the new trends in software development towards microservices and cloud-native architectures, where AWS API Gateway plays a critical role in facilitating these modern approaches to building and deploying applications.