## Introduction
Have you ever heard someone say that there is no difference between a Web Application and an [API](/blog-post/what-are-apis/)?  Or, that there is no difference between a Web Application Security and [API Security](/blog-post/nissan-leaf-api-security-who-owns-api-security-and-how-much-security-is-enough/)? The latter seems to be a very common notion within segments of the development community whose members are desperate to find some level of simplicity within a sea of chaos and complexity that is modern application development. I sympathize, but pose to you that this is not the case; this post is going to explore the evolution of web application architecture from a traditional web applications to modern Single Page Applications (SPAs) invoking multiple APIs advertised on an API Gateway with disparate API Providers (controlled by different organizations and following different standards) on the back-end.

## Evolution of Web Application Architecture
Let’s look at how Web Applications have evolved since the late 1990s.  I’m over-simplifying it (for my own purposes) and examples that blur the lines between one or more of these are likely ubiquitous, but what I am really interested in is how the evolution has impacted the application security model in use–we’ll get to the security aspects soon enough. There are four different basic web architectures that are important for this discussion:

1. The traditional Web Application
2. A Single Page Application (SPA) that makes calls to a single, dedicated API (though, in the beginning it wasn’t called an API) advertised on a Web Server.
3. SPA interacting directly with multiple API Providers (running on different Web Servers).
4. SPA interacting with multiple APIs advertised on an API Gateway

### The Traditional Web Application
![Traditional Web app](https://cdn.levvel.io/blog_content/Diagram-1-Traditional-Web-Application-1.jpg)
Figure 1: The Traditional Web Application Architecture

The traditional web application (running in a web browser) is composed of statically or dynamically generated web pages that make HTTP(S) calls to a web server. The web server returns a complete web page for every request.  Remember the good-old days, when things were simple?  This is a very different model from the more recent SPA model that makes API calls that return a simple JSON text with the data needed to render the next page or changes to a portion of the current page. All HTTP(S) calls are almost certainly made to the same web server host that the original content was loaded from.

### Early Single Page Application invoking early API concept:
![Diagram-2-Single-Page-Responsive-Application-or-SPA](https://cdn.levvel.io/blog_content/Diagram-2-Single-Page-Responsive-Application-or-SPA.jpg)

Figure 2: The Single Page Application (SPA) invoking an API (in an earlier form).

After this original web application design, more and more interactivity began to appear in web applications. Eventually leading to a style of communication with the web server, still using HTTP(S), that simply returned the needed data rather than  an entire web page. But, these calls to the web server were most likely still made to the same web server that served up the original static content and Javascript that  made up the web application.  This type of web application became known as a Responsive Web Application and more recently a Single Page Application (SPA). The SPA makes a series of these calls to the web server in response to the user interacting it. Around 2005, the term [AJAX](https://en.wikipedia.org/wiki/Ajax_%28programming%29) (Asynchronous Javascript And XML) was coined for this type of web application communication. This was the earliest example of APIs; although, at this point, the term API was not yet used. And, there was very little reuse of those API-like constructs–though, it evolved quickly and the reuse did come.


### Single Page Application + Multiple API Endpoints:
![Single Page Application](https://cdn.levvel.io/blog_content/Diagram-3-Single-Page-Application-SPA-Multiple-API-Endpoints.jpg)
Figure 3: Single Page Application (SPA) + Multiple API Endpoints

The next Web Application Architecture is a SPA application that makes API calls to multiple, distinct API providers. This is very similar to the last type of web application, but now there is more than one web server the client is interacting with. The various APIs may be advertised by the same organization or by multiple organizations. The situation becomes particularly noteworthy when the back-end APIs belong to different organizations.

Somewhere around this time, in the API realm (on the Web Server-side), APIs began being shared by multiple Web Applications (API Consumers). We also began to see API Consumers emerging that were not Web Applications–think Business-to-Business (B2B) Integration and system-to-system integration.  Here we see the server-side component of Web Applications expand into the use cases we have today. Not long after that, the first iPhone was released and these early APIs began being used with Mobile Apps.

### SPA as API Consumer, API Gateway, and N API Providers
![SPA as API Consumer](https://cdn.levvel.io/blog_content/Diagram-4-N-API-Consumers-Multiple-types-of-consumers-N-API-Providers.jpg)
Figure 4: N API Consumers, Multiple types of consumers; N API Providers with API Gateway

Now, things start getting interesting. In the next web application architecture example, we have SPA applications interacting with multiple, distinct APIs that are advertised on a common API Gateway.  In fact, API Consumers could now be SPAs, Mobile Apps, SaaS solutions, Business Partners (B2B Integration), and random third-party systems. The APIs advertised on this API Gateway are home grown (cloud or on-premise hosted), Commercial Of the Shelf (COTS) APIs, (Software as a Service) SaaS solutions, Business Partner-provided, and third-party APIs.

The basic architecture of a Web Application has changed a lot in twenty years. But, the same basic building blocks are there.

Maybe the Web Server components of the first three types of Web Applications have some type of reverse proxy or security gateway in front of them.  This doesn’t change the underlying architecture.  This is an application of the Layered System Constraint described by the [REST Architectural Style](/blog-post/what-are-apis/). Maybe it is just a stand-alone web server (with appropriate levels of HA features enabled)–the details can vary greatly.  But, none of this changes the underlying Message Exchange Patterns–though, the consumer’s interaction with the Identity Provider will likely differ.

## The API Gateway
Now, although, it tends to be unpopular in some circles, the patterns surrounding use cases for the [API Gateway](/blog-post/the-anatomy-of-an-api-management-solution/) start to look a lot like what organizations have done with the [Enterprise Service Bus](http://thinkmiddleware.com/blog01/2012/01/07/what-is-an-esb/) (ESB) and SOAP Web Services. We need to be careful. We do not want the API Gateway to engage in all manner of [ugliness](https://www.infoq.com/presentations/soa-without-esb) that an internal ESB has done. If we define the ESB’s role as protocol transformation, data transformation, and (secure) security integration, which I do, how does that compare to what the API Gateway does?

First, for the API Gateway all protocol activity is HTTP(S)-in/HTTP(S)-out; so, protocol transformation is more-or-less out (maybe it HTTPS-in/HTTP-out).  I consider SOAP<->REST translation to be an aspect of data transformation, not protocol transformation. To that end, the API Gateway is going to perform various data transformations. But, it will mostly involve JSON and XML–from a practical standpoint, I will refrain from saying it is only these.  Preferably, there would be more JSON than XML. And, lastly, security integration. Large, security-concious organizations spend a lot of time on their internal ESBs. A similar pattern will emerge on their API Gateway.  From previous [posts](/blog-post/nissan-leaf-api-security-who-owns-api-security-and-how-much-security-is-enough/), we’ve explored standardizing on OpenID Connect for the front-side of the API Gateway (and any other components that we control that are capable of supporting it), but there will be many actors that we have no control over and do not follow a standard security model–organizations are going to have to deal with that. They could use OAuth 1.x, OAuth 2.0, Basic Auth, subscription keys, mutual auth SSL, SAML (weird? I worked with a client not to long ago that used SAML 2.0 Bearer Tokens for internal REST/APIs), JSESSIONID cookie, custom token, etc.

The bottom line: there are similar patterns between the ESB and API Gateway, but what is done on the API Gateway must remain in the realm of XML and JSON.  To keep it simple: no protocol transformations. And, security integration as necessary to make it work (but, still be secure).

In the next part of this series, we will analyze how application security works in each of these Web Application Architectures.

API Security vs. Web Application Security Part 1: A Brief History of Web Application Architecture

Exploring the evolution of web application architecture from a traditional web applications to modern Single Page Applications.

API Security vs. Web Application Security Part 1: A Brief History of Web Application Architecture

API Security vs. Web Application Security Part 1: A Brief History of Web Application Architecture

Read the Blog