注: 個人拙見鹉究，就事論事，如有另解踪宠，還望不吝斧正
前言
軟件無論是從高層抽象還是底層實現(xiàn)自赔，都是輸入輸出的過程。
如果你要實現(xiàn)a+b,會選擇交給服務(wù)端做柳琢，還是客戶端做绍妨？
MVC润脸，傳統(tǒng)BS架構(gòu)項目首選模式，相對于CS架構(gòu)項目他去，服務(wù)器需要做的事情更多了毙驯，接受輸入數(shù)據(jù)（可能來源于請求、磁盤文件灾测、數(shù)據(jù)庫爆价、內(nèi)部維護的狀態(tài)等），渲染（填寫）view媳搪，返回客戶端铭段。
而客戶端最主要的職責(zé)是解析html，結(jié)合css渲染頁面秦爆，通過js實現(xiàn)交互序愚、計算、數(shù)據(jù)請求或其他的一些事情鲜结。當(dāng)然，瀏覽器為我們做了這些活逆，這也是開發(fā)成本降低最主要的原因精刷。
BS架構(gòu)的流行的原因，或許源自以下優(yōu)點
- 維護成本低
- 更新幾乎是實時的蔗候，無需在新版本推出后更新客戶端
- 業(yè)務(wù)怒允、資源、服務(wù)集中锈遥，易于管理
- 服務(wù)不依賴于客戶的操作系統(tǒng)纫事、硬件資源
其中最后一條不曉得能不能算是優(yōu)點，因為出現(xiàn)了瀏覽器所灸，后端開發(fā)者將大多數(shù)工作放在了服務(wù)端丽惶，圍繞程序員們的工作可能就是怎么處理業(yè)務(wù)邏輯、怎么應(yīng)對高并發(fā)爬立、怎么應(yīng)對各種高效率讀寫钾唬。
而前端開發(fā)者的主要工作環(huán)境從某一操作系統(tǒng)的桌面環(huán)境遷移到了瀏覽器環(huán)境，編寫html侠驯、css抡秆、js。處理用戶的各種操作吟策，并作出體驗響應(yīng)儒士，將數(shù)據(jù)提交得到服務(wù)器響應(yīng)，從而作出業(yè)務(wù)響應(yīng)檩坚。
所以着撩，后端關(guān)注用戶群體驗诅福，前端關(guān)注用戶體驗。
REST API 架構(gòu)的提出
一種軟件架構(gòu)風(fēng)格睹酌，設(shè)計風(fēng)格而不是標準权谁，只是提供了一組設(shè)計原則和約束條件。它主要用于客戶端和服務(wù)器交互類的軟件憋沿⊥浚基于這個風(fēng)格設(shè)計的軟件可以更簡潔，更有層次辐啄，更易于實現(xiàn)緩存等機制采章。
來源：百度百科
以javaEE中的jsp為例，我們想控制一個網(wǎng)頁的標題壶辜，可以怎么做悯舟？
- 方案1
<html>
<head>
<title><% conf.title %></title>
</head>
<body></body>
</html>
conf對象或許會是上層業(yè)務(wù)邏輯提供的一個數(shù)據(jù)對象，由web容器對這個jsp進行渲染砸民，最終輸出為一段純html代碼給客戶端抵怎。如下：
<html>
<head>
<title>網(wǎng)站標題</title>
</head>
<body></body>
</html>
- 方案2
以javaEE的servlet為例:
public class WebTitle extends HttpServlet{
public void doGet(HttpServletRequest request, HttpServletResponse response)14 throws ServletException, IOException{
response.write("網(wǎng)站標題");
}
}
編寫html：
<html>
<head>
<title>獲取失敗</title>
</head>
<body>
<script src='jquery.min.js'></script>
<script>
//請求渲染數(shù)據(jù)
$.get('/WebTitle',function(data,tag){
if( tag == 'success' )
$('title').text(data);
});
</script>
</body>
</html>
這樣就獲取了標題數(shù)據(jù)，并渲染到title這個dom節(jié)點上了岭参。
對比方案1與方案2不難發(fā)現(xiàn)反惕，他們做同樣的事情，主要的區(qū)別在于：數(shù)據(jù)誰來渲染(填寫)演侯？
js提供給前端開發(fā)人員邏輯表達的能力姿染，除了操作dom做特效，同樣也可以進行業(yè)務(wù)處理秒际，較輕的業(yè)務(wù)邏輯可以不提交給服務(wù)器悬赏，動用客戶瀏覽器的計算能力自行解決，對于數(shù)據(jù)敏感或者計算復(fù)雜的業(yè)務(wù)邏輯娄徊，可將請求提交至服務(wù)器來做闽颇，而傳統(tǒng)的MVC幾乎將所有的業(yè)務(wù)邏輯都放在后端去做，盡量忽略瀏覽器的計算能力寄锐，如dom通常不變換进萄，不用局部刷新，不需要實時響應(yīng)等锐峭。
各種MVC的框架中鼠，幾乎處理了各種前后端交互的問題，各種渲染問題沿癞，但對于前后端的分離援雇，以及前后端職責(zé)的問題總是弄不清楚，比如：讓前端人員給后端html椎扬，后端人員“翻譯為動態(tài)”的惫搏，這一過程屬于成果共享具温，后端共享前端提交的代碼，而修改后的結(jié)果需要前端去保證各種js筐赔，css執(zhí)行正確铣猩，對于成果修改造成的任何后果，前后端都有責(zé)任茴丰，并且因為術(shù)業(yè)專攻的問題达皿，而雙方總要把手伸向自己不熟悉的領(lǐng)域，必然會影響開發(fā)效率贿肩。
REST API的出現(xiàn)峦椰，使得前后端分離問題比較好的解決。以下是個層級之間的情況汰规。（JSON只是數(shù)據(jù)的一種表達方式汤功，項目中可能會自選適用于當(dāng)前應(yīng)用場景的格式，流行的還有XML等格式）
| 層級 | 面向?qū)ο?/th> | 主要業(yè)務(wù) |
|---|---|---|
| 前端 | json體 | 處理請求,返回json |
| 后端 | 請求 | 處理用戶交互,請求數(shù)據(jù)溜哮，渲染DOM節(jié)點 |
REST API 應(yīng)用的意義
以下是筆者認為以REST API為架構(gòu)的項目優(yōu)勢：
服務(wù)端業(yè)務(wù)基本處于穩(wěn)定滔金，不需要因服務(wù)想要進軍其他平臺而做太多改變。比如web端的功能做好了茂嗓，想要做移動端餐茵，可以選擇做APP享受本地系統(tǒng)資源（短信，照相在抛，地理位置钟病，存儲）萧恕，同時部分與本地資源無關(guān)的業(yè)務(wù)可直接與REST API交互刚梭，代價通常為想要進軍的平臺現(xiàn)有一個HTTP協(xié)議的實現(xiàn)或者自己實現(xiàn)悟耘，而服務(wù)端不需要做太大修改堪唐。
前后端工作均依賴接口，工作職責(zé)清晰捍靠，代碼組織方式清晰走趋。后端：輸入請求衅金，輸出json。前端：輸入json簿煌，輸出視圖相關(guān)內(nèi)容（HTML CSS）
個人觀點:一個應(yīng)用只有不到5%的業(yè)務(wù)氮唯，非常需要依賴本地資源。程序及輸入&輸出姨伟，只是有時候惩琉，我們需要的輸入不來僅僅自用戶的鍵盤或鼠標輸入，可能是用戶的攝像頭夺荒，可能是用戶的話筒瞒渠，等等良蒸，拓展到其他硬件平臺也一樣，一個應(yīng)用依賴的是對數(shù)據(jù)的處理方式（業(yè)務(wù)邏輯）伍玖，而這種方式通常都在服務(wù)端（本地應(yīng)用除外）
REST API 相關(guān)技術(shù)棧推薦（針對個人開發(fā)者或小型開發(fā)團隊嫩痰，面向非高并發(fā)應(yīng)用場景）
后端
- 數(shù)據(jù)存儲層：Mysql Mongodb SQLServer
- 業(yè)務(wù)邏輯層： PHP JAVA ASP JS（node.js） 以及其他支持HTTP協(xié)議的，對JSON格式數(shù)據(jù)與自身語言相關(guān)數(shù)據(jù)結(jié)構(gòu)體的轉(zhuǎn)化代價較低的任何語言窍箍。
前端
- 渲染相關(guān):JQuery Vue 其他（筆者沒用過串纺。。仔燕。）
- 后端數(shù)據(jù)交互: JQuery.ajax 其他（筆者沒用過造垛。。晰搀。）
