对于一个浏览器的请求来说,从连接的角度来看,似乎是一个比较持续的过程,因为对于一个请求发送和接收来说,往往是类似这样的一个过程:
如上图所示,如:
请
求
发
出
→
等
待
服
务
器
响
应
→
服
务
器
处
理
→
最
终
发
送
响
应
的
报
文
\small请求发出\rightarrow等待服务器响应\rightarrow服务器处理\rightarrow最终发送响应的报文
请求发出→等待服务器响应→服务器处理→最终发送响应的报文
的这一整个过程来看,对于页面的使用者来说,他们通常只会是一个简单的动作:一次点击,或是一次页面的刷新,而这个请求的过程,其实只会在用户每次在前端触发某个事件的时候才会相应的产生的,每次的请求事实上都是若干个单独的请求连接,而不是在客户端这边始终会跟服务器这边保持联系,通过一个持续维持的通道随时准备发送客户端的请求。
因此,从这个角度来看,对于多个请求的过程来说,这些请求并不是一个持续的 HTTP 请求的过程,每次在服务器这边,都会创建一个新的进程来负责相应的请求内容处理:
而当 A j a x Ajax Ajax 出现之后,客户端例如在浏览器的页面请求上,有了更加灵活的加载形式。这个时候,客户端不再需要在每次发送一个请求的时候都需要刷新整个的页面,而只需要对页面所需要的部分信息进行更新。这样,从用户的使用角度来看,不必在每次点击一个搜索按钮,或者是一个获取页面部分内容展示的时候,都需要看到一个让人烦躁的页面刷新按钮,重新展示整个页面,而可能仅仅只是需要更新一个查询结果或者是换一个图标:
这样,对于整个浏览的过程来说,从用户的角度来看,减少了多余页面元素的刷新带来不胜友好的体验,另外,对于数据传输以及服务器处理来说,也无需再次响应一个完整的页面,而是仅仅需要传输部分相关的更新数据即可。
此时前端就只需要关注:当后端传递来什么样的数据,或者接收到什么形式的内容,页面的布局以及展示方式需要如何调整。
这样,响应式的前端页面布局就应运而生了,后端不再需要处理页面的展示逻辑,前端也无需关注需要展示什么数据,整个应用的在设计上,数据和展示逻辑更加的分离,更加明确,只需要确定好数据交互方式,前后端可以更专注于自己需要实现的内容。
当然,这种分离也不是完全绝对的,任何前后端的设计上更多的时候需要取决于具体的需求,以及具体的数据展示的需要,进行相应的处理,有时候,一些数据可能在前端上进行处理将会更加的方便,而有时候也可能需要依赖于后端来返回某些页面的展示。这样的完全独立是理想化的,但是不管怎样,在设计上尽可能的考虑类似这样相互独立,让每个部分的逻辑更加的分离,不仅可以让我们在页面设计上更加的清晰,也方便项目在后续进行迭代和更新时更具有扩展性。