『壹』 web為什麼要前後端分離優點是什麼
解耦，降低耦合度，而且前後端分離可以提升一些後端的開發效率。
『貳』 用web api 分離前後台 會不會有風險
1、 OAuth是做什麼的？
在網上瀏覽時，大家都見過這樣的功能：網站A提供了第三方登錄服務，比如使用新浪微博、QQ賬戶登錄。用戶使用第三方賬戶登陸後，第三方返回Token給網站A，當網站A調用第三方服務請求登錄用戶信息時需傳遞該Token給第三方，第三方才允許該服務請求。之後的每次請求無需再次認證，直接使用該Token即可。這就是OAuth的典型應用。
2、 簡單使用介紹 (具體使用OAuth的方法請參考：在ASP.NET中基於Owin OAuth使用Client Credentials Grant授權發放Token)
2.1、用戶登錄的過程即是獲取Token的過程，前端用戶登錄示例代碼如下：
1 $.ajax({
2 type: "POST",
3 url: api_address + "token", //api_address為WebApi服務地址，由於OAuth的使用中設置了屬性TokenEndpointPath = new PathString("/token")，所以請求到「token」鏈接時即可自動進入認證流程。
4 data: { grant_type: "password", username: username, password: password, ran: Math.random() },//傳遞用戶名、密碼、認證方式
5 dataType: "json",
6 success: function (result) {
7 if (result.access_token && result.access_token.length > 0) {
8 //result.access_token即是有效的服務調用憑證，可以把該值存入到Cookie中，以備下次使用。
9 callback(1, "登錄成功。");
10 }
11 else {
12 callback(0, "未知錯誤！");
13 }
14 },
15 error: function (XMLHttpRequest, textStatus, errorThrown) {
16 callback(0, XMLHttpRequest.responseJSON.error);
17 }
18 });
登錄代碼
2.2、當認證方式為password時，已下方法為認證流程中的一步。(認證通過才會返回Token)
1 public override Task GrantResourceOwnerCredentials( context)
2 {
3 var username= context.UserName;
4 var password=context.Password;
5 if(用戶名與密碼不合法)
6 {
7 context.setError(「用戶名或密碼錯誤！」);//認證不通過
8 }
9 else
10 {
11 var oAuthIdentity = new ClaimsIdentity(context.Options.AuthenticationType);
12 oAuthIdentity.AddClaim(new Claim(ClaimTypes.Name, context.UserName));
13 //可以加入用戶信息及其他必要信息到Token中，以便在api服務中使用(使用中HttpContext.Current.User.Identity即為oAuthIdentity對象，WebApi的Controller中可直接使用User.Identity)。
14 oAuthIdentity.AddClaim(new Claim("UserID", user.UserID.ToString()));
15 var ticket = new AuthenticationTicket(oAuthIdentity, new AuthenticationProperties());
16 context.Validated(ticket);//認證通過
17 }
18 return base.GrantResourceOwnerCredentials(context);
19 }
認證代碼
3、 已經獲取了Token，如何使用？
網上的大部分示例都是使用HttpClient調用的方式，而前後端的完全分離作為一種發展趨勢，我們需要Jquery的調用方式。
1 $.ajax({
2 type: 「method」,//get,post,put,delete
3 url:api_address + 「api/Test」,//如果調用webapi中的TestController
4 data: {data},
5 dataType: "json",
6 headers: {
7 "Authorization": "Bearer " + 「token」 //把登錄獲取的Token加入到http請求頭中
8 },
9 success: function (result) {
10 callback(result);
11 },
12 error: function (XMLHttpRequest, textStatus, errorThrown) {
13 //。。。。。。
14 }
15 });
調用Api
4、Api的訪問許可權該如何做？
認證中我們把用戶登錄成功作為認證通過的標志，但不同角色的用戶具有不同的訪問許可權（個人認為認證中應使用最小許可權驗證，如示例中的登錄成功），如何控制有些Controller不能被低許可權用戶訪問。
1 [Authorize]
2 public class TestController: ApiController
3 {
4 // GET api/<controller>
5 public HttpResponseMessage Get(int appid)
6 {
7 return null;
8 }
9 }
一個典型的ApiController
[Authorize]表示訪問該Controller的請求必須經過認證（請求頭中具有Token信息），這里我們可以自定義一個特性去驗證用戶許可權，並替換特性AuthorizeAttribute。（這里僅提供思路，具體做法請自己摸索，不保證以下代碼的正確性）
1 public class CustomeAuthorizeAttribute:System.Web.Http.AuthorizeAttribute
2 {
3 protected override bool IsAuthorized(System.Web.Http.Controllers.HttpActionContext actionContext)
4 {
5 if(base.IsAuthorized(actionContext))
6 {
7 //這里對用戶的許可權進行驗證，actionContext可以獲得請求的是哪一個Controller
8 var user = HttpContext.Current.User.Identity;//Token中帶有的用戶信息
9 if (可以訪問)
10 {
11 return true;
12 }
13 return false;
14 }
15 return false;
16 }
17 }
18
『叄』 java web前後端分離安全性
批量注冊的賬號是屬於你的系統，對於他們有用嗎？如果對他們毫無用處，他們為什麼要用你的介面批量注冊呢
『肆』 Web 前後端為什麼需要分離
我理解的前端就是負責所有和用戶交互有關的模塊都可以視為前端，他就像餐館裡面的前台服務生直接和客戶打交道的人。
後端就是負責處理用戶的請求，進行數據的處理，用戶幾乎所有操作都可以抽象為對數據的增刪改查，就像餐館裡面的廚師接收服務生告訴他要炒哪些菜，廚師把菜處理好再給服務生（後端處理數據返回給前端表現層）服務生最後輸出給客戶。
但是目前由於很多情況下業務比較簡單，比如說一個內容發布系統 CMS ，用戶交互，請求查看文章和管理員新增文章都是很簡單的業務邏輯，所以前後端都用 php 這門主要用於表現層的語言來實現，而本身在用 MVC 模式把用戶交互部分（ V 和 C ）以及數據處理（主要是 M ），否則的話就得用 java 等非腳本語言來實現保證效率，甚至高並發環境下還要用到消息隊列，緩存等等。
『伍』 web開發為什麼要前後端分離
在學習前端開發的時候，會發現前端開發的知識非常瑣碎，前端往往是靠拼湊來完成頁面效果，開發過程沒有java後端開發有邏輯，代碼也很難管理。後端開發有各種各樣的工具類、jar包、maven依賴、spring框架等，具有工程化模塊化思維，可以滿足後期的優化。vue.js和react.js等這些前端框架的出現，它們從本質上打破了以前前端開發的規則，這就是前端開發組件化框架。這些框架出現後，前端開發也開始像後端一樣，遵循一套體系來進行約束性的開發，越來越工程化、組件化、迭代化，變得有章可循。前後端分離核心思想是前端HTML頁面通過AJAX調用後端的RESTFUL API介面並使用JSON數據進行交互。
『陸』 Web前後端分離的意義大嗎
沒必要分太細。我們需要 specialist，但是 senior 的人都應該了解整個 E2E (end-to-end) 過程的。在Facebook 我們不分前端和後端，只分 proct 和 infrastructure。做 proct 的通常都是 full stack，不需要對特定的技術非常精通，但要求學習能力和靈活性足夠好，不能只做自己 comfort zone 以內的事情，do whateverit takes to get your proct shipped。通常聰明的應屆生都會先進入 proct，因為他們學什麼都很快，也不會說浪費了在某個領域的積累。infrastructure 擁有更多各個領域的 specialist，前端只是其中之一。infrastructure 的客戶就是 proct，要做的事情就是讓 proct 開發實際產品時覺得爽，就這么簡單。至於真正 senior 的人，必須了解整個 E2E 過程。這有點像那個「在瀏覽器地址欄按下回車後都發生了什麼」的答案，也就是掌握大局同時了解細節。因為具體的問題可疑扔給 junior 的人去解決，所以 senior 的存在價值就是在眾多問題當中尋找值得解決的問題。學過計算機體系結構的人都應該知道，性能優化只應該在瓶頸上做，因為做在非瓶頸上就是浪費資源。同理技術或產品的優化都應該是做在瓶頸上的，所以 senior 的人應該熟悉整套系統並且能夠有效找到當前的瓶頸。這時候就不存在前端或者後端的概念了，因為specialist 在特定領域再精通，不了解整個 E2E 的過程就沒辦法再往上提升。提到「聯調」，我想說我很久沒聽說過這個詞了，因為這個詞沒有對應的英語版本，美國公司的產品開發過程通常不包括聯調。proct 要做什麼，就自己學習對應的技術，學習公司內部的 infrastructure，然後調用公司內部的 API 就可以了。一個產品的邏輯，要分前端和後端兩個團隊的人實現，然後還要協調實現的結果，這我只在中國公司見過。當然這不僅僅要求公司 infrastructure 好，還要求有開放的文化。
『柒』 web編程里的前後端分離缺點是什麼
簡單來說，前後端分離的缺點是會讓開發復雜化。對於大項目，這種方式是沒有問題的。而對於小項目，這種其實是不合適的。
因為小項目可能一共就1-2個人開發維護，還要分前後端，這就增大了工作量。
『捌』 Web項目開發為何要走前後端分離模式
如果是問「什麼是正確的前後端分離」，我還真不敢回答，生怕自己的理解有什麼偏差；但是問怎麼「理解前後端分離」，那我可以結合自身的工作，談談我對前後端分離的理解，也歡迎大家提出不同的理解。
不過到了此階段，在企業級項目的開發過程中，Java程序員依然要兼顧前後端的開發，所以前端頁面的樣子嘛，達不到美觀的程度，也就是能用。
前後端分離有很多的好處：前端開發和後端開發可以各司其職，約定好介面之後就可以並行開發；後端介面可以復用，如果項目同時有電腦網頁端、移動網頁端、APP端等多個入口的時候，後端可以只有一個；
帶來好處的同時，也會有一些缺點，例如：增加了架構的復雜性，如果技術能力不足的團隊，可以考慮半分離（例如我們部門都是企業級應用，都沒有前端開發人員）；如果是面向互聯網的應用，需要搜索引擎抓取，就需要伺服器端渲染；另外前後端交互的介面，也需要花時間和精力設計。