目前来说在网站架构方面采用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，分清楚层次，就明朗了。