簡單英語中的WSGI和CGI是什麼？

Question

我每次讀WSGI或CGI時都會畏縮。我已經嘗試過閱讀它，但沒有真正卡住。

它真的是純英語嗎？

它只是管理請求到終端並重定向輸出？

Answer 1

WSGI在Web服務器啓動時運行Python解釋器，作爲Web服務器進程的一部分（嵌入模式）或作爲單獨的進程（守護進程模式），並將腳本加載到其中。每個請求都會在被調用的腳本中產生一個特定的函數，請求環境作爲參數傳遞給函數。

CGI將腳本作爲單獨的進程運行每個請求，並使用環境變量，stdin和stdout與其「通信」。

Answer 2

CGI和WSGI都定義了程序可以用來處理Web請求的標準接口。 CGI接口的級別低於WSGI，並且涉及服務器設置包含來自HTTP請求的數據的環境變量，程序返回的格式與HTTP服務器的響應非常相似。另一方面，WSGI是一個特定於Python的略高級接口，它允許程序員編寫與服務器無關並且可以封裝在其他WSGI應用程序（中間件）中的應用程序。

Answer 3

從一個完全的後撤步點，Blankman，這裏是我的「介紹頁面」 Web服務網關接口：

第一部分：WEB服務器

Web服務器成爲了迴應。他們坐下來，耐心等待，然後突然間沒有任何警告：

• 客戶端進程發送請求。客戶端進程可能是一個Web服務器，一個機器人，一個移動應用程序，無論如何。這是簡單的「客戶端」
• Web服務器接收到這個請求
• 故意咕噥各種各樣的事情發生（見下文）
• Web服務器發回的東西給客戶
• Web服務器再次圍坐

Web服務器（至少，更好的）非常擅長這一點。他們根據需求擴大和縮小處理範圍，他們可靠地與極其客氣的客戶進行交談，而不必擔心這些問題。他們只是繼續服務。

這是我的觀點：web服務器就是這樣：服務器。他們對內容一無所知，對用戶一無所知，除了如何等待以及如何可靠地回覆之外，其他都沒有。

您選擇的網絡服務器應該反映您的傳送偏好，而不是您的軟件。你的網絡服務器應該負責服務，而不是處理或邏輯的東西。

第二部分：（Python）的軟件

軟件沒有身邊坐下。軟件僅在執行時存在。當涉及到其環境的意外變化（文件不在預期的位置，參數被重命名等）時，軟件並不是非常適應。雖然優化應該是您設計的核心宗旨（當然），但軟件本身並不會優化。開發者優化。軟件執行。軟件完成了上面「故意嘟'」部分的所有內容。可能是任何事情。

您的選擇或軟件設計應反映您的應用程序，您選擇的功能，而不是您選擇的Web服務器。

這就是傳統的「編譯」語言到Web服務器的方法變得痛苦的地方。您最終將代碼放入您的應用程序中以應對物理服務器環境，或者至少被迫選擇適當的'wrapper'庫以在運行時包含，以給出Web服務器上統一的錯覺。

那麼什麼是WSGI？

那麼，最後，什麼是WSGI？ WSGI是的一套規則，分爲兩部分。它們的編寫方式可以將它們整合到任何歡迎整合的環境中。

第一部分是爲Web服務器端編寫的，它說：「好吧，如果你想要處理WSGI應用程序，下面是加載時軟件的思維方式。應用程序，這裏是你可以期待每個應用程序都具有的接口（佈局），而且，如果出現任何問題，應用程序將如何思考以及如何預期其行爲。「

第二部分是爲Python應用程序軟件編寫的，它說：「好的，如果你想要處理WSGI服務器，下面是服務器在與你聯繫時的思維方式。服務器，這裏是你可以期待每個服務器都有的接口（佈局），而且，如果出現任何問題，這裏是你應該如何行動，這裏是你應該告訴服務器。

所以你有它 - 服務器將是服務器和軟件將是軟件，這是一種方式，他們可以相處得很好，而不必爲另一方的細節做任何補貼。這是WSGI。

mod_wsgi的，而另一方面，是Apache的一個插件，讓它跟WSGI兼容的軟件，換句話說，mod_wsgi的是實現 - 在Apache中 - 的規則手冊第一部分上述規則。

至於CGI ....問別人:-)

Answer 4

如果你是在這個空間中的所有條款不清楚，讓我們面對它，這是一個令人困惑的縮寫載貨一個，還有一個很好的背景閱讀器以official python HOWTO的形式討論CGI與FastCGI vs. WSGI等。我希望我會先讀它。