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

01-28

就是說 web,ios,android只是個展示層，持久化操作統一丟給api。
先不考慮模板渲染這一塊，我們可能會把這塊放到前端。
目前糾結就是 web的session 和 app的token 問題。

這套api不單單通過token來校驗，而是當web請求是他是會有用戶session的。
當含有用戶session的時候就不用校驗token。
這種做法有什麼局限性或者缺點嗎？
歡迎指正拍磚！

後端php..

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

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

如果你真的糾結token和session這種問題，要麼是因為你們沒有能力搞定這個架構，要麼是你沒玩過心裡沒底，我不太知道是哪一種，總之是否可行的答案是肯定的。

無後端方案？這個有過。記憶中有挺多的案例的。

無後端不是真的沒有後端，API實現不也是後端之類的技術嘛。發展到現在應該已經基本沒難點了。

簡單來說，

1. 後端提供rest api，提供一個/verify供登錄驗證，然後後續操作都需要附帶驗證信息

2. 前端通過ember/angular做成webapp，使用ajax消費rest api，我在實際中就不用cookie，每次登錄就是了，因為你已經是webapp了

3. 如果需要安全就上https，cookie這玩意我個人覺得能免則免

我理解你說的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，無關語言。可以想到的是，你們可能需要自己造很多輪子，因為很多事務在前端做的話沒有成熟的工具，最後反倒拖慢了你們的創業。

直接使用js api，授權問題很難解決，secret不能下載到瀏覽器，只能使用隱式授權，但大多數服務都不支持。。。

題主的問題，可能是沒有認識到服務端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，分清楚層次，就明朗了。