While developing web applications, we assume that we have request and focus on generating a response. The request reaches the application code through a web server. How a web server communicates with the application code is taken for granted. This writing is the result of my attempts to understand communication between web server and application code.

To understand web server interfaces, I had to understand terms like web server, application code, dynamic response generation, web framework and application server. To understand these terms I needed to go through the evolution of web.

The need for interfaces

Server process is an example of daemon. It continuously serves its clients. A server that communicates using HTTP is HTTP Server. As initial version of HTTP has only GET verb, the HTTP Server needed to serve some static HTML documents that are stored on disk. With the later versions, HTTP got extended with more verbs and header fields.

Let us say we have a web service, through which the resources are made available to the web. As HTTP verbs standardize the operations on the resources of the web, the web service should understand the HTTP verbs to carryout operation enforced by the HTTP verb on the specified entity. Now, the resources are not pre-generated static files. New resources can be created and existing ones can be updated or removed. Hence, for every request we need to generate the response dynamically — may be by querying the database. This is called dynamic response generation. For example, JSON representation or HTML document or any specific representation of a resource can be generated.

Hence, the web service application should contains two parts: code that responds to internet by taking in requests and sending out response, and code that operates on our resources according to the verbs. The former is HTTP Server code and the latter is application code.

Soon, the “technical” expectations of the servers changed; they are expected to be very fast and robust. The application code started to become complex; development teams needed help. Now, there are two problems to solve: developing servers capable of serving the needs modern web, and developing tools for manageable web application development. Significant efforts have been made in to producing specialized solutions to these two problems.

To solve the former problem, people started building “generic” server software. They called it as a “web server”. The reason behind nginx creation describes the expectations of a modern web server. Some of those expectations are: the ability to handle maximum number of requests per unit time, protecting the resources from the attacks, effective handling of static files, buffering response to clients with low bandwidth, HTTPS support, etc.,

To solve the latter problem, people started to building web frameworks to simplify the dynamic response generation.

Web servers are the qualified gate keepers of our services. Famous web servers out there are nginx, apache and IIS. The features of these web servers are just a configuration away.

As the goal of web servers is not to “understand” the request — for them every request is equivalent to a GET request, application code is expected to understand the request and carryout the necessary operation. HTTP verbs should drive the application code.

Useful links:

• Brief history of HTTP
• Understanding HTTP PUT
• What is a web server?
• Build your own web server

Interfaces

Once we have a web server and a application, we need to interface them. As the web server are “generic”, any application can be interfaced. But the interfacing methods depend on the type of the application. For example, the application can be a group of script files or a standalone service.

Below are some widely used interfaces:

• CGI
• FastCGI
• Reverse Proxy

Sometimes a programming language community might come up with their own standard. Python community came up their own standard, called WSGI to be used for communication between web server and python application. WSGI implementations are available for major web servers.

If the application itself is a standalone service, then it can be called as an application server. An application server, which runs the application code can be a HTTP Server without the qualities of a web server. A web server can be configured to be reverse proxy to the application server. Usage of the term application server can be contextual.

Application

We can program the web application in any programming language. To aid the web application development, many web frameworks are available. django in Python and Spring in Java are examples of web frameworks. Some web frameworks provide you with a development server to avoid the overhead of installing a web server during development. Production ready web server must be used to open traffic from the web.

Examples of web application development:

Python:

• How to Use Python in the web
• An introduction into the WSGI ecosystem
• uWSGI
• Apache, FastCGI and Python
• Understanding uwsgi, threads, processes, and GIL

Java:

Currently, Servlets is the standard way of web development in Java. Spring, one of the widely used framework for web development implements Servlets standard.

Application code written using Servlets is deployed using HTTP servers written in Java. These servers contain servlet container component to invoke the application code written using Servlets. Jetty and tomcat are examples of servers used to to deploy servlet code. These servers can be called as application servers.

Useful links:

• How web servers work?
• Servlet Specification
• List of Web Containers.

Useful links:

• HTML
• Common Questions
• server-side
• Web technology for developers
• Application Server vs. a Web Server?
• Web Characterization Terminology & Definitions Sheet

Behind the magic curtains is a series of writings. Checkout Behind the magic curtains: Spring Boot