Risposte:
WSGI esegue l'interprete Python all'avvio del server Web, come parte del processo del server Web (modalità incorporata) o come processo separato (modalità demone) e carica lo script al suo interno. Ogni richiesta comporta una specifica funzione nello script che viene chiamato, con l'ambiente di richiesta passato come argomenti alla funzione.
CGI esegue lo script come processo separato per ogni richiesta e utilizza variabili di ambiente, stdin e stdout per "comunicare" con esso.
Da un punto di vista totalmente indietro, Blankman, ecco la mia "Pagina introduttiva" per l'interfaccia del gateway di servizi Web:
PARTE PRIMA: SERVER WEB
I server Web forniscono risposte. Si siedono intorno, aspettando pazientemente e poi senza alcun preavviso, all'improvviso:
I server Web (almeno quelli migliori) sono MOLTO bravi in questo. Aumentano e diminuiscono l'elaborazione a seconda della domanda, tengono conversazioni in modo affidabile con i clienti più sfigati su reti molto rozze e non dobbiamo mai preoccuparci. Continuano a servire.
Questo è il mio punto: i server Web sono proprio questo: server. Non sanno nulla dei contenuti, niente degli utenti, niente di diverso se non aspettare molto e rispondere in modo affidabile.
La scelta del server Web dovrebbe riflettere le tue preferenze di consegna, non il tuo software. Il tuo server web dovrebbe essere incaricato di servire, non di elaborare o cose logiche.
PARTE SECONDA: SOFTWARE (PYTHON)
Il software non è disponibile. Il software esiste solo al momento dell'esecuzione. Il software non è terribilmente accomodante quando si tratta di cambiamenti imprevisti nel suo ambiente (i file non si trovano dove si aspetta, i parametri vengono rinominati ecc.). Sebbene l'ottimizzazione dovrebbe essere un principio centrale del tuo progetto (ovviamente), il software stesso non ottimizza. Gli sviluppatori ottimizzano. Il software viene eseguito. Il software esegue tutte le operazioni nella sezione "Mumble deliberata" sopra. Potrebbe essere qualsiasi cosa.
La scelta o la progettazione del software devono riflettere l'applicazione, la scelta della funzionalità e non la scelta del server Web.
È qui che il metodo tradizionale di "compilazione" delle lingue sui server Web diventa doloroso. Finisci per inserire il codice nella tua applicazione per far fronte all'ambiente fisico del server o, almeno, essere costretto a scegliere una libreria 'wrapper' appropriata da includere in fase di esecuzione, per dare l'illusione di uniformità tra i server web.
COS'È WSGI?
Quindi, finalmente, cos'è WSGI? WSGI è un insieme di regole , scritto in due metà. Sono scritti in modo tale da poter essere integrati in qualsiasi ambiente che accolga l'integrazione.
La prima parte, scritta per il lato server Web, dice "OK, se vuoi gestire un'applicazione WSGI, ecco come penserà il software quando si carica. Ecco le cose che devi mettere a disposizione dell'applicazione, e qui è l'interfaccia (layout) che puoi aspettarti da ogni applicazione. Inoltre, se qualcosa va storto, ecco come penserà l'app e come puoi aspettarti che si comporti. "
La seconda parte, scritta per il software applicativo Python, dice "OK, se vuoi avere a che fare con un server WSGI, ecco come penserà il server quando ti contatterà. Ecco le cose che devi mettere a disposizione del server, e ecco l'interfaccia (layout) che puoi aspettarti da ogni server. Inoltre, se qualcosa va storto, ecco come dovresti comportarti ed ecco cosa dovresti dire al server. "
Quindi il gioco è fatto: i server saranno i server e il software sarà il software, ed ecco un modo in cui possono andare d'accordo semplicemente senza che uno debba tenere conto delle specifiche dell'altro. Questo è WSGI.
mod_wsgi, d'altra parte, è un plug-in per Apache che gli consente di parlare con il software conforme WSGI, in altre parole, mod_wsgi è un'implementazione - in Apache - delle regole della prima parte del regolamento sopra.
Per quanto riguarda CGI .... chiedi a qualcun altro :-)
Se non si è chiari su tutti i termini in questo spazio, e ammettiamolo, è un linguaggio confuso pieno di acronimi, c'è anche un buon lettore di background sotto forma di un HOWTO ufficiale in pitone che discute CGI vs FastCGI vs WSGI e così via sopra. Vorrei averlo letto per primo.
Sia CGI che WSGI definiscono interfacce standard che i programmi possono utilizzare per gestire le richieste Web. L'interfaccia CGI è a un livello inferiore rispetto a WSGI e coinvolge il server che imposta variabili di ambiente contenenti i dati dalla richiesta HTTP, con il programma che restituisce qualcosa di formattato praticamente come una risposta del server HTTP nudo.
WSGI, d'altra parte, è un'interfaccia specifica di Python, di livello leggermente superiore che consente ai programmatori di scrivere applicazioni indipendenti dal server e che possono essere inserite in altre applicazioni WSGI (middleware).