打字机 输入，输出 （规则26个字母）
计算机 输入，输出（规则01）
软件 输入，输出（软件的业务规则）
web系统软件 （web化的业务规则-细粒度受控）
数据库系统软件（SQL化的业务规则-粗粒度受控）
web系统 前端UI和逻辑+后端逻辑和数据
数据系统 前端SQL语句编辑器+后端逻辑和数据
前后端的区别
分工不同
前端，独立实现部分 业务规则（非安全，如，一次只能看10条数据），配合后端实现部分（安全，如，只可看指定数据）
后端，安全的实现业务规则的部分，其他部分不影响业务核心逻辑的，可不由其实现
关注的粒度不同
数据 从始化 前端输入 后端存储 后端查询 前端展现 ，数据在 前后端 的形态 可能不同，或即使形态相同，但被前后端，关注提取使用的字段也不同
对于2个业务不同的web系统
传统做法
Web1系统 定制的UI+ 定制的后端（抽象为受控的业务实体）+定制设计的数据库
Web2系统 定制的UI+定制的后端（抽象为受控的业务实体）+定制设计的数据库
新的做法
web1系统 定制的UI+统一的后端（抽象为受控的资源实体）+定制设计的数据库
web2系统 定制的UI+统一的后端（抽象为受控的资源实体）+定制设计的数据库
具体实现
以restful 规范 前端，后端的调用
前端要承担restful概念之外的 动作型 业务操作的 分解，把 具体的业务操作 转为 一个或多个rest Api调用
后端 只以 受控 资源模型，来抽象，包括 oathAPI+restful API
带来的好处
统一的后端 可以统一 一次实现，持续优化，架构上各系统的 后端 理论上 互相没有关系的，微服务
带来的坏处
架构上 各 当系统的业务有关联时，前端 要 调取 多个后端的API，加上 时间顺序，数据依赖，数据聚合显示 等因素，会 导致前端 无法实现，会 实现代价太大，或 有性能问题。
改进的可能
架构上带来的前端复杂问题，可以 通过 在后端增加 API网关（统一通用型，或定制型）
是否问题归零，回到原点
以上问题都是 以 SQL数据库做前提的后台，因为它 没有提供 http 化的查询接口，和 角色权限 管理
但如果一个 noSQL 数据库，提供了这样的 功能，架构上 演进到 定制型Apl网关，是不是 就和现在的做法相同，问题是否回到原点。
问题根源
桌面型 软件C/S软件 本身 就可以没有后端，也可以 带后端；但web型B/S系统，受浏览器 和 http 无状态的限制，只能采用前端+后端模式。
回答前一个问题，如果假设的 noSQL 数据存在，则形态或架构上问题归零，但使用开发的方便性，友好性，抽象层次不一致，
首先 该no-SQL 数据库 对外提供的API接口，是否基于restful的资源操作模型，还是基于 数据存储的模型，其次 其 权限和 角色模型 是否 能结合 oauth，还是 基于传统数据存储安全的模型，如果答案都是 是，二者确实无本质区别，否则 抽象层次来说 偏向前端可直接使用的restful 资源操纵模型 更高，受安全控来说，oauth更容易使用。
定性总结
可以说，是一次，基于某一层次抽象和封装，简化BS开发工作量和开发流程的尝试
形态可以是 通用的受控资源读写后端 （PC上的B/S模式） 或 代码级别的工具组件（Android上的B/S模式）
