簡介
上次介紹完了前端和後端在做什麼，這次來講一下網頁開發這一行的演進歷史，也順便帶一些網頁開發常會聽到的名詞和基本概念。
網頁開發這一行不是一蹴可幾的，而是前人流著鮮血汗水發展出來的。現在所寫的每一行code，在十年後，都會腐爛而不能用。話雖如此，這些腐爛的程式碼，都是孕育下一代網頁開發的養分。了解這些歷史，就能更加了解前後端是在什麼情況下做分支的，以及它們形成的必然性。
開始囉！
1991年8月6日，Tim Berners Lee發表了第一篇有關World Wide Web的摘要，標誌著網頁時代的來臨，最初網頁的功能是被科學家用來交換和分享信息，而這時候全世界的伺服器也寥寥無幾。
這時候伺服器的功能非常的簡單，簡單到不能再簡單，我說真的，十分的簡單。
夠了，我知道你想表達它很簡單，所以到底是怎麼個簡單法？
這時候的伺服器，就只有提供html文本的功能而已。這時期的早餐店沒有老闆娘，只有自動點餐機（什麼，這種早餐店也太先進了吧XD）。會類比成點餐機的原因，是因為他就像一般的自動販賣機一樣，你點什麼，他只按照你的要求（http request），給你該給的東西，沒有其它額外的服務。理所當然，你所看到的網頁也是非常的簡單，只有html檔標誌的文字，還有一些很簡單很簡單的樣式。
我要一片吐司（按下吐司按鈕）
這是你的吐司。
呃……什麼醬都沒有塗是怎樣？
什麼？這種遠古級的網頁會有誰要看啊？
你說的沒錯，這時候的網頁還在起步階段，我估計聽個收音機都比看網頁有意思多了！不過時代是會進步的，科學家們開始無法忍受簡單的白吐司，於是一個叫CGI（Common Gateway Interface）的東西出現了。
到了這個時代，早餐店進化了，老闆娘覺醒了。對於被一個自動販賣機給取代，她感到非常的不甘。雖然到了打孫子屁屁和玩孫女嘴巴的年紀了，還是親自上陣來服務客人。她心想，我能夠客製化客人的需求，和動態更改菜單，這是我的優勢。
老闆，我要吐司。
好低，這是你的吐司。
老闆，我要巧克力口味的。
好的，這是你的巧克力吐司。
老闆，我要草莓的。
不好意思，今天草莓口味的賣完了。
想像一下，如果今天你想在你的網誌上顯示「我今天很開心」，你會怎麼做？如果今天被爸爸揍了，非常難過，想寫一些髒話，舒發一下心情，你會怎麼做？把所有心情都刻一份html檔？我想應該不是吧。
根據上一篇的內容（我是傳送門），聰明的你應該會把內容輸入到資料庫裡。想要更改的時候，直接改資料庫的內容，伺服器每天就會讀到不同的內容。這個溝通伺服器和資料庫的介面（interface，大陸都叫接口），就叫做CGI。
CGI的功能就是溝通所有非www系統和www server，更加豐富我們的網頁。有了他，我們就可以動態的在html插入我們想要的東西，而不是事先寫死。對於使用者的request，我們也可以客製化各種response，譬如表單的處理也是在這時候開始有的。
CGI可以由各種語編寫而成，在當時，主要是由perl、bash、C等語言編寫的。
腳本（script）語言的的興起
目前我們已經能動態顯示我們的網頁內容了。但是網頁的效率還不是很高，這是因為CGI對於每一個請求，都要開一個進程，實在是太麻煩了。為了處理更複雜的網頁，並且維持高維護性，腳本語言興起了，分別有JSP、PHP、ASP。
為了維持高維護性，一個好的方法是將html製成模版，然後這個模版去動態的填入我們想要的資料。這種感覺就好像你到戶政事務所去，拿著結婚表格，照著格子填的感覺。今天要嫁誰，要娶誰，填了就對了！這時，腳本語言會在發揮很重要的功能。程式設計師將PHP的程式碼嵌在html裡面，然後當使用者request這個頁面的時候，便自動執行這個腳本，去資料庫拿我們想要的資料填上去。
PHP本身是一個很老的程式語言，在1995年誕生，例如咱們祖克伯祖先生創立的Facebook，便是用這個寫的。雖然是個很老的語言，到現在都還有很多工程師使用PHP做開發。而JSP是使用Sun公司（後來被Oracle給併購）所推出的java語言撰寫的，ASP則是由Microsoft所推出的，這些語言的功能都十分的類似。
前端工程師的工具——CSS出現了
在CSS出現以前，你所看到的網頁大概都像國文老師的板書一樣，非常的平淡。你看了一便，知道他在寫什麼，但是卻high不起來。這是因為老師寫的板書都太單調了，沒有重點畫記，就只是一堆中文字在黑版上，供學生瞻仰。
為了讓網頁看起來更生動，CSS（Cascading Style Sheets）誕生了。CSS1 在1991年被提出，涵蓋了一些簡單但卻基本的功能，例如行距、字的顏色、大小……。
有了這個工具，國文老師終於有其它顏色的粉筆了。
瞧，你的老師正在畫岳陽樓，范仲淹在黑版的角落邊喝酒邊說「慶曆四年春，滕子京謫守……」，有沒有很high？
MVC
隨著網頁規模的加大，不同的網頁架構也不斷的被提出，也不斷的被試作和淘汰。
MVC（model，view，controller）上台了，他們是三個合作無間的兄弟，一起完成製作網頁這件大事。三個人在網頁製作上都各懷絕技，又真心合作，如果謞他們來當總統+行政院長+立法院長的話，台灣大概會有22000K那麼多。呃，我是說人口。
MVC是一種軟體架構模式，而所謂的軟體架構模式，是一個選項，而不是強制。按照某個模式下去設計網站架構和分派工作，或許會有意想不到的收獲，也或許導致專案的崩潰，沒有絕對，端視模式的好壞。就好像老師都希望學生開啟好寶寶模式，但有些學生適合這種模式，有些卻不適合，執行起來成效如何，全看學生自己的造化。
MVC的大哥model，大體來說就是負責資料和邏輯，而二哥view，則負責畫面的顥示。至於可憐的小弟，沒辦法，只能被哥哥們使喚，就負責溝通大哥和二哥的工作，當大哥有資料要傳給二哥的時候，就交給三弟，然後三弟就告訴二哥該在畫面顯示什麼。除此之外，三弟可忙得很，身兼客服工作，還要負責client的request，然後把request轉交給大哥，然後大哥model根據request，去提取或修改資料。
這樣說起來似乎有一點複雜，不過上個圖就能夠了解了。
講了這麼多，讓你休息（REST）一下吧！
幫我倒杯茶好嗎，我的舌頭也該REST一下。
謝囉，還記得第一篇（我是傳送門）提到的get和post嗎？
我想想，好像是client的browser用來跟server溝通的一個手段吧？等等，你不是讓我要休息（REST）嗎，怎麼還繼續講？
太棒了，孔子躺在地下也會起來跟你說聲「孺子可教也！」之前提到的get和post，以及我接下來要說的put和delete，都是屬於RESTful API的一部分。知道為什麼要REST一下了吧！
在提到REST（Representational State Transfer）之前，先講解一下API（Application Programming Interface）是什麼。API指的是應用程式和應用程式，library和library之間，或者應用程式和library之間的一個溝通方法。API會定義一些溝通該有的參數，填上這些「事先定義好的」參數，交給對方，就可以享受對方帶給自己的服務。
API在現在的網路世界，對企業，對開發者而言，都是非常重要的東西。譬如Google的Youtube開了很多的API，只要開發者填上該有的參數（例如：長、寬、是否全螢幕……），就可以在自己的網頁內嵌各種影片。設計良好的API，對開發者而言是一大福音，對提供API的library、程式或企業，也是一大樂事。因為好上手的API更受開發者青睞，也就易於推廣，而提供API的平台也就更容易壯大！這也是為什麼Facebook、Google等大公司會一直推出新的，好用的API。
回到REST來說，它是一種設計風格，不是標準，這點要非常注意。所謂的REST，具有幾個很重要而且很明顯的特性。
- 客戶-伺服器（Client-Server）
這個不用解釋了吧XD，就是一個request配一個response
- 無狀態（Stateless）
這個的意是是說client負責狀態的保存。這個講法這樣聽起來會比較堅澀，不過用個登入來講就會好理解許多了。當你登入成功時，會拿到一個session token。然後下次要請求這個server的某個資源時，只要把token一併傳過去，讓server判斷這個是不是對的，可以登入的。這樣一來，可以大大減輕server的負擔，server也就不用記住誰登入了，誰沒登入。
你有聽見server鬆了一口氣嗎？
- 緩存（Cache）
允許傳輸的資料在傳輸過程中的某處被暫存，藉以改善效率。
- 統一接口（Uniform Interface）
client和server藉由統一的溝通方法來進行通信，在網頁的世界裡，就是http協定。
- 分層系統（Layered System）
簡單來說，呼叫API的人只要懂最外層參數讓人怎麼給就好，不需要了解內層是如何實作的。
（摘自維基百科）
而所謂的RESTful，就是實作REST這個設計理念的系統的統稱。
get、post、put、delete和RESTful的關係
等等你先停，你走遠了，所以這個跟GET和POST到底有什麼關係？
嘖嘖嘖！年輕人就是這麼心急！
呃……你也才20歲……別跟我說教
以上提到的這4個方法，是server開給client的4種類型的API
- get：取得資料
- post：新增資料
- put：更新資料
- delete：刪除資料
也就是說server提供給client的api，「大部分」都可以歸類成以下這幾種。當client發出一個request，MVC的三弟controller接到request後，就會把reponse傳到大哥model那去。根據不同的method，model會做出相對應的動作。完成後告訴controller，然後controller再回覆給client，如果要更新view，便同時更新。至於client該request哪一個API，其實是看URL而定的，這個在第一篇也有提到過。
很單純吧，只提供了簡單的4種方法，就包山包海了。也因為REST的設計十分簡單，使開發者容易設計出好的API，所以這個風格已經慢慢的獨霸網頁世界。
結語
今天講了網路發展的歷史，從最早的遠古html，講著講著，講到了RESTful。下一次就會講到前後端的正式分工囉！
欸，你今天喇塞喇好少喔！
當然，趕快講一講，我要去讀段考了QAQ
粉絲專頁——沒一村端筆記
https://www.facebook.com/noootownnotes/
關於我：
我是沒一村，專長和興趣是程式、主動投資、科技商業模式。可以參考我的書單和比較熱門的文章：
REST常常跟SOAP比較
希望作者能在用故事補充^^
謝謝你的意見:)，我覺得這個建議很不錯，謝謝你~~
Pingback: [前端連載] 什麼是AJAX，以及CSS3、HTML5簡單介紹 – 沒一村生活點滴
Pingback: [前端連載] 什麼是AJAX，以及jQuery、CSS3、HTML5簡單介紹 – 沒一村生活點滴
這一篇提到的脈絡詮釋方式很特別。事實上對我而言，很有時空跳躍的感覺。
我接觸到的大概是第二階段的 web (1998年起)。
當時根本不存在網誌這種 UGC 的觀念，大多屬於單向閱讀，雙向閱讀跟興起，以台灣為例是在 2003 左右無名慢慢爬起來跟改變習慣之後，之前大多是 BBS 。
在 1998 年的時候，當時有提供網路空間的，如當年的 pchome 「我的網頁」，就真的是要寫 html 才能上傳，這也成為我最早的 html 啟蒙。(我那時才十二歲，已經學會當時的基本 tag 了。)
後來開始興起的，大概是2000 年左右，奇摩推出奇摩家族，成為很早期除了 BBS 跟線上遊戲外重要的社群前身。
而 css 出來的時候，因為大家還不了解，限制也很多，所以當時其實是受到強烈抵制的，而且因為當時跟工具綁的太緊密，挑戰很大。
我們大概跟這個既有族群奮戰了兩年，寫了很多如 table layout 如何轉換到 float layout 的文章，加上瀏覽器慢慢推出新的規格(但當然，ie6 是陰魂不散的傢伙)，才變成我們今日的 css。
不談別的，第一代 css 根本就沒有現在做 RWD 完整的edia query 概念。(當時只有列印用或瀏覽用的媒介識別)
Media query 完整進入建議規格，其實是 2012 年的事情。
而 css 的大戰，是在 2007 年左右的事情，大概用了兩到三年才讓他成為主要標準。
之類的事情還有很多，其實這些「發展」，真的不是「因為有了現在我們認為的好處」，所以才發展的。甚至在那個時空背景是被視為來找麻煩的。
而且也真的有些規格是來找麻煩的，後來直接淡出消失被視為時代悲劇的。
但當然願意寫普及文章是好的，只是寫教學或入門是一回事，跟發展脈絡是完全不一樣的兩回事。
這些事情的發展過程有他有趣的歷史時空，不能這樣簡化的喔。
Api 跟 restful 的糾葛也不是這麼簡單掛上去的，簡言之 restful 是 api 的一種實作，但 api 並不等於restful 。
事實上 restful 現在也還不是真的大一統的實作，因為實作上還是有很多模糊跟界定難分的地方。
既然寫的是發展脈絡，有些歷史你們可能未必有經歷過，有興趣可以再留言討論，讓文章留下更多歷史刻度。
謝謝TonyQ大指教和分享XD，其實我在臉書有留了言，但我這邊補個更詳細一點~~
我寫這篇的初衷只是為了把我認為當一個前端工程師該懂的基本技術寫下。而我只是個寫網頁還未滿9個月的新手，因此由我來以今觀古，如果把標題訂的太大，ex「脈絡」，我覺得我寫得難免有些過簡和偏頗，也無法完全還原歷史。
那我想請教一下，該加些什麼，或爬些什麼資料呢？或者不以網頁脈絡，而改以單純的新手教學文來說，還缺少些什麼呢？
目前由你的留言看出，在這系列的文章，我想還缺少：
1. AJAX的真正目的，並不限於降低傳輸量，而有其它目的。但這其它目的，還請賜教。
2. media query，這點我著實忘了，RWD的部分，我想我該補。
3. rest 和 api 的定義，我想我拉的不夠明確
4. 瀏覽器大戰？
5. css的詳細發展以及原因？
1. AJAX 我認為比較核心的動力是增加互動的體驗，不換頁對一些應用而言是感受上必要的。
減少傳輸量是達到這件事情的作法跟目標，但其實很多時候為了寫 WEB APP，反而會花更多流量在載入內容，所以單純的切是為了減少傳輸量，我覺得是值得確認的。
2. RWD 要先處理 float 布局。這題目在教學上不好處理。ccc
3. 簡言之，API 是用來用特定格式存取資料的，RESTFUL 是其中特別適合單一 entity 類型的一種存取方式(存在一個單一對象可以對他做 CRUD )。但實務上而言，因為很多時候其實是複合 entity ，比方說使用者忘記密碼這個動作，他其實是一個商業操作，要把他放在 user 去做 put 或 delete 都很奇怪。如果需要權限驗證需求也會是特化問題。
所以通常就得拉出特別的 function ，這雖然沒有被 restful 明確規範符合或不符合，但這種特化實務上讓 restful 的一致性大減。
而且主要是了 CRUD 的規格，讓很多產生器或 framework 預設會幫忙產生 api ，所以有時候忘了關不能做的操作還會出現不必要的安全性風險。
說實在話，從我角度來看，是不是 rest，對 api 而言已經沒有多大意義了。
4. 瀏覽器大戰大概就幾個明確的軸線。safari 跟 opera 當時 mac 市佔一直都不高，而且 opera 有一些特殊規格讓他容易出奇怪的 bug。支援意願不高。
2007~2008 Firefox 出現，當時 firefox 使用者很容易被網頁設計師視為找麻煩的。
(而且兩邊除了運算效能不同以外，很多也真的是 api 設計理念不同)
2008 CHROME 出現，大概兩年左右因為效能比較快，後發先至的使用率迅速超車 FF。
當時其實 IE6 最大的問題是運算速度慢，跟 IE8 比起來慢十倍有，IE7 市佔率很低(因為 win7 直接升級 IE8, 2009 年)，所以，不然當時很多需求包括圓角等，都有現成 js 套件可以做向下相容。
現在做圓角只是個 css 屬性，在 2008 年時，需要用類似 jquery-corner 之類的套件用 div 想辦法視覺上夾出圓角，效能圓角一多就很糟糕。
當時也缺乏很多基本配備，沒有 video 只能靠 flash…. etc
缺乏 drag file and drop 媒介，甚至缺乏一次上傳多檔案的介面，導致這些都得靠 flash 做，結果就是效果很不穩定。
5. 國內 CSS 發展上最重要的里程碑，其實是樣板客制化。如 blog 的 css customization ，當時無名甚至為了這件事情出了一套視覺化工具來處理細節設定。plurk 的自訂 css 也是個好範例。
以前的 html tag 作法無法做到單一套 html 變換樣式，讓使用者改內容又容易出現安全性風險，當時可說是就這樣半哄半騙的讓表格派棄械投降。XDDDD
到後來新進的都認為 css 是比較潮的，需求也特別針對表格切版批評，表格派可說是斷根了。這個震盪對設計師而言，我一直覺得可比擬 dos 轉 windows 等級的差異。
而這也是設計師不太願意踏入的領域，再加上互動程式設計，也以此為基礎，產生了新的需求定義，也就是前端工程。前端工程當時的情況其實是大家原本的角色都不想做的事情，只好創個新角色來吸收這些事情。
早期寫 JS 是會被笑的(2007~2009)，寫 server 好賺多了，網頁又累又難寫瀏覽器又難搞。待遇還比不上後端，我超多朋友轉後端。
當然最近三年國內前端身份水漲船高不可同日而語，但這段需求，是因為前端在歷史上斷過根。
我自己 2011 年發起 js.tw 社群聚會的時候，網頁需求是大的，但職業環境還沒翻轉。2012 年以後才比較穩定跟好一些。
先寫到這裡。
雖然有點回覆得有點晚，但是我有一個搞不懂的點。如果繼續用一開始餐廳的那個例子的話，API扮演的是什麼角色呢？