目前來說在網站架構方面採用nobackend這種方案構建是否真的可行？

就是說 web,ios,android只是個展示層，持久化操作統一丟給api。
先不考慮 模板渲染這一塊，我們可能會把這塊放到前端。
目前糾結就是 web的session 和 app的token 問題。
這套api不單單通過token來校正，而是當web請求是他是會有使用者session的。
當含有使用者session的時候就不用校正token。
這種做法有什麼局限性或者缺點嗎？
歡迎指正拍磚！
後端php..

回複內容：

當然可行，而且我還有很多成功案例，業內的案例應該也不少，儘管有些是忽悠人的，有些只是看起來是那麼回事兒，實際卻不是。

但是話說回來，這事兒還是看你們有沒有資深架構師，要真的有很多錢的話，我不介意 用.NET給你們證明這個架構的可行性的。（PHP無愛抱歉）


如果你真的糾結token和session這種問題，要麼是因為你們沒有能力搞定這個架構，要麼是你沒玩過心裡沒底，我不太知道是哪一種，總之是否可行的答案是肯定的。我理解你說的nobackend是指不想採取PHP、JSP之類技術的傳統架構，那類架構在session裡會放一堆使用者業務的狀態，並在伺服器端寫邏輯來更新頁面或者操作後端服務（如，更新資料庫）。

就我個人經驗而言，你完全可以把頁面更新和使用者目前狀態放在前端，後端API是一組無狀態的服務，這其實是很常見的架構了。

比較麻煩的（從你的問題描述裡也可以看出）是安全那塊。

native的client，你可以考慮oauth implicit grant type那種，即token直接放用戶端，因為native APP被認為比較安全。

web的話，token直接放用戶端比較危險，但傳統方法（包括oauth authorization code grant type）是要在session裡放token的。

這個問題，其實也有辦法解決。但你最好先問一下自己，真的要無session化嗎？其實session一般而言是很難完全去掉的，就整個系統架構而言，你只不過是在你的編程視野內不用它而已。合理的使用，並無不可，不要搞原教旨主義。如果只有token放session裡面，萬一伺服器崩潰，假設你應用處理得好，前端業務狀態態能被持久化，那無非就是讓使用者重新登入然後回到剛才頁面繼續。比如，線上商城，使用者只要把東西放購物車裡，後台崩掉，也無非就是重登入，你的購物記錄還在，可以繼續操作。這隻是粗略描述，具體細節要根據業務需求來定，但我的意思你應該能明白了吧。你可以讀讀這個Post: Lift, State, and Scaling ， 無關語言。可以想到的是，你們可能需要自己造很多輪子，因為很多事務在前端做的話沒有成熟的工具，最後反倒拖慢了你們的創業。簡單來說，
1. 後端提供rest api，提供一個/verify供登入驗證，然後後續操作都需要附帶驗證資訊
2. 前端通過ember/angular做成webapp，使用ajax消費rest api，我在實際中就不用cookie，每次登入就是了，因為你已經是webapp了
3. 如果需要安全就上https，cookie這玩意我個人覺得能免則免直接使用js api，授權問題很難解決，secret不能下載到瀏覽器，只能使用隱式授權，但大多數服務都不支援。。。無後端方案？這個有過。記憶中有挺多的案例的。

無後端不是真的沒有後端，API實現不也是後端之類的技術嘛。發展到現在應該已經基本沒痛點了。題主的問題，可能是沒有認識到服務端token和web session的區別。其實還好，和介面伺服器通訊肯定是token，web端的session肯定是先驗證了服務端存取權限由web端產生的。
我們來過一下流程，
使用者登入狀態例，
1. 使用者登入，向api伺服器發送驗證資訊
2. 伺服器驗證OK，返回一個token表示驗證通過
3. web端建立一個登入session記錄下當前登入態擷取的token
4. 登入完成，跳轉到應用頁面
在上面之後，使用者要看看ta的優惠券資訊
1. 拿著登入時web端session裡儲存的token 和使用者名稱等資訊，調用優惠券介面
2. 返回優惠券資訊
伺服器在這個過程中做了2件事
1. 驗證token合法性（存在性，到期與否，來源等）
2. 合法，調用服務返回優惠券資訊，反之，報錯。
在這裡，你可以看到session是web端表現層用的，token是介面伺服器的session，分清楚層次，就明朗了。

