記得大學搞編程的時候，比起研究數據結構，做算法題，我更喜歡搞 web 編程。因爲做 web 是可以通過瀏覽器快速看到效果的，可視化的頁面也能帶給自己滿足感。
我畫了個圖，讀者朋友可以感受下，自己作爲用戶，請求自己代碼編出來的頁面，豈不是很有成就感？
如果你作爲用戶來訪問互聯網資源，那麼大概的過程是這樣的：你在瀏覽器是錄入 URL 或者點擊一個超鏈接後，瀏覽器會請求 DNS 服務器解析這個 URL，返回域名映射的IP，然後通過 HTTP 請求這個 IP 對應的 web 資源，如果涉及到一些數據的查詢，還會訪問數據庫服務器獲取數據，然後把數據返回，web 服務器將數據和樣式處理下，轉成 web 資源，然後返回給瀏覽器，經過瀏覽器的渲染，你就能看到可視化的頁面了。
但那時搞 web 編程還比較麻煩，什麼 JSP，ASP，前端代碼和後端代碼雜糅在一起，就這麼你離不開我我離不開你似的在 web 服務器上跑着，代碼看上去不清爽，很多業務邏輯也沒法被其它站點複用。
假設現在有三個巨頭企業，他們分別維護 baitu.com，kk.com，taopao.com 三個站點，這些站點向服務端的交互都是通過 JavaScript 客戶端實現的。某一天三家合併了，那就會涉及很多業務互通，比如 baitu.com 站點下想訪問 kk.com 的一些數據。
這時候該怎麼做呢？過去通用的解法是用 SOAP（Simple Object Access Protocol，簡單對象訪問協議），這是一種基於 XML 格式以及 HTTP 傳輸方式的數據交換協議。
前端 JavaScript 是不能直接訪問 SOAP 服務的，需要先訪問到 baitu.com 對應的網站後臺，然後由網站後臺去訪問 kk 提供的 SOAP 服務（要在之前網站後臺直接訪問數據庫的邏輯上，抽取單獨的服務層出來），然後再由 baitu.com 的網站後臺對返回的數據進行渲染，將 HTML 等資源信息返回給前端。
那麼這時候問題就來了，我在 baitu.com 上的一個前端頁面上，一旦想加點 kk 纔有的數據，我就必須得改 baitu.com 的網站後臺，並且要重新接入 kk 提供的 soap 服務。這顯然是一種低效的架構方式，相當影響研發效率。
那麼有沒有一種方式，我不需要經過 baitu 的網站後臺，直接就能訪問到 kk 的服務呢？頁面上業務邏輯的處理，就不要放網站後臺了，在 JavaScript 的客戶端直接做掉，通過訪問後端的某種服務獲得業務處理的結果，然後基於網站後臺存放的 HTML 和 CSS 來渲染頁面。
就像圖示的這樣，baitu 的 JavaScript 客戶端就做兩件事，訪問後端服務獲取業務邏輯處理的結果數據，將數據以 網站後臺存放的 HTML 和 CSS 的要求展示出來。這樣看來，網站後臺就像個殼，只負責本站的 HTML、CSS 和 JavaScript 等靜態資源，相關的業務邏輯處理就交給服務來提供。
這就是前後端分離的思想，前端靜態資源和後端動態服務解耦。前端只關心 HTML 等前端代碼，不涉及一行後端代碼，後端只關心自己提供的服務，不涉及一行前端代碼。
在這種思想的指引下，SPA（single page web application，單頁面應用）就出現了。SPA 是單個 HTML 頁面的 Web 應用程序，它在用戶與應用程序交互時由 JavaScript 動態更新頁面。其工作原理如圖。
瀏覽器客戶端一開始會加載必需的 HTML、CSS 和 JavaScript，之後的所有的操作都在這張頁面上完成，由 JavaScript 來控制，通過某種數據格式和服務端產生交互，獲取返回結果。
這個時候，客戶端就需要服務端提供的業務服務得是一個 API(應用程序訪問接口)，客戶端可以直接發起請求，這時候 REST API 就派上用場了。
什麼是 REST 呢？
REST 是 REpresentational State Transfer（表述性狀態轉移） 的首字母縮寫，這名字什麼鬼？好難理解的樣子，不過它本身就源於國外一個博士的論文，論文嘛，大家都知道的，一般不太好理解。我這裏畫了個圖，通過分拆的方式，幫助大家理解下：
REST 是一種設計思想，它的核心是資源，可以理解成在 REST 的世界裏，萬物皆資源。
- REpresentational（表述性）：這是個形容詞，它想要表達的意思是，資源可以用各種形式來進行表述，無論是 XML、JSON 還是 HTML，只要適合資源使用者，任何形式都可以。
- State（狀態）：這是個名詞，也是 REST 思想的本質。它告訴開發者，REST 關注的是資源當前的狀態，而不是對資源採取的行爲。無論資源的形式如何變化，它要表達的內容其實是統一的，該資源存在還是不存在，單個信息還是多個信息，都有哪些屬性，這就是資源的狀態。
- Transfer（轉移）：這是個動詞，它指轉移資源，以某種表述性形式把資源從一個應用轉移到另一個應用。轉移過程中，資源狀態可能會有所變化。
在 REST 中，資源是通過 URL 進行識別和定位的。對資源的操作，是通過 HTTP 方法來定義的。HTTP 方法一般會映射到數據層的 CRUD 動作：
| 數據層動作 | HTTP 方法 | 描述 |
|---|---|---|
| Create | POST | 新建資源 |
| Read | GET | 獲取資源 |
| Update | PUT 或 PATCH | 更新資源 |
| Delete | DELETE | 刪除資源 |
此映射不是嚴格限制，讀者朋友可以根據實際情況靈活映射。
比如很多網站會維護用戶的個人資料信息，如果用 REST 來設計相關操作的 API，可以這麼設計：
| 操作項 | URL | HTTP 方法 |
|---|---|---|
| 新增個人資料 | http://api.example.com/profile | POST |
| 查詢個人資料 | http://api.example.com/profile | GET |
| 修改個人資料 | http://api.example.com/profile | PUT |
| 刪除個人資料 | http://api.example.com/profile | DELETE |
簡單講，REST 就是 URL 定位資源，HTTP 方法操作資源。
REST 的出現是對過去編程模式的重大顛覆，除了架構上客戶端服務的解耦，前後端各司其職，也極大提升了開發團隊的研發效率。希望我在編程模式上的變化和思考能對你有所啓發。
以給我點個贊，分享給身邊朋友，非常感謝讀者朋友，也歡迎關注我，我會分享更多優質原創內容。