Jesse James Garrett 2005 年明确提出了 Ajax 的概念，无疑对 web 客户端的展现效果产生了巨大的革新，对 Template 整页刷新技术形成了巨大的挑战，也为客户端展现逻辑和服务端逻辑分离开启了曙光。REST 的风格则为服务端程序的利用 URL 的天然特性进行了分布服务化，并将之前的事务型 Controller（一个 action 对应一个操作）的服务端逻辑模型拆散成资源性逻辑。这两个技术概念则为客户端展现逻辑和服务端逻辑的彻底分离奠定了基础。
在没有 Ajax 之前，客户端与服务端交互技术普遍采用的是 Template 整页刷新技术。客户端每次提交数据到服务端，服务端进行事务处理之后，都会进行 Template 整页刷新。之前客户操作引起的界面展现模型状态是需要传递到后台，否则就无法给用户界面操作以连贯性的支持。如果页面的展现状态不是很繁复多变的情况下，Template 整页刷新交互方式问题不大。但在如今这个特别强调">人机交互的时代里，这种方法在设计上来说是会造成界面展现逻辑和应用逻辑层层次不清，在工作量上来说也增加了不少传递界面展现模型的重复逻辑。Ajax 交互则不然，它可以在维持当前界面状态的同时，往服务端提交数据，服务端应用逻辑处理完之后，将处理结果返回，客户端按照处理结果，进行客户端的界面的改变。明显的，维持界面状态连贯性的工作就被省却了，服务端代码可以只需关注商业逻辑即可，层次也变得清晰起来。
按照这种思路 ，客户端逻辑维持展现，服务端只提供对 model 的操作，等于之前的服务端展现逻辑被移植到客户端去，这涉及到展现逻辑的语言使用 Java 语言变成了 JavaScript 语言。这种变化对于提出概念的人说，可能也只是一种语言的转换，可从实际的编程角度来说，从有着丰富 lib 支持的静态语言 Java 到 JavaScript 这缺乏完整函数库支持的动态语言，是一个巨大的鸿沟。JavaScript 以前只被作为一种简单的界面表现以及验错的语言（部分得导致其内涵完全被低估）一下子无法承受起支撑整个展现逻辑的重任。更为重要的是，培养一个 JavaScript 程序员的成本非常高。也许 AJAX+REST 这种设计对代码是整体最优的，但从项目管理开发人员资源分配来说，成本更为低廉 (JavaScript 开发人员少，而要其懂业务逻辑成本就更大了 )。
但事物正在慢慢地变化，JS 的框架层出不穷的涌现，prototype、Dojo、Ext JS、jQuery 等让代码大为简化 , 这个因素开始慢慢弱化。现在应用 REST+Ajax 架构的技术难度也越来越小了。
还有一个产业发展的因素，现在不再只是浏览器才能访问 web 网站了，还有许多如移动设备 app 根本就不需要 HTML 的展现形式，一个是费流量，另一个是展现是客户端控件完成，不需要 HTML 给其以做渲染指导。
在外部和内部共同作用下，这种架构的发展结果导致未来有这种可能性：所谓的 web 服务端程序就是一堆 Web service, 然后客户端就第一次下载一堆基本的网页结构到本地，然后每次在本地网页上去运行 JS 去组织调用 Web service 得到数据进行用户输入处理和返回数据的页面渲染。由于网页在本地运行，其安全级别较高，可以访问很多本地资源，功能会很强大（如 chrome 的 extension）。
但仍然有此 Ajax( 交互方式）+REST 模型解决不了的问题：
从应用场景来说，当需要从一个应用场景跳转到另一个完全不同的应用场景，界面状态的保留就不是必要的；而且在跳转后往往需要渲染大量的展现数据和相应控件的结构代码（HTML），这时 Template 整页刷新的优势就体现出来，劣势也得到了避免。
从性能上考虑，一个复杂的事务型逻辑操作从逻辑上来说可以拆散成多个资源性操作，但这必然导致交互的增加和性能下降。
从架构风格的适用性考虑，REST 是以资源 +CRUD 的方式看待世界，那的确在信息化系统中大多数场景都是围绕这个主题，但也有部分逻辑确实是事务性很强（相当于 job），比如以 excel 形式导入大量的数据到数据库，涉及许多对象的创建，包含删除（覆盖导入），修改等，那此时使用 REST 就未必适宜。
所以综合考虑是将 Ajax+REST 和 Template 整页刷新综合 应用于各业务场景，从各业务场景的不同来应用。