摘要：也就是說，是連接服務器和應用服務器的橋梁。目前實現的中，有兩個角色分別是和。是一個可調用對象，它包含了一個表示響應狀態的字符串和一個響應的列表以及一個用于出錯返回的信息，具體參數包含及詳情請點這里。可以被連接在一起，由此產生的鏈通常被稱為。

WSGI, 全稱為 Web Server Gateway Interface。

它不是什么框架，它是一個規范，但是作為一個規范，它實際上并沒有官方標準。
這里要說明一下，PEP-0333并不是用來規范WSGI用得，而是PEP-0333提出應該有那么一個東西用來處理web服務器和應用服務器之間的關系，因此產生了WSGI。

因為，就目前來看，Web服務一般按照如下方式部署：

先部署一個web服務器(Apache etc.)用于處理協議層的業務，比如，單臺物理機多服務（多域名或者多端口）、負載均衡等。

然后部署一個應用服務器(Django etc.)，它用于處理具體業務方面的事情，比如，滴滴打車的應用服務器就會處理打車訂單CRUD，處理完成之后呢再返回給web服務器，web服務器收到響應之后再返回給客戶端。

通過上文，我們可以了解到WSGI無非做了兩件事：

讓Web服務器知道如何調用Python應用程序并把從客戶端來的請求拿過來。

讓Python應用程序知道客戶端的具體請求是什么，以及如何返回結果給Web服務器并幫助Python應用程序把計算后的結果返回給Web服務器。

也就是說，WSGI是連接Web服務器和應用服務器的橋梁。

目前實現的WSGI中，有兩個角色,分別是Server/Gateway和application/framework。

當請求來臨的時候，server調用application，然后application把結果返回給server。

接下來，server需要知道去哪能夠找到application。實現這一邏輯，需要在server指定一個Python模塊（具體在server的哪個位置保存這一路徑，那就得根據具體server類型來選擇了，如apache或nginx）該模塊必須包含一個名稱為application的可調用對象，這個對象的形式如下：

在PEP-0333中指出了，一個WSGI的application角色，應該是一個可調用對象：
def application(environ, start_response)

其中，environ是一個包含了關于這次HTTP請求信息的字典，start_response是一個可調用對象，用于在application中執行，用以在返回響應內容前設置響應的狀態碼和響應頭，同時也意味著告訴server，application要開始返回http的body了。這兩個就是server調用application時候需要傳遞的所有參數了。

那么，我們還需要再說一下，environ和start_response()是需要在server端的生成和定義的

有了這兩個參數，application就能知道用戶請求的是什么資源，請求中帶了什么數據，結果該如何返回給server等等。其中，environ包含了一些符合CGI規范的環境變量和WSGI規范新添加的變量，此外還可能有一些系統變量及Web服務器相關的環境變量。start_response是一個可調用對象，它包含了一個表示HTTP響應狀態的字符串和一個HTTP響應headers的列表以及一個用于出錯返回的信息，具體參數包含及詳情請點這里。

下面是一個完整的application demo，最終返回的body也可以是一個可迭代對象，這樣server也可以通過遍歷這個對象來拼接成body。

def application(environ, start_response):
    start_response("200 OK", [("Content-type", "text/plain")])
    return ["Hello World!",]

看上去不錯，那么我們該如何調用呢？

有幾個服務器組件也能夠運行的WSGI應用程序，但是對于簡單的測試目的，我們可以使用包含在Python的標準庫參考實現，就像下面那樣：

if __name__ == "__main__":
    from wsgiref.simple_server import make_server
    server = make_server("localhost", 8080, application)
    server.serve_forever()

好了，還記得我們剛才提到的最終返回的body也可以是一個可迭代對象嗎？在python中，創建一個迭代器的簡單辦法就是使用一個生成器，比如，我們有一個用于靜態文件的服務，我們可以寫一個生成器，讓它一次生成一個固定大小的文件塊，這樣我們就可以隨時一次只存儲一個文件塊了，讓我們來試試吧：

def send_file(file_path, size):
    with open(file_path) as f:
        block = f.read(BLOCK_SIZE)
        while block:
            yield block
            block = f.read(BLOCK_SIZE)

對應的 WSGI application 部分如下:

size = os.path.getsize(file_path)
headers = [
    ("Content-type", mimetype),
    ("Content-length", str(size)),
]
start_response("200 OK", headers)
return send_file(file_path, size)

注意，send_file就是上文中所指的可迭代對象。

看得出來，WSGI應用結構非常簡潔，只需指定一個可調用的識別標記，這使得WSGI應用很容易實現調用其他框架，無非就是修改到來的請求或者修改發出的響應，當然也可以兩者都有。那么，接下來看看demo:

class Filter(object):
    def __init__(self, application):
        self.application = application
        
    def __call__(self, environ, start_response):
        # Do something here to modify request
        pass
        
        # Call the wrapped application
        app_iter = self.application(environ, 
                                    self._sr_callback(start_response))
        
        # Do something to modify the response body
        pass
        
        # Return modified response
        return app_iter
        
    def _sr_callback(self, start_response):
        def callback(status, headers, exc_info=None):
            # Do something to modify the response status or headers
            pass
        
            # Call upstream start_response
            start_response(status, headers, exc_info)
        return callback

像這樣應用通常被稱為Middleware applications或Filter。 Filter可以被連接在一起，由此產生的鏈通常被稱為pipeline。

最后呢，我想說明一下，WSGI是故意設計成最小的Web服務器實現輕松的應用，以便被更多的人采用。但是，幾乎沒有人真的喜歡直接操作environ變量，也幾乎沒有人喜歡用start_response這么詭異的邏輯，雖然WSGI提供的API易于實現，但這不代表它的語義讓人滿意。也正是因為這一原因，幾乎每一個應用程序或者web框架都把environ和start_response封裝成了語義更完善容錯率更高的request和response對象。

Webob就是request和response對象的規范實現之一，它使得WSGI更容易和更滿意地被大家使用。

你可以在這里找到Webob的官方文檔，當然，下次有機會我也會簡單的說明一下Webob到底有多方便。