Web Server Gateway Interface (WSGI) is a protocol which allows any WSGI-compatible web framework to use any WSGI-compatible web server. It’s pretty easy to implement. You just provide a callable object (either a function or a class) that accepts two arguments:
- environ: A Python dictionary of environment variables.
- start_response: a callback function sending HTTP status and headers back to the server.
That’s it. The canonical WSGI specification, PEP-3333, gives the final goal of WSGI: web libraries instead of frameworks1.
If middleware can be both simple and robust, and WSGI is widely available in servers and frameworks, it allows for the possibility of an entirely new kind of Python web application framework: one consisting of loosely-coupled WSGI middleware components. Indeed, existing framework authors may even choose to refactor their frameworks’ existing services to be provided in this way, becoming more like libraries used with WSGI, and less like monolithic frameworks. This would then allow application developers to choose “best-of-breed” components for specific functionality, rather than having to commit to all the pros and cons of a single framework.
-
A library is a collection of functions called by your program. A framework is a large, monolithic program into which you add your code. Your code calls a library. A framework calls your code. Hence the expression: Don’t call us. We’ll call you. ↩