需要哪些預備知識，有什麼要注意的，哪些流行的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節），裡面是你填寫的表單內容。
於是我們有了一些關於請求的資料，不過現在一般來講這些資料還在前端伺服器（
反向 Proxy，比如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內建了一個簡單的Regex解析組件，能解析一般常見文法的Regex，把capturing groups解析成位置參數，named capturing groups解析成關鍵字參數。
- 也有DSL的方案，比如Werkzeug的路由群組件。
- 請求實體的處理。表單解析，配合Web伺服器進行上傳檔案處理。
- 正常的urlencoded表單，JSON表單，text/plain資料，multi-part表單
- multi-part附件，附件操作API
- 大檔案上傳（這個一般會被前端伺服器儲存在磁碟上的臨時檔案裡，比方說nginx就是這麼實現的）。
- 會話。HTTP是無狀態（stateless）的，這個特點非常重要。如果沒有會話，你連續做幾個請求，卻沒有手段證明你們是同一個人/同一台機器（你完全可能是Proxy 伺服器）。
- 儲存會話資料的會話後端（記憶體資料結構？檔案？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一時間不會用所見即所得 (WYSIWYG)編輯了
- 給前面的內容加了一些例子，微調了一些敘述，具體的話我暫時懶得起git庫管理了
- 加上了架構資料庫操作的內容
首先你要會用python
學個簡單的web架構譬如flask什麼的，瞭解架構應該有什麼，大概怎麼用的。
然後讀一讀bottle，一個檔案而已，看懂之後，差不多了。
剩下的瞭解一些請求和請求處理知識，不懂的搜一搜算是有始有終吧，做了個簡單的，今天想起拿出來.ladder1984/globefish · GitHub
首先你的有一個成功的商業網站模式，類似linkedin，facebook之類的大網站，當然我們不可能寫到那麼大的架構。但前提這個網站模式得有其他人去用。不然寫成架構給自己一個用也太TM浪費了。Bottle single file
- 這裡補充一下. 有朋友說現成的架構這麼多，我們還需要開發一個嗎? 需要, 不是要專業的做開發架構, 而是在開發架構的過程中，能夠讓我更加的理解, 認識架構, 對開發有很大的好處，所以我認為Web開發人員都應該對架構有所瞭解(至少源碼得讀一遍).
- 寫好一個Web架構不是一兩天的事情，那我們可以先從寫一個簡單的開始, 不斷進行重構，迭代.
- 需要掌握一些基礎的知識, 協議, TCP, HTTP, WSGI. 網路IO模型(blocking/non-blocking, Sync/Async).
- 設計，一些好的架構都有一些好的設計在裡面，讓在此架構上開發的人員感覺很爽.
- 現成的一些架構, 讀一些目前流行架構可以瞭解一些新開發技術, 益處多多. tornado, flask, 剛開始讀的時候可以看架構最初的版本, 可以從http://github.com中下載.
