如何開發一個Python web框架？

01-04

需要哪些預備知識，有什麼要注意的，哪些流行的Python web框架適合參考、學習？

謝邀（ @WHPython ），第一次在知乎上回答問題，各位大牛見笑了。

那麼首先是不好意思，因為小夥伴肯定也知道我們這裡馬上要考試了，所以我就簡單寫一點，一方面是要把一些平時作業補上，另一方面是我也要盡量避免涉及太高深的內容導致裝*失敗（畢竟太嫩沒有工作經驗），當然還有一個重要的原因是內容實在太龐雜啦。好的，我們就開始吧。

首先你需要知道一個Web應用基本的請求處理流程。以最簡單最原始的動態網頁為例，你點擊鏈接（GET），提交表單（POST），就是與伺服器端建立了連接之後發送了一個HTTP請求（RFC2616 5.1節，之後都以HTTP 1.1為例），裡面至少有方法（動詞，就是GET啦POST什麼的，詳見RFC2616第9節），地址（URL），HTTP版本，還可能帶上Cookie（會話的一般實現機制），緩存相關的信息（RFC2616 13節），User-Agent串等等一堆信息。對於POST請求我們還有表單內容作為請求實體（RFC2616 7.2節），裡面是你填寫的表單內容。

於是我們有了一些關於請求的數據，不過現在一般來講這些數據還在前端伺服器（反向代理，比如nginx，暫且忽略掉負載均衡，反正是透明的，也不考慮裸WSGI容器直接扛請求的情況）的手上，還沒有傳進後端語言（這裡是Python）。我們就針對每一種語言都有特定的機制，用來將HTTP的請求信息映射到相應的編程語言範疇，叫做Web伺服器界面（Web server interface），通用如CGI/FCGI/SCGI，特定於某一語言如WSGI/PSGI/Rack/...，特定於某一操作系統如ISAPI（這貨還活著？），一些已經不再使用的就不提了。總之在Python世界裡這就是WSGI（PEP 3333, Web Server Gateway Interface），它就定義了Python語言與Web伺服器之間的界面。在WSGI里，

請求的處理過程被映射為對應用callable的調用（application(environ, start_response)，知乎不支持inline代碼塊？）；
請求信息被映射到environ字典中的相應鍵值，比如請求方法被映射到environ["REQUEST_METHOD"]，請求的「相對路徑」被映射到environ["PATH_INFO"]（過度簡化；暫且不提WSGI應用掛載點，框架層一般也不用關心這個，掛載WSGI應用一般是WSGI容器如gunicorn、uWSGI之類組件的工作）；
發送響應頭的動作被映射到調用start_response(status, response_headers)（不考慮可選的第三個參數異常信息）；
返迴響應數據被映射到application返回iterable的動作。

於是響應便從Python返回到Web伺服器，再被發送回瀏覽器，瀏覽器將響應內容渲染，一個請求就完成啦。

有了這樣的感性認識，那麼我們作為Python Web開發框架的作者，要做的事情就是在WSGI規範的基礎之上，提供儘可能便捷的開發手段和儘可能低的框架開銷，也即我們的代碼將要工作在WSGI與業務邏輯的中間層。架構上，Web開發框架或多或少都遵循MVC的設計模式（Django管它叫MTV，其實差不多）。同時，由於框架位於中間件的位置，加上其鼓勵模塊化與代碼復用的性質，自然需要為常見的HTTP操作提供抽象。這裡就可以展開一些話題：

請求路徑到view/controller的映射，請求參數的解析（routing，也叫路由）。

正則匹配的方案，比如Django內置了一個簡單的正則表達式解析組件，能解析一般常見語法的正則表達式，把capturing groups解析成位置參數，named capturing groups解析成關鍵字參數。
也有DSL的方案，比如Werkzeug的路由組件。

請求實體的處理。表單解析，配合Web伺服器進行上傳文件處理。

正常的urlencoded表單，JSON表單，text/plain數據，multi-part表單
multi-part附件，附件操作API
大文件上傳（這個一般會被前端伺服器保存在磁碟上的臨時文件里，比方說nginx就是這麼實現的）。

會話。HTTP是無狀態（stateless）的，這個特點非常重要。如果沒有會話，你連續做幾個請求，卻沒有手段證明你們是同一個人/同一台機器（你完全可能是代理伺服器）。

存儲會話數據的會話後端（內存數據結構？文件？RDBMS？Redis？Memcache？）
安全機制（HMAC什麼的，可以參考beaker的secure cookie實現）
請求處理流程中的會話中間件（從Cookie中提取會話，從query string中提取會話，從自定義頭中提取會話，等等）

View/Controller界面。發揮你的創造力，用上你的工程經驗。

Function-based or Class-based views? 參考：Django, Bottle, web.py, Tornado等一票框架的做法
框架的可選機制與服務如何暴露，

裝飾器？（比如@login_required 這種額外要求）
回調？（能想到的只有Tornado和Twisted這種非同步框架做事情的方式，還有整個JS生態系統都是回調（不考慮Promise什麼的）的思路）

傳入應用（業務邏輯）層的數據結構如何設計？（HttpRequest等價物，名字可能記不清了）
響應數據結構如何設計？（HttpResponse等價物，同上）

資料庫操作封裝。Web應用基本都是數據為中心，這個組件非常有必要，也是撰寫可復用代碼必須的一環，畢竟光是框架抽象了，資料庫操作還是裸SQL什麼的，到時候生產環境一換（比如MySQL變pgsql）還不是傻眼。

關係型資料庫。一站式解決方案參考：Django ORM、SQLAlchemy；輕量級解決方案參考各資料庫Python綁定。
非關係資料庫。各資料庫Python綁定（pymongo, riak, redis-py之類），這個沒什麼可替代方案了，因為本來各種NoSQL庫都是適應某一特殊需求設計的，沒什麼互相替換的必要，那意味著重新進行技術選型。

未完待續

接下來的內容：

主要響應AJAX/API請求的框架設計思路
Python下實時Web框架思路
框架設計哲學
框架性能分析方法

本人才疏學淺，大項目沒做過，小項目也沒怎麼起飛過，請各位閱讀我的觀點時務必留心。讀到最後非常感謝。

Changelog

2014/12/28 18:25 第一次補充，昨天想寫的時候已經上床了客戶端不能編輯富文本哭哭哦

我發現富文本編輯功能了，長期寫reST和Markdown一時間不會用所見即所得編輯了
給前面的內容加了一些例子，微調了一些敘述，具體的話我暫時懶得起git庫管理了
加上了框架資料庫操作的內容

首先你的有一個成功的商業網站模式，類似linkedin，facebook之類的大網站，當然我們不可能寫到那麼大的架構。但前提這個網站模式得有其他人去用。不然寫成框架給自己一個用也太TM浪費了。

算是有始有終吧，做了個簡單的，今天想起拿出來.ladder1984/globefish · GitHub

首先你要會用python

學個簡單的web框架譬如flask什麼的，了解框架應該有什麼，大概怎麼用的。

然後讀一讀bottle，一個文件而已，看懂之後，差不多了。

剩下的了解一些請求和請求處理知識，不懂的搜一搜

僅做參考

werkzeug實現簡單Python web框架（1）：MVC模式

werkzeug實現簡單Python web框架（2）：添加jinjia2模板支持

werkzeug實現簡單Python web框架（3）：添加動態路由

werkzeug實現簡單Python web框架（4）：添加orm支持

werkzeug實現簡單Python web框架（5）：擴展思路

Bottle single file

至少寫過幾年項目，看過其他框架的代碼。

Kiss - 天才小三斤

可以看看我寫的python web 框架系列文章。

這裡補充一下. 有朋友說現成的框架這麼多，我們還需要開發一個嗎? 需要, 不是要專業的做開發框架, 而是在開發框架的過程中，能夠讓我更加的理解, 認識框架, 對開發有很大的好處，所以我認為Web開發者都應該對框架有所了解(至少源碼得讀一遍).
寫好一個Web框架不是一兩天的事情，那我們可以先從寫一個簡單的開始, 不斷進行重構，迭代.
需要掌握一些基礎的知識, 協議, TCP, HTTP, WSGI. 網路IO模型(blocking/non-blocking, Sync/Async).
設計，一些好的框架都有一些好的設計在裡面，讓在此框架上開發的人員感覺很爽.
現成的一些框架, 讀一些目前流行框架可以了解一些新開發技術, 益處多多. tornado, flask, 剛開始讀的時候可以看框架最初的版本, 可以從http://github.com中下載.