It’s All HTTP Underneath

When you are working with web applications, every operation is ultimately reduced to a series of requests and responses between the user’s browser and the server hosting the application, using the HTTP protocol. While an introductory discussion of HTTP is outside the scope of this book, it’s important for web developers to know how it works.

From a web application standpoint, HTTP means getting requests from a web browser for some URL that the application knows how to handle, then processing this request and sending a response back. This sounds easy, but there’s lots of stuff to do.

Imagine that we are writing an application that will do all this work without depending on other libraries or frameworks. Our application needs to know how to interpret a request, decode any parameters that it contains, pass that information to the specific code in the application that is supposed to be run for that URL, get a result (preferably a nice HTML page with a beautiful design), encode that into a response, and send it back to the server. All of this would require writing code to handle each task.

Additionally, HTTP is a stateless protocol, which means no session information is kept from request to request. Our application will need some way to know if a user logs in or out, and make sure that the correct information for each user is used where required. The browser provides some tools to keep track of that on the client side, but the application needs to do some work, and the available mechanisms are often not enough for many applications.

Our application also has to have a way to get requests from a web server, as well as sending back a response. That means more code will be needed to communicate with the web server. The actual logic in our application begins to feel rather small compared to the work required to make it work on the Web.

Web Servers and WSGI

When the Web started, a server only had to do one thing: get a file from the path from the server root specified by the URL path. HTML was just text, nothing more. Later, it became possible to add images. Twenty years later, a single “web page” can pull in 50 or more resources.

Along the way, servers began getting more complex and the Web turned from a static content medium into a dynamic content generation platform. First, there was the capability to perform simple queries, then to run scripts via a mechanism known as CGI. Finally, specialized protocols to run applications began to emerge.

In the Python world, things started moving very early on. Zope, the first Python application server, was open sourced in 1998, when opening up the code from a commercial project was still big news. Zope was ahead of its time in many ways and, though it has become less popular, it still survives and is in heavy use after all these years.

Zope was what we call a full-stack framework, which means it provides the whole range of services discussed in the previous section, and lots more. At the same time, other Python frameworks started coming out, but they all interoperated with web servers in different ways or used generic web server gateways that required some code to interface. That meant that the choice of framework would limit the choice of web servers and vice versa.

In 2003, a protocol named WSGI (Web Server Gateway Interface) was proposed to provide a standard interface between web servers and Python web applications. Inspired by the Java Servlet specification, the WSGI protocol took off after some time and is now the de facto way to connect Python applications with web servers.

A server implementing the WSGI specification can receive a request, pass it to the web application, and send the application’s response back to the client. Applications can be stacked, so it’s possible to have middleware that transforms the application response before it’s returned.

Today, most Python web frameworks implement or support WSGI, and there are some libraries and toolkits that make it easier to create WSGI-compatible frameworks.

Installing Python Packages

When discussing some of the most notable frameworks back in Chapter 2, there was a Quick Start section for each. For people who don’t have previous experience with Python packaging, we include some information about installing packages in this appendix.

For more information, consult the official Python packaging user guide, located at http://bit.ly/1O2NiWu.

pip install -U pip setuptools

python -m pip install -U pip setuptools

pip install wheel

pip install 'package'

pip install 'package==1.0'

pip install -r requirements.txt