#22 Fetch API

2022-08-02

在很长一段时间里,浏览器发送 Ajax 请求主要依赖 XMLHttpRequest,也就是大家熟悉的 XHR。
但随着 JavaScript 生态的发展,XHR 的一些问题越来越明显:

  • 代码太啰嗦
  • 回调层级复杂
  • 错误处理麻烦
  • 可读性较差

于是浏览器推出了更现代、更简洁的网络请求方案 Fetch API。

XMLHttpRequest 的问题

先看一个传统 Ajax 请求:

var xhr = new XMLHttpRequest();
xhr.open("GET", "/api/user", true);
xhr.onreadystatechange = function () {
  if (xhr.readyState == 4) {
    if (xhr.status == 200) {
      console.log(xhr.responseText);
    }
  }
};
xhr.send();

虽然功能没问题,但存在几个明显缺点:

  1. 状态判断复杂:必须反复判断 readyState 和 status,初学者经常搞混。
  2. 回调代码较多:所有逻辑都写在 onreadystatechange 里面,代码一多就会非常乱。
  3. 服务器返回 JSON 时需要手动转换。
    JSON.parse(xhr.responseText)
    

Fetch 的基本写法

主要是基于 Promise 实现,可以链式调用,不用一层又一层地回调,更符合现代 JavaScript 风格。
注意:这是较新的语法,在某些老版本浏览器上可能支持程度不好,如果需要兼容,可以使用 XHR 或者 Axios、jQuery Ajax 等库。

fetch("/api/user")
  .then(function (response) { // Response 对象
    return response.json();
  })
  .then(function (data) {
    console.log(data);
  })
  .catch(function (error) { // 异常处理
    console.log(error);
  });

相比 XMLHttpRequest:

  • 代码明显更短
  • 结构更清晰
  • 更容易阅读

Fetch 也支持提交数据:

fetch("/api/user", {
  method: "POST",
  headers: {
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    name: "Tom",
    age: 18
  })

})
.then(function (response) {
  return response.json();
})
.then(function (data) {
  console.log(data);
});

参考资料与拓展阅读

#20 公共库 CDN

2022-02-19

公共库 CDN,也叫静态资源库。

我想了一下,国内公共库 CDN 全面挂了可能是由于监管压力。
在国内,如果 CDN 提供的静态资源被一些恶意网站引用,会被问责。如果要全面审核使用 CDN 的网站,肯定是会增加太多的管理成本。
感觉这真是太不合理了!

如果是线上项目,不要用公共库 CDN。
小项目自己管理静态资源,大项目可以用付费的 CDN 服务。

BootCDN

https://bootcdn.cn

我之前用的最多的 CDN,但是总是挂,心累。现在开始用字节跳动 CDN 了。

字节跳动 CDN

http://cdn.bytedance.com/

CloudFlare CDN

https://cdnjs.com/

JsDelivr

https://www.jsdelivr.com/

不可用清单

百度 [不可用]

http://cdn.code.baidu.com

已经挂了。

腾讯 [不可用]

https://libs.qq.com/

打不开。

新浪 [不可用]

http://lib.sinaapp.com/

只有很少的资源。

360 [不可用]

http://libs.useso.com/

又拍云 [不可用]

http://jscdn.upai.com/

只有很少的资源。

七牛云 [不可用]

http://www.staticfile.org/

感觉很久没有维护了。一些常用库都非常老了。

参考资料与拓展阅读

#19 DNS_PROBE_FINISHED_NXDOMAIN

2021-12-14
  1. 浏览器突然打不开 zhihu.com, 报 DNS_PROBE_FINISHED_NXDOMAIN。
  2. Windows 网络诊断之后说是 DNS 不可用。
  3. 经过检查,使用 DHCP 获取到的 DNS 172.16.0.1。
  4. 改成 AliDNS: 223.5.5.5, 223.6.6.6 之后就好了。
  5. 然后再改回默认的 DNS 发现也能正常访问了。

我应该在出现问题的时候先尝试 nslookup 一下,看看 DNS 解析出来的到底是个什么结果。
下次遇到再继续更新。

C:\Users\Administrator>ipconfig /all | findstr DNS
   主 DNS 后缀 . . . . . . . . . . . :
   连接特定的 DNS 后缀 . . . . . . . :
   DNS 服务器  . . . . . . . . . . . : 172.16.0.1
   连接特定的 DNS 后缀 . . . . . . . :
   DNS 服务器  . . . . . . . . . . . : fec0:0:0:ffff::1%1
   连接特定的 DNS 后缀 . . . . . . . :
   连接特定的 DNS 后缀 . . . . . . . :
   连接特定的 DNS 后缀 . . . . . . . :
   连接特定的 DNS 后缀 . . . . . . . :

C:\Users\Administrator>nslookup zhihu.com
服务器:  UnKnown
Address:  172.16.0.1

非权威应答:
名称:    zhihu.com
Address:  103.41.167.234

#16 Nginx location 指令

2019-05-22
Syntax : location [ = | ~ | ~* | ^~ ] uri { ... }
location @name { ... }
Default: —
Context: server, location
  1. 执行顺序是:完整匹配(= uri) > 前缀匹配(^~ uri/uri) > 正则匹配(~/~*)。
  2. 优先级是:完整匹配 > 正则匹配 > 前缀匹配(越长优先级越高)。
  3. 完整匹配、正则匹配匹配上之后直接返回,前缀匹配则不是。

#15 记一次 XSS 漏洞发现过程

2019-04-09

某用户委托安全公司对本司(SendCloud)短信发送业务做安全检测,发现咱们的上游通道某一环节的安全漏洞。
跟踪这个过程,真的十分有趣。
这是 XSS 第一次发生在我身边,怎么也不会想到有人会犯这么弱智的错误。最基本的页面输出转义都没做。
页面内容输出转义、SQL 防注入、表单的 CSRF token 校验,应该算是 Web 站点搭建的基础工作吧!

#13 常见 Web 缓存服务

2019-01-06

Apache,Nginx 都有缓存功能,再加上 Redis 做动态数据的缓存,再加上 CDN,所以我还没有用过专门的缓存服务。
但是这些服务真是大名鼎鼎,即便不用,我也可以先列出来做个简单的了解。