什麼是WSGI
全名為「Web Server Gateway Interface」 Web伺服器閘道介面，主要規範HTTP請求如何與伺服器溝通， 通常有了協議之後， 伺服端與客戶端就能具有參考依據， 也能照著規範實作與開發， 目的在於讓開發者專注於功能上的開發而避免繁雜的通訊處理。
大致上就是一來一往的過程， 建立一條連線並發送請求之後就必須等待回應。
那什麼又是ASGI呢？
全名為「Asynchronous Server Gateway Interface」 非同步伺服氣閘道介面， 這邊的關鍵字在於「非同步」這三個字， 我們都知道Rest API是一種請求與等待回應的同步等待過程， 這方式雖然簡單明瞭但常常耗費在「等待回應」的過程中， 假如假如我們可以丟出請求後去做別的事情， 等到回傳結果之後再接著回來處理， 那麼中間的空閒間隙就會縮小許多， 避免不必要的空等浪費， 這就是非同步的精神， 關於非同步相關的技術不妨也參考我們的「【Python - asyncio】非同步 I/O 簡介」、「【Web微知識系列】 Web Workers」、「【Web微知識系列】雙向溝通的技術，什麼是Websocket？」。
那麼流程上大致是這樣， 建立連線之後， 資料的傳輸就會基於這條連線進行傳送， 而過程中也沒有所謂的等待。
但沒有等待要怎麼知道這一封訊息是要伺服器做什麼呢？ 這問題非常好， 這種非同步的傳輸對於雙方來說也會需要一種約定的規範， 也常常導入事件驅動開發的架構。
比如說： 我傳給你一封掛號信， 請您收到掛號信之後進行xxx的處理， 處理的內容在於信中。
上述簡短的一個情境就隱含了幾個非常重要的資訊， 首先是「掛號信」， 可以理解為傳輸的資料型態(字串、二進制…)， 我們伺服端根據這樣的差異進行判斷後處理相對應的流程， 這也是一種事件的驅動， 當然「事件」的格式有很多種， 像是JSON、XML…， 我們都可以在欄位裡面描述xxx事件與待處理的內容， 伺服端收到xxx事件之後， 根據內容進行請求處理， 而回應也是這樣的概念， 整個過程非常的彈性， 但容易讓彈性過於膨脹導致混亂， 因此在開發之前， 會盡量的去設計這些事件並進行有限度的規範， 才不會導致後續維護上的困難。
關於事件驅動開發， 我們後續也會整理在「🔒 阿Han的軟體心法實戰營」， 歡迎加入共同學習與討論。
結語
原來設計API還有WSGI與ASGI的差異， 過往只知道選擇一個稱手的框架進行開發， 並未考慮到各個框架的特性， 而如今理解後才知道原來我們的應用可以區分為同步/非同步， 進而選出適合的一套框架， 關於API的技術選型也歡迎參考「【Python 技術選型】如何選出適合的API框架呢？」唷。
