Chapter 10 ■ http ServerS
182
Summary
Python has an http.server module built in that, when launched from the command line, serves up files from
beneath its current working directory. While convenient in emergencies or when examining a web site stored directly
on disk, the module is rarely used any more for creating new HTTP services.
Normal, synchronous HTTP in Python is usually mediated by the WSGI standard. Servers parse the incoming
request to produce a dictionary full of information, and applications examine the dictionary before returning HTTP
headers and an optional response body. This lets you use any web server you want with any standard Python web
framework.
Asynchronous web servers are an exception to the WSGI ecosystem. Because WSGI callables are not full
coroutines, every async HTTP server has to adopt its own convention for how you write a service in its custom
framework. The server and framework come as a bundle in this case, often without any possibility of wider
interoperability.
Four architectures are popular for serving HTTP from Python. A stand-alone server can be run using Gunicorn
or other pure-Python server implementations such as CherryPy. Other architects opt to run their Python under the
control of Apache through mod_wsgi. However, now that the concept of a reverse proxy is a go-to pattern for web
services of all kinds, many architects find it simpler to put Gunicorn or another pure-Python server directly behind
nginx or Apache as a separate HTTP service to which they can forward requests for paths whose resources are
generated dynamically.
Any of these patterns can then have Varnish or another reverse proxy put in front of them to provide a caching
layer. The cache instances can be local to the same machine room (or even the same machine), but they will often be
geographically distributed to put them closer to particular populations of HTTP clients.
Installing your service on a PaaS provider will often provide caching, reverse-proxying, and load balancing as
part of the service. All that your application will be responsible for is answering HTTP requests, often using a simple
container like Gunicorn.
A popular question that is asked of services is whether they are RESTful: whether they feature the properties
that standards author Dr. Roy Fielding describes as having been intended by the design of HTTP. While many
services today have pivoted away from opaque choices of method and path, which hid what the service was doing,
few have adopted Fielding’s full vision for powering semantics with hypertext instead of with programmer-directed
documentation.
Small services, especially those that filter or transform an HTTP request, can be written as a WSGI callable. Either
of two competing solutions, WebOb or Werkzeug, can reduce the raw WSGI environment to an easier-to-consume
Request object, and they can also help you build your answer through their Response classes.
In the next chapter, you will go beyond both generic HTTP services and low-level WSGI programming by learning
about the World Wide Web—the vast collection of interlinked documents that have made the Internet world famous.
You will learn how to fetch and process hypertext documents and to implement web sites yourself using popular web
frameworks.