Как веб-фреймворки Python, WSGI и CGI сочетаются друг с другом

Я думаю, Флорианский ответ отвечает на часть вашего вопроса о том, что такое WSGI, особенно если вы читаете PEP.

Что касается вопросов, которые вы задаете ближе к концу:

WSGI, CGI, FastCGI и т.д. - все протоколы для веб-сервера для запуска кода и доставки динамического контента, который создается. Сравните это со статическим веб-сервисом, где обычный HTML файл в основном поставляется как есть для клиента.

CGI, FastCGI и SCGI являются языковыми агностиками. Вы можете писать сценарии CGI в Perl, Python, C, bash, что угодно. CGI определяет, какой исполняемый файл будет вызываться на основе URL-адреса, и как он будет вызываться: аргументы и среда. Он также определяет, как возвращаемое значение должно быть возвращено на веб-сервер после завершения вашего исполняемого файла. Эти вариации в основном являются оптимизациями, позволяющими обрабатывать больше запросов, уменьшать задержку и т.д.; базовая концепция одинаков.

WSGI - только Python.. Вместо агностического протокола языка определена стандартная сигнатура функции:

def simple_app(environ, start_response):
    """Simplest possible application object"""
    status = '200 OK'
    response_headers = [('Content-type','text/plain')]
    start_response(status, response_headers)
    return ['Hello world!\n']

Это полное (если ограниченное) приложение WSGI. Веб-сервер с поддержкой WSGI (например, Apache с mod_wsgi) может вызывать эту функцию всякий раз, когда приходит запрос.

Причина, по которой это так здорово, заключается в том, что мы можем избежать беспорядочного перехода от HTTP GET/POST к CGI на Python и снова вернуться на выход. Это гораздо более прямая, чистая и эффективная связь.

Это также упрощает работу с многолетними фреймворками, работающими за веб-серверами, если все, что нужно сделать для запроса, - вызов функции. С простым CGI вы должны запустить всю свою структуру для каждого отдельного запроса.

Чтобы иметь поддержку WSGI, вам необходимо установить модуль WSGI (например, mod_wsgi) или использовать веб-сервер с WSGI (например CherryPy). Если ни один из них невозможен, вы можете использовать мост CGI-WSGI, указанный в PEP.

Вы можете запустить WSGI через CGI, как показано в примере Pep333. Однако каждый раз, когда возникает запрос, запускается новый интерпретатор Python, и весь контекст (соединения с базой данных и т.д.) Должен быть построен, и все это занимает время.

Лучше всего, если вы хотите запустить WSGI, было бы, если бы ваш хост установил mod_wsgi и сделал соответствующую конфигурацию для отсрочки контроля над приложением ваш.

Flup - это еще один способ запускать WSGI для любого веб-сервера, который может говорить FCGI, SCGI или AJP. Из моего опыта работает только FCGI, и его можно использовать в Apache либо через mod_fastcgi, либо если вы можете запустить отдельный демон Python с mod_proxy_fcgi.

WSGI - это протокол, похожий на CGI, который определяет набор правил взаимодействия веб-сервера и Python-кода, он определяется как Pep333. Это позволяет, что многие различные веб-серверы могут использовать множество различных фреймворков и приложений, используя один и тот же протокол приложений. Это очень полезно и делает его настолько полезным.

Если вы неясны на всех терминах в этом пространстве и можете встретить это, его запутанный сокращенный аббревиатурой, там также есть хороший справочный читатель в форме официального Python HOWTO, который обсуждает CGI и FastCGI vs. WSGI и т.д.: http://docs.python.org/howto/webservers.html

Это простой уровень абстракции для Python, сродни тому, что спецификация Servlet для Java. В то время как CGI действительно низкий уровень и просто сбрасывает материал в среду процесса и стандартное вход/выход, приведенные выше два спецификатора моделируют HTTP-запрос и ответ как конструкции на языке. Мое впечатление, однако, заключается в том, что в Python люди не совсем обосновались в де-факто реализациях, поэтому у вас есть сочетание эталонных реализаций и других библиотек типа утилит, которые предоставляют другие возможности наряду с поддержкой WSGI (например, Paste). Конечно, я могу ошибаться, я новичок в Python. Сообщество "веб-скриптов" сталкивается с проблемой в другом направлении (совлокальный хостинг, наследие CGI, проблемы с разделением привилегий), чем люди из Java имели возможность начать с (запуск одного корпоративного контейнера в выделенной среде против статически скомпилированных и развернутых код).