title: WSGI
text: # WSGI
  
  La Interfaz de Pasarela del Servidor Web, o Web Server Gateway Interface en inglés (WSGI) es un estándar que facilita la conexión entre el servidor web y las aplicaciones web desarrolladas en Python. Gracias a esta interfaz estandarizada, resulta más sencillo utilizar una aplicación que sea compatible con WSGI con diversos servidores web.
  WSGI actúa como una interfaz entre el servidor web y la aplicación web, permitiendo que ambos se comuniquen de manera eficiente:
  * Solicitud del Cliente: Un usuario realiza una solicitud a través de su navegador web para acceder a una página web.
  * Servidor Web: La solicitud del cliente llega al servidor web, que es responsable de manejar las solicitudes entrantes.
  * Entorno WSGI: Cuando se recibe una solicitud que debe ser manejada por una aplicación web en Python, el servidor web crea un entorno WSGI. Este entorno contiene información sobre la solicitud, como el método HTTP, la URL solicitada y otros detalles relevantes.
  * Aplicación WSGI: La aplicación web escrita en Python, que sigue la especificación de WSGI, recibe el entorno WSGI y produce una respuesta. La aplicación puede ser un marco web como Flask o Django.
  * Respuesta WSGI: La aplicación WSGI genera una respuesta, que incluye el contenido de la página web, los encabezados HTTP y cualquier otra información necesaria.
  * Devolución al Servidor Web: La respuesta de la aplicación WSGI se devuelve al servidor web a través del entorno WSGI.
  * Envío al Cliente: El servidor web toma la respuesta WSGI y la envía de vuelta al cliente, que la recibe y muestra en el navegador.
  
  # WSGI
  ## Orígenes del WSGI
  
  Antes de la existencia de WSGI, cada marco web en Python tenía su propia forma de interactuar con los servidores web. Esta falta de estandarización dificultaba la portabilidad de las aplicaciones web entre diferentes servidores.
  El primer estándar WSGI, conocido como WSGI fue propuesto en 2003 por Phillip J. Eby y Ian Bicking. La intención era crear una interfaz común que permitiera a los desarrolladores de aplicaciones web trabajar con diferentes servidores web sin tener que realizar cambios significativos en su código.
  En el año 2010, el PEP 333 (Python Enhancement Proposal) formalizó la especificación de WSGI, este PEP proporcionó la documentación necesaria para la implementación y el uso de WSGI.
  
  # WSGI
  ## En la Documentación introductoria de Python sobre el WSGI
  
  WSGI no constituye un servidor, un módulo de Python, un framework, una API, ni cualquier tipo de software en sí mismo. Más bien, se trata de una especificación de interfaz que establece cómo deben comunicarse el servidor web y la aplicación web.
  La especificación WSGI define tanto el lado del servidor como la interfaz de la aplicación, como se detalla en el PEP 3333 (Python Enhancement Proposal). Cuando una aplicación, framework o conjunto de herramientas se desarrolla siguiendo la especificación WSGI, tiene la capacidad de ejecutarse en cualquier servidor que también esté implementado según esta especificación.
  Las aplicaciones WSGI, aquellas que cumplen con la especificación WSGI, tienen la capacidad de ser apiladas. Aquellas que ocupan una posición intermedia en esta pila se denominan middleware y deben implementar tanto el lado de la aplicación como el del servidor en la interfaz WSGI.
  La aplicación que se encuentra en la parte superior de la pila actuará como un servidor para la aplicación (o servidor) ubicada debajo, mientras que para la aplicación (o servidor) que está debajo, funcionará como una aplicación. Este modelo permite la composición y la creación de cadenas de middleware, lo que proporciona flexibilidad y extensibilidad en el manejo de las solicitudes web en entornos WSGI.
  WSGI funciona como un conducto simple que recibe la solicitud del cliente, la transmite a la aplicación y luego envía la respuesta generada por la aplicación de vuelta al cliente. Su función se limita a este proceso y no realiza acciones adicionales. Todos los detalles específicos sobre cómo manejar la solicitud y generar la respuesta deben ser gestionados por la aplicación o middleware.
  Es importante destacar que no es necesario tener un conocimiento profundo de la especificación WSGI para desarrollar aplicaciones utilizando frameworks o kits de herramientas que sean compatibles con WSGI. En el caso de usar middleware, se requiere una comprensión básica de cómo apilarlos junto con la aplicación o el marco, a menos que el framework ya los integre de manera nativa o proporcione algún mecanismo para incorporar aquellos que no estén integrados de forma predeterminada.
  
  # WSGI
  ## "Hello word" en WSGI
  
  La implementación de una aplicación compatible con WSGI implica proporcionar un objeto invocable (puede ser una función o una clase) que reciba un diccionario llamado environ y una función llamada start_response. En términos sencillos, el diccionario environ puede compararse con una combinación de $_SERVER, $_GET y $_POST en PHP, aunque con ciertos procesamientos adicionales requeridos.
  * Codigo de ejemplo dentro de la documentación de python sobre el WSG:
  
  # WSGI
  ## Funcionamiento dentro de las Frameworks
  
  Dentro de marcos de trabajo compatibles con WSGI como Flask, Django, Pyramid, etc. El marco generalmente proporciona su propia implementación de WSGI, y no es necesario que escribas el código WSGI tú mismo. En el caso de Flask, el módulo werkzeug que utiliza Flask internamente incluye una implementación WSGI. Cuando ejecutas una aplicación Flask, el servidor web (Gunicorn, uWSGI, etc.) utiliza la interfaz WSGI para comunicarse con la aplicación Flask, Este framework ya tiene la implementación de WSGI integrada, y generalmente no necesitas preocuparte por los detalles internos de WSGI a menos que estés configurando un servidor personalizado o tratando con situaciones muy específicas.