Web 技术研究所

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

Fetch API 之 —— Request

  Request 对象其实就是把一个 HTTP 请求的所有参数都准备好。这个操作通常是一次解决的,不像传统的 XMLHttpRequest 一样要先创建对象然后才一个个设置属性那么繁琐。另外 Request 对象仅仅是准备而已,只有当调用 fetch 方法时才会发起请求。
  很多对 XMLHttpRequest 对象的封装都采用了一次性准备好所有参数的接口形式,比如 jQuery 的 $.ajax(options);   这里的 options 就是请求所需的参数,实际上其中就包含了和 Request 对象类似的概念。然而 Fetch API 的 Request 对象的设计就比较蛋疼,它的 url 参数必须和其他参数独立开来。我们先看 jQuery 的设计 // 这两种方式都是可用的
$.ajax("/",{method:"post"});
$.ajax({url:"/",method:"post"});
  而 Fetch API 的 Request 就只支持前一种 new Request("/",{method:"post"});   我不明白为什么 url 被特殊化了?也许 url 这个参数确实是用得最多的,但在逻辑上应该与其他参数同级才对。不过还好这对我而言并不是什么实在无法忍受的设定。
  另外 Fetch API 的 Request 实例还有个神奇的 clone 方法。虽然这个方法看名字就能知道是什么意思,但为何会有这么一个方法存在实在是难以想象。至少我从来没遇到过这种需要 clone 一个请求的需求。
  其实我之前以为这套 API 是无状态的,但实际上它还是有状态的。比如 Request 对象同 XMLHttpRequest 一样请求成功后就被设置了状态。所以一个 Request 对象如果被用于两次 fetch 就会抛出异常。

  这个设定让我对它的好感度直接减半!也许上面的 clone 方法就是用来解决这个问题的?反正我是暂时无法理解了。
网名:
3.84.186.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^