如何理解Fetch Api

摘要： 關於 Fetch Api，接受度越來越高了。網上很多文章在介紹 Fetch 的用法，在鼓吹 Fetch 的優勢，也有人在撰文批評 Fetch 的難以使用。 但是，當我們在討論 Fetch Api 的優點和缺點的時候，我們在討論什麼？如果不清楚一個介面的設計目的，有如何去評判這個設計？ 從我...

關於 Fetch Api，接受度越來越高了。網上很多文章在介紹 Fetch 的用法，在鼓吹 Fetch 的優勢，也有人在撰文批評 Fetch 的難以使用。 但是，當我們在討論 Fetch Api 的優點和缺點的時候，我們在討論什麼？如果不清楚一個介面的設計目的，有如何去評判這個設計？

從我個人看來，我們覺得我們需要明確以下兩點：

第一、Fetch Api 是一個“底層”介面

這個“底層”的意思並不是說這個 api 有操縱 OS 或者瀏覽器原生特性的能力，而是說這個介面是 Web 的底層。 Fetch Api 屬於 WEB API，不是一個高度封裝介面。競爭對手不是jquery，不是axios，也不是其他的 HTTP 庫。

所以，fetch api 本身就不是給普通開發者用的，而是給庫開發者用的。就像在 java 裡面，你通常不會直接通過 socket 去執行 http 請求一樣。所以，不要站在普通開發者的視角來看這些問題，如果你想像用 axios 一樣來使用 fetch，你就掉坑裡了。

第二、Fetch Api 是由 whatag （對比一下 W3C） 制定的。

隨著 web 和 js 的領域擴張，如果 Web 想成為一個通用平臺，如果 js 想成為一個成熟的平臺語言，那麼 API 的底層化和精準化是不可避免的，不跳出瀏覽器這個束縛，是達不到目的的。

1. 站在語言的角度，js 競爭的是 java，是 python，是其他的通用平臺語言。

2. 站在平臺的角度，Web 競爭的是其他平臺，是 windows，是android，是ios。

3. 站在標準的角度，規範要統一的是瀏覽器，是Node，也是其他的 Web 執行宿主。

當前 XMLHttpRequest 面臨的困境是，XMLHttpRequest 滿足不了 web 的擴充套件（不論是橫向擴充套件還是縱向擴充套件）。而不是因為 XMLHttpRequest 有什麼內在缺陷。所以 Fetch 重新模組化了各個部分，

Request
Response

Header
Body

顯然，這種架構根本就是對 Http 協議的復刻，因為 Http 才是 Web 的底層協議。

如果我們能記住以上兩點，我們就能理解那些槽點：

1. fetch api 備受苛責點的“錯誤處理”。404、502之類的狀態碼被認為是 “resolved” 不是一目瞭然嗎？因為對於一個底層介面來說，網路是正常的，只是你的服務不正常。
2. Request 預設是不帶 cookie。這個在我看來是改進，而不是槽點，“如無必要,勿增實體”。
3. 不支援取消請求。說實話，這才真的是一個槽點。不過這只是一個暫時缺失的點，而不是介面設計如此。 AbortController 已經在實現中了，而且最新的瀏覽器已經實現了。不過，最後使用當然不會像 XMLHttpRequest 直接呼叫 abort() 這麼簡單。
4. 如果還有其他問題，請參照對比 Fetch 與 Socket。

有問題請聯絡 QQ 群：315658668