Tìm nạp API so với XMLHttpRequest


163

Tôi biết rằng Fetch API sử dụng Promises và cả hai đều cho phép bạn thực hiện các yêu cầu AJAX đến máy chủ.

Tôi đã đọc rằng Fetch API có một số tính năng bổ sung, không có trong XMLHttpRequest(và trong polyfill API Fetch, vì nó dựa trên XHR).

API Fetch có những khả năng bổ sung nào?


2
Mặc dù tôi không thể nhớ lại tại chỗ, có một hoặc hai điều bạn có thể làm với XHR mà bạn không thể tìm nạp. Bạn nói rằng bạn đã đọc rằng tìm nạp có nhiều khả năng bổ sung, những bài viết đó sẽ không tốt nếu họ không nói chúng là gì
Jaromanda X

2
đã tìm thấy hai điều bạn không thể làm với tìm nạp mà bạn có thể làm với XHR ... bạn không thể đặt giá trị của riêng mình cho thời gian chờ yêu cầu trong quá trình tìm nạp, bạn cũng không thể nhận các sự kiện tiến trình
Jaromanda X

3
Tìm nạp chỉ là một cách đơn giản để thực hiện mọi thứ đối với hầu hết các loại XMLHttpRequests. Nếu trường hợp sử dụng của bạn phù hợp với những gì Fetch làm, thì hãy sử dụng nó. Khi bạn hiểu đúng về nó, API XMLHttpRequest thật xấu cho hầu hết mọi người sử dụng nó cho. Fetch là một nỗ lực để cung cấp một cách sạch hơn để làm những việc không cần thư viện bao quanh XMLHttpRequest để làm cho nó trở nên ngon miệng.
jfriend00

1
Nó có hỗ trợ thuần túy trong các trình duyệt ( caniuse.com/#search=fetch ), do đó, có một sự đa dạng cho nó github.com/github/fetch , wich đang làm việc trên xhr
ilyabasiuk 22/2/2016

4
@Marco - Làm thế nào bạn có thể không nói rằng điều đó fetch(url).then(function(data) (...));không đơn giản hơn việc sử dụng XMLHttpRequestđể làm điều tương tự? Nó có thể có nhiều tính năng khác, nhưng geez, nó chắc chắn sẽ đơn giản hơn để sử dụng cho những thứ thông thường. Đây là một API đã được dọn sạch.
jfriend00

Câu trả lời:


120

Có một vài điều bạn có thể làm với tìm nạp chứ không phải với XHR:

  • Bạn có thể sử dụng API Cache với các đối tượng yêu cầu và phản hồi;
  • Bạn có thể thực hiện no-corscác yêu cầu, nhận phản hồi từ máy chủ không triển khai CORS. Bạn không thể truy cập cơ quan phản hồi trực tiếp từ JavaScript, nhưng bạn có thể sử dụng nó với các API khác (ví dụ: API Cache);
  • Truyền phản hồi (với XHR, toàn bộ phản hồi được đệm trong bộ nhớ, với quá trình tìm nạp, bạn sẽ có thể truy cập luồng cấp thấp). Điều này chưa có sẵn trong tất cả các trình duyệt, nhưng sẽ sớm thôi.

Có một vài điều bạn có thể làm với XHR mà bạn chưa thể thực hiện với tìm nạp, nhưng chúng sẽ sớm được cung cấp (đọc đoạn "Cải tiến trong tương lai" tại đây: https: //hacks.mozilla .org / 2015/03 / this-api-is-so-fetching / ):

  • Hủy bỏ một yêu cầu (điều này hiện đang hoạt động trong Firefox và Edge, như @sIDIAbarker giải thích trong bình luận của anh ấy);
  • Báo cáo tiến độ.

Bài viết này https://jakearchibald.com/2015/thats-so-fetch/ chứa một mô tả chi tiết hơn.


1
Thông số kỹ thuật cho API Fetch hiện cung cấp cho việc hủy bỏ. Hỗ trợ đã được chuyển đến trong Firefox 57 và Edge 16. Trình diễn: fetch-abort-demo-edge.glitch.me , mdn.github.io/dom-examples/abort-api . Và có Chrome & Webkit mở tính năng lỗi bug.chromium.org/p/chromium/issues/detail?id=750599 , bug.webkit.org/show_orms.cgi?id=174980 . Cách thực hiện: developers.google.com/web/updates/2017/09/abortable-fetch , developer.mozilla.org/en-US/docs/Web/API/AbortSignal#Examples . Và ví dụ trong câu trả lời Stack Overflow tại stackoverflow.com/a/47250621/441757
sIDIAbarker

1
Một điểm khác biệt nữa là fetchcác yêu cầu không thể được phát lại trên Công cụ dành cho nhà phát triển.
Parziphal

Và, từ kinh nghiệm của tôi, fetchcó thể yêu cầu các tệp, nhưng XHR không thể.
D. Pardal

64

lấy

  • thiếu một phương thức dựng sẵn để tiêu thụ tài liệu
  • có cách nào để thiết lập một thời gian chờ chưa
  • không thể ghi đè tiêu đề phản hồi kiểu nội dung
  • nếu tiêu đề phản hồi độ dài nội dung có mặt nhưng không được hiển thị , tổng chiều dài của cơ thể sẽ không xác định trong khi truyền phát
  • sẽ gọi trình xử lý hủy bỏ tín hiệu ngay cả khi yêu cầu đã được hoàn thành
  • không có tiến trình tải lên (hỗ trợ cho các ReadableStreamtrường hợp như các cơ quan yêu cầu vẫn chưa đến )

XHR

  • không có cách nào để không gửi cookie (ngoài việc sử dụng cờ không chuẩnmozAnon hoặc hàm AnonXMLHttpRequesttạo)
  • không thể trở về FormDatatrường
  • không có tương đương với fetchcủa no-corschế độ
  • luôn theo dõi chuyển hướng

13
fetchcũng đang thiếu tiến độ. với XHR, bạn có thể theo dõi tiến trình với progresssự kiện
rzr

1
"Không thể ghi đè tiêu đề loại nội dung của phản hồi" ... đây chỉ là một ý tưởng tồi để bắt đầu. kiểu 'nội dung chỉ ra những gì sẽ được trả lại và BACKEND NÊN đưa ra điều đó cho frontend. THỰC SỰ, loại nội dung phải là 'ĐẦU TIÊN' cho loại vì những gì được yêu cầu, là những gì nên được trả lại. Nếu bạn muốn một cái gì đó khác nhau phục vụ từ một tên miền phụ đặc biệt hoặc một cái gì đó để bạn có thể xử lý các chức năng cụ thể riêng biệt. Bạn đang cố gắng buộc một quy tắc 1% xuống 99% cổ họng của mọi người.
Orubel

@Knu yep và bây giờ chúng tôi đã tiến bộ hơn và chúng tôi có thể dễ dàng tự động hóa một giải pháp 90% và để các trường hợp kỳ dị chuyển đến các chức năng khác nhau.
Orubel

1
@rzr không chính xác, bạn có Response#body.
Knu

9

Các câu trả lời ở trên là tốt và cung cấp thông tin chi tiết tốt, nhưng tôi chia sẻ ý kiến ​​tương tự như được chia sẻ trong mục blog của nhà phát triển google này vì sự khác biệt chính (từ góc độ thực tế) là sự tiện lợi của lời hứa tích hợp được trả về từfetch

Thay vì phải viết mã như thế này

function reqListener() {
    var data = JSON.parse(this.responseText);
}

function reqError(err) { ... }

var oReq = new XMLHttpRequest();
oReq.onload = reqListener;
oReq.onerror = reqError;
oReq.open('get', './api/some.json', true);
oReq.send();

chúng ta có thể dọn dẹp mọi thứ và viết một cái gì đó ngắn gọn và dễ đọc hơn với những lời hứa và cú pháp hiện đại

fetch('./api/some.json')
    .then((response) => {
        response.json().then((data) => { 
            ... 
        });
    })
    .catch((err) => { ... });

8
@TheOpti Bạn có thể polyfill hỗ trợ tìm nạp cơ bản vào IE 11. Bạn cũng có thể bỏ IE11 làm trình duyệt được hỗ trợ trong nhiều dự án vì trong nhiều cơ sở người dùng, mức sử dụng IE 11 hiện dưới 1%.
Devon Holcombe
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.