Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

合并请求的做法与坑

  有时候页面会有很多零碎的数据要显示,而这些数据却来自不同的接口,如果直接逐个调用势必会产生大量多余的请求。既然我们懂得将小而杂的图片用 CSS Sprite 方式加载,那这些零碎的接口为何不可呢?同样也可以搞出一个 Batch Reqeust 方案来嘛。
  应用级的 HTTP 封装应该是像 jQuery 的 $.ajax 或 Angular 的 $http 那样,将请求和响应视为无状态的对象来处理的。也许有人会觉得原生的 fetch API 这东西更标准?是的,它很标准,但很烂!我不认为它是个应用级的 API,只有将请求和响应作为无状态对象来处理才是最易用的。
  合并请求需要的是无状态的对象,虽然有状态的也能勉强操作,但是会变得非常复杂。我们现在只考虑无状态的情况,比如请求是一个这样的结构 var request={
  method:"GET",
  url:"/xxx",
  data:"a=1&b=2",
  headers:[
    {name:"Content-Type",value:"application/x-www-form-urlencoded"}
  ]
};
  响应是一个这样的结构 var response={
  status:"200",
  statusText:"OK",
  data:"{}",
  headers:[
    {name:"Content-type",value:"application/json"}
  ]
};
  那么有了这两个结构之后只需要服务器提供个接口,请求时把所有请求的结构放入一个数组中,响应时也响应一个响应的数组就可以实现合并请求了。
  这本来是个很简单的东西,但深入思考一下就会发现其实也有很多坑。由于客户端不处理 1xx 和 3xx 的状态码,合并接口时服务器遇到这些状态码应该先处理掉。还有一堆 headers 也不是客户端该处理的,比如 set-cookie。服务器端也得考虑将 set-cookie 给处理掉。
  以上两个最基本的坑要是填掉的话就能实现一个建议的合并请求了,但是实际上它的坑远不止这些。考虑 CORS 之类的问题会让人很奔溃,还有各种事务问题。其实我只需要一个能用的东西即可,更复杂的东西暂时就先不纠结了。
网名:
3.80.32.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^