Cada vez que leo WSGI o CGI me estremezco. Intenté leerlo antes, pero nada se ha estancado.¿Qué son WSGI y CGI en inglés simple?
¿Qué es realmente en inglés llano?
¿Simplemente canaliza las solicitudes a un terminal y redirige la salida?
WSGI ejecuta el intérprete de Python en el inicio del servidor web, ya sea como parte del proceso del servidor web (modo incrustado) o como un proceso separado (modo daemon), y carga el script en él. Cada solicitud da como resultado una función específica en el script que se llama, con el entorno de solicitud pasado como argumentos a la función.
CGI ejecuta el script como un proceso separado para cada solicitud y utiliza variables de entorno, stdin y stdout para "comunicarse" con él.
WSGI! = Mod_wsgi. Su lenguaje sugiere que se refiera a mod_wsgi, que es una implementación de WSGI. WSGI en sí mismo es simplemente una especificación y se puede implementar de muchas maneras diferentes, incluso sobre CGI. –
@Graham: ¿Estás diciendo que no hay otros contenedores WSGI que admitan la ejecución de aplicaciones WSGI en esos modos? –
Técnicamente, se podría decir que hay variaciones más sutiles que solo esas dos, al menos en la medida en que se inician los procesos o cómo se activa el código dentro de un sistema integrado. Entonces uno solo tiene que tener cuidado al generalizar las cosas en esas dos categorías. En un nivel bruto, podrías decir lo que tienes, pero hay un poco más que eso si quieres profundizar en él. –
Tanto CGI como WSGI definen interfaces estándar que los programas pueden usar para manejar solicitudes web. La interfaz CGI está en un nivel más bajo que WSGI, e implica que el servidor configure las variables de entorno que contienen los datos de la solicitud HTTP, y el programa devuelve algo formateado de forma muy parecida a una respuesta de servidor HTTP vacía.
WSGI, por otro lado, es una interfaz específica de Python que permite a los programadores escribir aplicaciones que son independientes del servidor y que pueden incluirse en otras aplicaciones WSGI (middleware).
Desde un punto de retroceso totalmente de vista, Blankman, aquí está mi "Introducción Página" para los Servicios Web Gateway Interface:
PARTE: SERVIDORES WEB
servidores web sirven respuestas. Se sientan alrededor, esperando pacientemente, y luego sin previo aviso, de repente:
Los servidores web (al menos, los mejores) son MUY buenos en esto. Escalan el procesamiento hacia arriba y hacia abajo dependiendo de la demanda, mantienen con confianza conversaciones con los clientes más descabellados sobre redes realmente rudas y nunca tenemos que preocuparnos por eso. Ellos solo siguen sirviendo.
Este es mi punto: los servidores web son solo eso: servidores. No saben nada sobre el contenido, nada sobre los usuarios, nada más que cómo esperar mucho y responder de manera confiable.
Su elección de servidor web debe reflejar su preferencia de entrega, no su software. Su servidor web debería estar a cargo de servir, no procesar o cosas lógicas.
PARTE: (Python) SOFTWARE
software no se sienta a. El software solo existe en el momento de la ejecución. El software no es terriblemente servicial cuando se trata de cambios inesperados en su entorno (los archivos no están donde se espera, los parámetros se renombran, etc.). Aunque la optimización debería ser un principio central de su diseño (por supuesto), el software en sí mismo no se optimiza. Los desarrolladores optimizan. El software se ejecuta El software hace todas las cosas en la sección de "murmullo deliberado" de arriba. Podría ser cualquier cosa
Su elección o diseño de software debe reflejar su aplicación, su elección de funcionalidad y no su elección de servidor web.
Aquí es donde el método tradicional de "compilar en" idiomas para servidores web se vuelve doloroso. Terminas poniendo código en tu aplicación para lidiar con el entorno del servidor físico o, al menos, forzándote a elegir una biblioteca 'contenedora' adecuada para incluir en tiempo de ejecución, para dar la ilusión de uniformidad en todos los servidores web.
SO ¿QUÉ ES WSGI?
Entonces, ¿qué es WSGI? WSGI es un conjunto de reglas, escrito en dos mitades. Están escritos de tal manera que se pueden integrar en cualquier entorno que dé la bienvenida a la integración.
La primera parte, escrita para el lado del servidor web, dice "OK, si desea tratar con una aplicación WSGI, así es como el software estará pensando cuando se carga. Estas son las cosas que debe poner a disposición del aplicación, y aquí está la interfaz (diseño) que puede esperar que tenga cada aplicación. Además, si algo sale mal, así es como la aplicación estará pensando y cómo puede esperar que se comporte ".
La segunda parte, escrita para el software de la aplicación Python, dice "OK, si quieres tratar con un servidor WSGI, así es como el servidor estará pensando cuando te contacte. Estas son las cosas que debes poner a disposición el servidor, y aquí está la interfaz (diseño) que puede esperar que tenga cada servidor. Además, si algo sale mal, así es como debe comportarse y esto es lo que debe decirle al servidor ".
Así que ahí lo tienes: los servidores serán los servidores y el software será el software, y esta es una forma en la que se pueden llevar bien sin que haya que tener en cuenta los detalles del otro. Este es WSGI.
mod_wsgi, por el contrario, es un plug-in para Apache que le permite hablar con software de WSGI-compatible, en otras palabras, mod_wsgi es un aplicación - en Apache - de las reglas de la primera parte del libro de reglas anteriores .
En cuanto a CGI .... pedir a otra persona :-)
En lugar de dejar que esta respuesta termine con "preguntar a alguien más", me gustaría que alguien editara esta respuesta para incluir CGI de la misma manera. –
Si no está seguro de todos los términos en este espacio, y seamos sinceros, es un acrónimo confuso uno cargado, también hay una buena Lector de fondo en forma de un official python HOWTO que trata CGI vs. FastCGI vs. WSGI y más. Ojalá lo hubiera leído primero.
http://stackoverflow.com/questions/219110/how-python-web-frameworks-wsgi-and-cg-fit-together –