Zum Inhalt springen

„Web Server Gateway Interface“ – Versionsunterschied

aus Wikipedia, der freien Enzyklopädie
Versionsgeschichte interaktiv durchsuchen
[gesichtete Version][gesichtete Version]
← Zum vorherigen VersionsunterschiedZum nächsten Versionsunterschied →
Inhalt gelöscht Inhalt hinzugefügt
VisuellWikitext
K zus. Links, Doppel-Links raus
Zeile 1: Zeile 1:
Das '''Web Server Gateway Interface''' ('''WSGI''') ist eine Schnittstellen-Spezifikation für die Programmiersprache [[Python (Programmiersprache)|Python]], die eine Schnittstelle zwischen [[Webserver]]n und [[Webframework]]s bzw. [[Web Application Server]]n festlegt, um die [[Plattformunabhängigkeit|Portabilität]] von [[Webanwendung]]en auf unterschiedlichen Webservern zu fördern.
Das '''Web Server Gateway Interface''' ('''WSGI''') ist eine [[Spezifikation# Spezifikation_in_der_Informatik|Spezifikation]] für die Programmiersprache [[Python (Programmiersprache)|Python]], die eine [[Schnittstelle]] zwischen [[Webserver]]n und [[Webframework]]s bzw. [[Web Application Server]]n festlegt, um die [[Plattformunabhängigkeit|Portabilität]] von [[Webanwendung]]en auf unterschiedlichen Webservern zu fördern.


== Details ==
== Details ==
Die eigentliche Schnittstelle besteht auf Anwendungsseite aus einem aufrufbaren Objekt. Dieses erhält als Parameter die Umgebungsvariablen und ein Funktionsobjekt (<code>start_response</code> im Beispiel) und muss ein iterierbares Objekt zurückgeben. Die Umgebungsvariablen werden als [[assoziatives Array]] übergeben (<code>environ</code> im Beispiel). Das Funktionsobjekt dient dazu, die HTTP-Header auszugeben; es wird von der Server-Seite aufgerufen, bevor der Rückgabewert der Funktion an den Client gesendet wird.
Die eigentliche Schnittstelle besteht auf Anwendungsseite aus einem aufrufbaren [[Objekt (Programmierung)|Objekt]] (<code>app</code> im Beispiel). Dieses erhält als [[Parameter (Informatik)|Parameter]] die [[Umgebungsvariable]]n (<code>environ</code>) und ein [[Funktion (Programmierung)|Funktions]]<nowiki></nowiki>objekt (<code>start_response</code>) und muss ein [[Iteration#Informatik|iterierbar]]es Objekt zurückgeben. Die Umgebungsvariablen werden als [[assoziatives Array]] übergeben. Das Funktionsobjekt dient dazu, die [[HTTP-Header]] auszugeben; es wird von der [[Server]]-Seite aufgerufen, bevor der [[Rückgabewert]] der [[Funktion]] an den [[Client]] gesendet wird.


Beispiel:
Beispiel:
Zeile 12: Zeile 12:


== Hintergrund ==
== Hintergrund ==
In den letzten Jahren entwickelte sich auf der Basis von [[Python (Programmiersprache)|Python]] eine Vielzahl von [[Web Application Framework]]s und [[Web Application Server]]n. Die Schwierigkeit bestand darin, dass die Auswahl eines Frameworks die Auswahl des Webservers einschränkte und umgekehrt. Dies machte es schwer, sich für ein System zu entscheiden und erschwerte zusätzlich die [[Plattformunabhängigkeit|Portabilität]], wenn man später ein anderes Framework bzw. einen anderen Webserver verwenden wollte.
In den letzten Jahren entwickelte sich auf der Basis von Python viele Web Application Frameworks und Web Application Servern. Die Schwierigkeit bestand darin, dass die Auswahl eines Frameworks die Auswahl des Webservers einschränkte und umgekehrt. Dies machte es schwer, sich für ein System zu entscheiden und erschwerte zusätzlich die Portabilität, wenn man später ein anderes Framework bzw. einen anderen Webserver verwenden wollte.

Um diesem Problem entgegenzuwirken, wurde das ''Python Web Server Gateway Interface'' geschaffen – gedacht als einheitliche Schnittstelle ([[Middleware]]) zwischen den beiden Welten. Dies sollte eine Trennung des Webservers und der dahinterliegenden Anwendung ermöglichen und damit die Portabilität für diese erhöhen. Der erste Entwurf des zugehörigen [[Python Enhancement Proposal]] 333 war vom 7. Dezember 2003.
Um diesem Problem entgegenzuwirken, wurde das ''Python Web Server Gateway Interface'' geschaffen – gedacht als einheitliche Schnittstelle ([[Middleware]]) zwischen den beiden Welten. Dies sollte eine Trennung des Webservers von der dahinterliegenden Anwendung ermöglichen und damit die Portabilität für diese erhöhen. Der erste Entwurf des zugehörigen [[Python Enhancement Proposal]]&nbsp;333 war vom 7.&nbsp;Dezember 2003.


== Anwendung ==
== Anwendung ==
Bisher sind nur wenige Websites für eine extensive Nutzung von WSGI bekannt geworden.<ref>{{cite web|url=http://trends.builtwith.com/Web-Server/mod_wsgi|title=mod_wsgi Usage Statistics|accessdate=2020-08-01}}</ref><ref>[http://w3techs.com/technologies/overview/programming_language/all w3techs.com]</ref>
Bisher sind nur wenige [[Website]]s für eine extensive Nutzung von&nbsp;WSGI bekannt geworden.<ref>{{cite web|url=http://trends.builtwith.com/Web-Server/mod_wsgi|title=mod_wsgi Usage Statistics|accessdate=2020-08-01}}</ref><ref>[http://w3techs.com/technologies/overview/programming_language/all w3techs.com]</ref>
Verwendet wird WSGI derzeit vor allem
⚫
Verwendung findet derzeit WSGI vor allem über [[mod_wsgi]] in [[Apache HTTP Server|Apache Web Servern]] oder über [[uwsgi]] in [[Nginx]]-<ref>[http://wiki.nginx.org/HttpUwsgiModule wiki.nginx.org]</ref> oder [[Cherokee (Webserver)|Cherokee]]<ref>[http://cherokee-project.com/doc/cookbook_uwsgi.html cherokee-project.com]</ref>-Servern.
* über [[mod_wsgi]] in [[Apache HTTP Server|Apache Web Servern]] oder
⚫
Beide Varianten können als eigenständiger Systemdienst (daemon) vom Webserver getrennt arbeiten und bieten so neben bedingten Sicherheits- und Performance-Vorteilen auch komfortable Möglichkeiten zur Skalierung und unterbrechungsfreien Updates.<ref>{{cite web|url=http://nginx.org/LICENSE|title=uwsgi Zerg Mode|accessdate=2013-09-27}}</ref><ref>{{cite web|url=http://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide#Delegation_To_Daemon_Process|title=mod_wsgi Daemon Delegation|accessdate=2013-09-27}}</ref>
⚫
* über [[uwsgi]] in [[Nginx]]-<ref>[http://wiki.nginx.org/HttpUwsgiModule wiki.nginx.org]</ref> oder [[Cherokee (Webserver)|Cherokee]]<ref>[http://cherokee-project.com/doc/cookbook_uwsgi.html cherokee-project.com]</ref>-Servern.
⚫
Beide Varianten können als eigenständiger [[Dienstprogramm|Systemdienst]] ([[daemon]]) getrennt vom Webserver arbeiten und bieten so neben bedingten Sicherheits- und [[Rechenleistung|Performance]]-Vorteilen auch komfortable [[Skalierbarkeit|Möglichkeiten zur Skalierung]] und unterbrechungsfreie [[Softwareaktualisierung|Update]]s.<ref>{{cite web|url=http://nginx.org/LICENSE|title=uwsgi Zerg Mode|accessdate=2013-09-27}}</ref><ref>{{cite web|url=http://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide#Delegation_To_Daemon_Process|title=mod_wsgi Daemon Delegation|accessdate=2013-09-27}}</ref>


== WSGI-kompatible Software ==
== WSGI-kompatible Software ==

Version vom 15. Oktober 2022, 13:29 Uhr

Das Web Server Gateway Interface (WSGI) ist eine Spezifikation für die Programmiersprache Python, die eine Schnittstelle zwischen Webservern und Webframeworks bzw. Web Application Servern festlegt, um die Portabilität von Webanwendungen auf unterschiedlichen Webservern zu fördern.

Details

Die eigentliche Schnittstelle besteht auf Anwendungsseite aus einem aufrufbaren Objekt (app im Beispiel). Dieses erhält als Parameter die Umgebungsvariablen (environ) und ein Funktionsobjekt (start_response) und muss ein iterierbares Objekt zurückgeben. Die Umgebungsvariablen werden als assoziatives Array übergeben. Das Funktionsobjekt dient dazu, die HTTP-Header auszugeben; es wird von der Server-Seite aufgerufen, bevor der Rückgabewert der Funktion an den Client gesendet wird.

Beispiel: 

def app(environ, start_response):
    start_response('200 OK', [('content-type', 'text/plain')])
    return [b'Hello world!']

Hintergrund

In den letzten Jahren entwickelte sich auf der Basis von Python viele Web Application Frameworks und Web Application Servern. Die Schwierigkeit bestand darin, dass die Auswahl eines Frameworks die Auswahl des Webservers einschränkte und umgekehrt. Dies machte es schwer, sich für ein System zu entscheiden und erschwerte zusätzlich die Portabilität, wenn man später ein anderes Framework bzw. einen anderen Webserver verwenden wollte.

Um diesem Problem entgegenzuwirken, wurde das Python Web Server Gateway Interface geschaffen – gedacht als einheitliche Schnittstelle (Middleware) zwischen den beiden Welten. Dies sollte eine Trennung des Webservers von der dahinterliegenden Anwendung ermöglichen und damit die Portabilität für diese erhöhen. Der erste Entwurf des zugehörigen Python Enhancement Proposal 333 war vom 7. Dezember 2003.

Anwendung

Bisher sind nur wenige Websites für eine extensive Nutzung von WSGI bekannt geworden.[1][2] Verwendet wird WSGI derzeit vor allem

Beide Varianten können als eigenständiger Systemdienst (daemon) getrennt vom Webserver arbeiten und bieten so neben bedingten Sicherheits- und Performance-Vorteilen auch komfortable Möglichkeiten zur Skalierung und unterbrechungsfreie Updates.[5][6]

WSGI-kompatible Software

Einzelnachweise

  1. ↑ mod_wsgi Usage Statistics. Abgerufen am 1. August 2020.
  2. ↑ w3techs.com
  3. ↑ wiki.nginx.org
  4. ↑ cherokee-project.com
  5. ↑ uwsgi Zerg Mode. Abgerufen am 27. September 2013.
  6. ↑ mod_wsgi Daemon Delegation. Abgerufen am 27. September 2013.
Webserver-Schnittstellen
Protokolle

CGI | SCGI | FastCGI | AJP

APIs

C NSAPI | C ASAPI | C ISAPI | Jakarta Servlet | ASP.NET | Python WSGI | Ruby Rack | JavaScript JSGI | PSGI | Lua WSAPI 

Apache-Module

mod_jk | mod_lisp | mod_parrot | mod_perl | mod_php | mod_python | mod_wsgi | mod_ruby | Phusion Passenger 

Web APIs

WSDL | XML-RPC | SOAP | REST 

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Web_Server_Gateway_Interface&oldid=227055131“