Evolution of the Web Service Architecture

http://justmobiledev.com/wp-content/uploads/2017/11/web-architecture-evolution.pnghttp://justmobiledev.com/wp-content/uploads/2017/11/web-architecture-evolution.pnghttp://justmobiledev.com/wp-content/uploads/2017/11/web-architecture-evolution.pngEvolution of the Web Service Architecture


Today an incredible variety of different architectures, languages and frameworks to build web applications exist, like .Net, nodejs, Angular or Java Servlets/Server Pages and many more. Time to reflect where they all came from, and how they evolved.

This article discusses the transition from static HTML pages to one-page web applications which have become increasingly popular in the recent years. The article examines which technologies were pivotal in each phase and highlights the pros and cons of each web application architecture.

Static HTML architectures (1980s)


A quarter of a century ago a researcher at CERN, Tim Berners-Lee came up with the building blocks of the web application:

1. A markup language for web-based documents (HTML).
2. A uniform notation scheme for addressing internet resources (URL) and
3. A protocol for exchanging request/response messages across the Internet (HTTP).

With these building blocks the first simple web pages were constructed to make static formatted content and images accessible on the Internet. Although Berner-Lee’s focus was simply to provide a virtual library for content sharing, the building blocks he provided are still used today to build modern web applications.


The web system architecture in this phase was very simple: The client requested a web page from a web server in form of HTTP requests and the web server provided content for the Presentation Layer as static HTML content back to the client. The client’s web browser interpreted the HTML tags and rendered the page.

Pros and Cons

– Simple architecture
– High performance through indexing and caching
– Advantages over traditional client-server systems: No need for installation on the client; light-weight solution; independent of OS platform
– Lack of basic web applications functionality: session management, authorization, personalization, dynamic content
– Difficult to manage change due to replicated layout, styles and formatting
– Poor UI experience
– Limited to browser-based clients
– Application content limited to a single source

Thin-client, Server-driven Web Applications (1990s)


Fueled by the passion for personal publishing and the fascination with the idea of selling goods online, static web sites soon evolved into dynamic web sites in the 1990s.

The web application architecture in this phase was server-centric: The server was responsible for handling requests, retrieving data from the database and generating the user interface. The client browser would merely interpret and render UI content.
The main enablers in this phase were server-side languages such as CGI/Perl and PHP, combined with the new client-side language JavaScript. The combination allowed to overcome the limitations of static HTML and build dynamic content retrieved from relational databases. These simple web applications support JavaScript-driven form validation and event handling and were used to collect user information and built simple shopping cart applications.


The main characteristic of this architecture a server-centric approach in which the web application server was responsible for retrieving data, providing business logic and generating the user interface.

The client was responsible for rendering the UI and for executing JavaScript tasks such as validation, session management, and event processing.

Pros and Cons

– Allowed session management, authorization, personalization
– Increase in dynamic UI experience provided by JavaScript
– Powerful server-side languages were object-oriented and included modules for building more capable applications
– Poor UI experience caused by request/response flow
– Computational overhead on the server-size; scalability issues
– Limited to browser-based clients
– Application content limited to a single source
– Cross-browser compatibility issues

Rich Web Applications (2000s)


The demand for web applications with more responsive user interfaces continued to increase at the beginning of the millennium. In response, myriad of new web browsers appeared on the market: Internet Explorer, Netscape, Safari, Opera, and Firefox – were all released a year apart from each other and outpaced each other in implementing JavaScript functionality and W3 standards.
The main stepping stone on the way to a rich client architecture was provided by a simple technology called Ajax – developed by Microsoft in 1999. Ajax is a JavaScript object that allows browser clients to send asynchronous HTTP requests to the server. The ability to fetch data ‘behind the scenes’ allowed web applications to build dynamic page fragments that responded to user actions without having to reload the complete page from the server.

The way of building web applications came with a number of architectural changes: First, the Ajax clients needed to be able to retrieve data from the server so web application server had to expose the required web service APIs. These web services where often provided with the web service protocol REST, and response data was structured in XML or JSON. Next, due to the Ajax functionality the business layer implementation was now split up between client and server which made development and maintenance more complicated.
In this decade the first MVC-oriented server-side languages emerged, e.g. Java Server Pages, Active Server Pages, and Coldfusion. The main improvement here was the use of reusable HTML templates as well as a separation of HTML view data, business logic, and modeled data which improved maintainability.

In another development large Internet players like Google, Yahoo, and Amazon started offering API services such as Google Maps in the mid 2000s which allowed web developers to build mashup applications that would use data and UI components from different sources. Naturally, the Ajax technology was an excellent fit for the API implementation.


Although the web application server still generates the main user interface, implements part of the business logic, and is responsible for retrieving data from the database. In addition, web services had to be provided to handle API calls from Ajax.
The client renders the user interface, provides JavaScript and Ajax engines, and execute part of the business logic of the application. The rich client experience is provided by JavaScript functionality and Ajax, asynchronously updating page fragments with data from the server.

Pros and Cons

– Improved dynamic UI experience through asynchronous page updates.
– Server-side MVC implementations through languages like Java Server Pages or ASP .Net.
– Content mashup from various sources
– Business logic implementation split between client and server
– Increased application complexity due to UI generation partially on client and server
– Limited to browser-based clients
– Cross-browser compatibility issues

Single-Page Applications (2010 and today)


In the last few years a new type of web application architecture has emerged: the single-page application. The new architecture seems to continue the trends discussed above: from static to dynamic, from server-centric to client independence, from ‘build-it-yourself’ to ‘use-a-framework’.

The single page application has several distinct features: As the name states, a main page is loaded into the web browser at startup. Page navigation is accomplished by replacing views in the frames of the main layout. This leads to a much more responsive user experience.
One of the main advantages of this architecture is by decoupling the UI generation from the server and implementing an API interface between client and server, a degree of independence between the two is achieved. As a result, different types of clients (e.g. native mobile or browser) can communicate with the server or one client can interact with different types of servers. This new architecture allows developers to build single-page mash-up applications consuming multiple distributed API services.

Products used to implement this type of architecture such as Angular.js, Backbone, or Ember.js provide other important features: The best-practice UI implementation pattern of separating Model, View, and Controller functionality for example. Most products also support the automatic two-way binding between View (HTML code) and Model (data) which greatly simplifies development and testing.

Today other powerful tools are often used to complement the development process:

  • UI frameworks such as Bootstrap, JQuery UI, or KendoUI provide a responsive layout, cross-browser compatibility, and a uniform set of widgets which can be easily themed.
  • CSS preprocessors such as Less and SASS allow developers a more flexible way to manage CSS by introducing variables and functions.
  • Templating libraries such as handlebars or mustache directly support the MV implementation and enhance reusability and maintainability of UI code.


The presentation layer and business logic is implemented completely on the client side. The client retrieves data from the server using JavaScript/Ajax and by consuming the available API services. The server provides data in form of JSON or XML format.
The client then uses the data to populate models which are then automatically bound to views loaded from templates. A two-way binding of UI elements and model properties ensure that both components are kept in sync. Navigation within the web application is provided by a route implementation and loading views into the main application page frames as the routes are executed.

Pros and Cons

– Responsive UI experience provided by limited trips to the server
– Cleaner UI implementation through MVC patterns and templates
– Decoupling of client and backend functionality allows support of multiple client types (e.g. native mobile apps, browsers, hybrid apps)
– Simplified UI development and theming through HTML/JS frameworks
– API interfaces allow content integration from multiple sources
– Decreased server workload and increased scalability
– Security concerns due to business logic implementation on the client side
– Startup delay during the initial load of the application

Architectural Comparison

Thanks for reading. Hope you enjoyed the post. Please comment and rate.

Author Description


No comments yet.

Join the Conversation