承上篇來源

POST req/res 範例

因表單行為 (submit) 而產生。

req

與 GET 像似， 第一行則改為 POST。
最主要差異在於 URL 不存在任何參數，以及表單資訊寫在 req body 之中

res

與 GET 相似， 302 Found 這個訊息讓 browser 知道 POST succeeded 。

Static sites 靜態網站

第三天有提過，是寫死 (hard-coded) 的內容。
假設只有少量的產品，在網站中要修改、新增、刪除或許不會花很多實踐，
但如果產品量多，要做以上的事情要分別在每一頁進行，很沒有效率；
靜態網站適合頁數很少的網站，但若網站規模會變大，會消耗大量成本。

再看一次之前的圖， user 想要連到一個頁面， browser 發送 GET req ；
server 接到 req ， 回傳 res (document + status code)

靜態的 server 只需要處理 GET req ， 因為 server 不儲存可修改的資料，
也不因 HTTP Req(URL parameters or cookies) 不同而改變 res

了解靜態網站對學 server-side programming 很有用，因為動態網站處理靜態檔案(CSS, JS, images, etc.)的 req 與靜態網站的處理方式一樣

Dynamic sites 動態網站

是一個可以回傳因特定 req URL 所產生內容的網站。
以商品網站為例： 跟靜態不同， server 會在 db 儲存 data 。當接到商品 HTTP GET Req ， server 會判斷是哪個商品 ID 進而從 db 拿取資料，
接著把資料塞進 template ，構築 res HTML 頁面。

相比靜態，這樣做最主要的好處是： db 允許以可擴充、可修改、可被搜尋的方式，來有效率地儲存商品資訊

而 template 的好處在於可以輕鬆地改變 HTML 結構，因為只需要在一個 template 修改一個地方，不需修改上千、甚至更多的頁面

解析動態 req

為了更貼近現實，這裏舉個「球隊管理網站」的例子，球隊教練可以在表單選擇隊名、球隊規模，並取得「最佳球員組合」來應對下一場比賽。

下圖是該網站示意圖， 當教練進入最佳組合名單時， 會有一系列的執行動作。
Web Application ( 與 server-side code 處理 req, res ) db 及 templates 組成動態網站

教練把表單填好隊名及隊員名單 submits 之後，一連串的操作如下：

1. Browser 生產 GET req 給 resource ( /best ) server，
   用 URL parameters ( /best?team=my_team_name&show=11 ) 或 URL pattern ( /best/my_team_name/11/ ) 寫入隊伍資料
2. Server 偵測到 req 是動態的， 並通知 Web App 處理
3. Web App 根據 URL ( /best/ ) 辨識 req 的目的是要取得「最佳球員名單」， 找出球隊名稱及隊伍人數； 接著 Web App 從 db 拿取資訊。
   db 參照 internal parameters 來定義哪些球員被稱為「最佳」， 同時也可能從 client-side cookie 取得教練的登入身份
4. Web App 將取出的資料放入 template 的保留位 ( placeholders ) ，動態產生 HTML page
5. Web App 透過 Web Server 回傳 HTML 給 browser， 同時夾帶 HTTP status code (200 success)； 若有回傳被阻斷， Web App 會夾帶另一個 status code ( e.g. 404 )
6. Browser 著手處理被回傳的 HTML ， 接著個別送出不同的 req ， 來取得 CSS 或 JS
7. Server 從 file system 載入靜態檔案， 然後直接傳給 browser

如果是操作更新球員表現的記錄， 處理方式也很相似， 差別在於 browser 是發送 POST req 。