Czym są WSGI i CGI w prostym języku angielskim?

127

Za każdym razem, gdy czytam WSGI lub CGI, wzdrygam się. Próbowałem to przeczytać wcześniej, ale tak naprawdę nic nie utknęło.

Co to naprawdę jest w prostym języku angielskim?

Czy po prostu przekazuje żądania do terminala i przekierowuje dane wyjściowe?

Blankman
źródło

Odpowiedzi:

60

WSGI uruchamia interpreter języka Python przy starcie serwera WWW, jako część procesu serwera WWW (tryb osadzony) lub jako oddzielny proces (tryb demona) i ładuje do niego skrypt. Każde żądanie skutkuje określoną funkcją w wywoływanym skrypcie, a środowisko żądania jest przekazywane jako argumenty do funkcji.

CGI uruchamia skrypt jako oddzielny proces dla każdego żądania i używa zmiennych środowiskowych, stdin i stdout do „komunikacji” z nim.

Ignacio Vazquez-Abrams
źródło
15
WSGI! = Mod_wsgi. Twój język sugeruje, że masz na myśli mod_wsgi, który jest implementacją WSGI. Sam WSGI jest jedynie specyfikacją i może być implementowany na wiele różnych sposobów, w tym jako dodatek do CGI.
Graham Dumpleton
@Graham: Czy chcesz powiedzieć, że nie ma innych kontenerów WSGI, które obsługują uruchamianie aplikacji WSGI w tych trybach?
Ignacio Vazquez-Abrams,
3
Z technicznego punktu widzenia można powiedzieć, że istnieją bardziej subtelne odmiany niż tylko te dwie, przynajmniej w takim samym stopniu, jak rozpoczęcie procesów lub aktywacja kodu w systemie wbudowanym. Trzeba więc być ostrożnym przy uogólnianiu rzeczy tylko na te dwie kategorie. Na poziomie grubym możesz powiedzieć, co masz, ale jest w tym coś więcej, jeśli chcesz się w to zagłębić.
Graham Dumpleton
1
@GrahamDumpleton, czy z ciekawości mógłbyś wyjaśnić, w jaki sposób można zaimplementować WSGI oprócz CGI?
Yoland
2
Przeczytaj specyfikację WSGI. Przedstawia przykładowy mostek CGI / WSGI. python.org/dev/peps/pep-3333/#the-server-gateway-side Aby uzyskać bardziej niezawodną implementację, zobacz github.com/GrahamDumpleton/cgi2wsgi Poważnie, ogólnie rzecz biorąc, chciałbyś uniknąć CGI.
Graham Dumpleton
256

Z całkowicie cofniętego punktu widzenia, Blankman, oto moja „Strona wprowadzająca” dla interfejsu Web Services Gateway:

CZĘŚĆ PIERWSZA: SERWERY INTERNETOWE

Serwery WWW obsługują odpowiedzi. Siedzą dookoła, czekając cierpliwie, a potem bez żadnego ostrzeżenia, nagle:

  • proces klienta wysyła żądanie. Procesem klienta może być serwer WWW, bot, aplikacja mobilna, cokolwiek. To po prostu „klient”
  • serwer WWW otrzymuje to żądanie
  • celowe mamrotanie zdarza się różne rzeczy (patrz poniżej)
  • Serwer WWW odsyła coś do klienta
  • serwer sieciowy znów działa

Serwery WWW (przynajmniej te lepsze) są w tym bardzo BARDZO dobre. Skalowują przetwarzanie w górę iw dół w zależności od zapotrzebowania, niezawodnie prowadzą rozmowy z najbardziej niestabilnymi klientami w naprawdę prymitywnych sieciach i nigdy nie musimy się o to martwić. Po prostu nadal służą.

To jest mój punkt widzenia: serwery WWW to po prostu: serwery. Nie wiedzą nic o treści, nic o użytkownikach, nic poza tym, jak dużo czekać i rzetelnie odpowiadać.

Wybór serwera internetowego powinien odzwierciedlać preferencje dotyczące dostarczania, a nie oprogramowanie. Twój serwer WWW powinien być odpowiedzialny za obsługę, a nie przetwarzanie lub logikę.

CZĘŚĆ DRUGA: OPROGRAMOWANIE (PYTHON)

Oprogramowanie nie działa. Oprogramowanie istnieje tylko w czasie wykonywania. Oprogramowanie nie jest zbyt przystosowane, jeśli chodzi o nieoczekiwane zmiany w swoim środowisku (pliki nie są zgodne z oczekiwaniami, zmiana nazw parametrów itp.). Chociaż optymalizacja powinna być głównym założeniem twojego projektu (oczywiście), samo oprogramowanie nie optymalizuje. Programiści optymalizują. Oprogramowanie wykonuje. Oprogramowanie wykonuje wszystkie czynności opisane w sekcji „celowe mamrotanie” powyżej. Cokolwiek.

Twój wybór lub projekt oprogramowania powinien odzwierciedlać Twoją aplikację, wybór funkcjonalności, a nie wybór serwera WWW.

W tym miejscu tradycyjna metoda „kompilowania” języków na serwery sieciowe staje się bolesna. W końcu umieszczasz kod w swojej aplikacji, aby poradzić sobie z fizycznym środowiskiem serwera lub przynajmniej jesteś zmuszony do wybrania odpowiedniej biblioteki „opakowującej”, która ma być dołączona w czasie wykonywania, aby stworzyć iluzję jednolitości na serwerach internetowych.

CZYM JEST WSGI?

A więc w końcu czym jest WSGI? WSGI to zestaw reguł , napisanych w dwóch częściach. Są napisane w taki sposób, że można je zintegrować z każdym środowiskiem, które sprzyja integracji.

Pierwsza część, napisana po stronie serwera WWW, mówi „OK, jeśli chcesz mieć do czynienia z aplikacją WSGI, oto jak oprogramowanie będzie myśleć po jej załadowaniu. Oto rzeczy, które musisz udostępnić aplikacji, a tutaj to interfejs (układ), którego możesz oczekiwać od każdej aplikacji. Co więcej, jeśli coś pójdzie nie tak, oto jak aplikacja będzie myśleć i jak możesz oczekiwać, że będzie się zachowywać ”.

Druga część, napisana dla oprogramowania aplikacji Python, mówi „OK, jeśli chcesz mieć do czynienia z serwerem WSGI, oto jak serwer będzie myślał, kiedy się z Tobą skontaktuje. Oto rzeczy, które musisz udostępnić serwerowi i tutaj jest interfejs (układ), którego możesz oczekiwać od każdego serwera. Ponadto, jeśli coś pójdzie nie tak, oto jak powinieneś się zachować, a oto co powinieneś powiedzieć serwerowi. "

Więc masz to - serwery będą serwerami, a oprogramowanie będzie oprogramowaniem, a oto sposób, w jaki mogą się świetnie dogadać bez konieczności uwzględniania specyfiki drugiego. To jest WSGI.

Z drugiej strony mod_wsgi jest wtyczką do Apache, która pozwala mu komunikować się z oprogramowaniem zgodnym z WSGI, innymi słowy mod_wsgi jest implementacją - w Apache - zasad części pierwszej powyższej instrukcji.

A co do CGI ... zapytaj kogoś innego :-)

Marka Henwooda
źródło
21
Zamiast pozwolić, aby ta odpowiedź kończyła się na „zapytaj kogoś innego”, chciałbym, aby ktoś zmodyfikował tę odpowiedź, aby uwzględnić CGI w ten sam sposób.
Bruno Bronosky,
1
„serwery będą serwerami, a oprogramowanie będzie oprogramowaniem” - „serwery są z Marsa, a oprogramowanie z Wenus” :)
Rahul
22

Jeśli nie masz jasności co do wszystkich terminów w tym miejscu, i spójrzmy prawdzie w oczy, jest to mylący, pełen akronimów, jest też dobry czytnik tła w postaci oficjalnego Pythona HOWTO, który omawia CGI, FastCGI i WSGI, i tak dalej na. Żałuję, że nie przeczytałem go najpierw.

Richard Boardman
źródło
21

Zarówno CGI, jak i WSGI definiują standardowe interfejsy, których programy mogą używać do obsługi żądań WWW. Interfejs CGI jest na niższym poziomie niż WSGI i wymaga, aby serwer ustawiał zmienne środowiskowe zawierające dane z żądania HTTP, przy czym program zwraca coś sformatowanego prawie tak, jak czysta odpowiedź serwera HTTP.

Z drugiej strony WSGI jest specyficznym dla Pythona interfejsem nieco wyższego poziomu, który umożliwia programistom pisanie aplikacji, które są niezależne od serwera i które mogą być opakowane w inne aplikacje WSGI (oprogramowanie pośredniczące).

Wooble
źródło