Als Frontend-fokussierter Typ, der von Zeit zu Zeit auch node.js macht, war Axios meine erste Wahl.
Einfache API von Facebook funktioniert auf Browsern und Knoten? Getan

Nach einer kürzlich geführten Diskussion mit @mikeal habe ich Bent ausprobiert. Als Node.js-Entwickler, der Request schon seit einiger Zeit verwendet, war gebogen definitiv ein einfacher Übergang - sehr zu empfehlen 💖

@reconbot Vielleicht möchten Sie got , needle und urllib hinzufügen .

Nun, es fühlt sich irgendwie falsch an, hier für meine eigene kleine Bibliothek zu werben, aber da dies das Ziel des Problems ist, hier ist es: request-compose ist ein funktionaler HTTP-Client mit 0 Deps mit Unterstützung für Promises, Streams und eine Menge von andere nützliche Optionen, von denen die meisten den angeforderten sehr ähnlich sind.

Ich habe auch einen Artikel darüber geschrieben. Die allgemeine Idee ist, dass jeder ermutigt wird, seine eigenen HTTP-Clients zusammenzustellen, die speziell auf seine eigenen Bedürfnisse zugeschnitten sind.

Was die Bundle-Größe betrifft, habe ich keine Ahnung, aber sie sollte ziemlich klein sein, obwohl dieser Client nie für die Verwendung im Browser entwickelt wurde.

Es könnte sinnvoll sein, der Tabelle die folgenden Spalten hinzuzufügen:

• Anzahl der Sterne in Github (ja, ich weiß bereits, dass dies nicht der einzige Faktor bei der Auswahl einer Bibliothek ist)
• Anzahl der npm-Downloads (vielleicht wöchentlich, gleiche Statistik wie die npm-Website, und ja, ich weiß bereits, dass dies nicht der einzige Faktor bei der Auswahl einer Bibliothek ist)

Wenn man diese Zahlen nebeneinander stellt, haben einige Bibliotheken Tausende von Sternen und Millionen von Downloads pro Woche, im Vergleich zu anderen in den Hunderten.

Meine 2 Cent, OK, um zu ignorieren und weiterzumachen, keine Notwendigkeit, den Kommentar zu korrigieren oder anzufechten.

@csantanapr Ich stimme zu, es könnte sich auch lohnen, Feature-Sets zu vergleichen. Proxy-Unterstützung, Cache-Unterstützung, Authentifizierungsfunktionen usw. Wenn Sie eine bestimmte Anforderungsfunktion verwenden und sie woanders finden müssen, wäre dies ein guter Zeitpunkt, darüber zu sprechen.

axios bekommt meine Stimme, besonders als Frontender.

Sehenswert: ky (Frontend) und ky-universal (isomorph)

Axios-Benutzer hier. Auf diese Weise können alle unsere Teams unabhängig von der Umgebung dieselbe Bibliothek verwenden: Browser oder nodejs (auf dem Server oder ohne Server ausgeführt). Sehr gut gepflegt, und alle unsere Leute lieben es.

Wir haben einen guten Vergleich zwischen got , request , node-fetch , axios und superagent in der got Readme : https://github.com/sindresorhus/got#comparison
(PR willkommen, wenn Sie Ungenauigkeiten sehen. Wir haben versucht, es so neutral wie möglich zu halten.)

Got hat auch einen Migrationsleitfaden für den Umzug von request : https://github.com/sindresorhus/got/blob/master/migration-guides.md

Für mich neige ich dazu, Wrapper um die Fetch-API zu erstellen, also ist Node-Fetch mein Goto. Trotz der negativen Aspekte lade ich es normalerweise auf global.fetch in node, damit ich mich darauf verlassen kann, dass es immer verfügbar ist, ähnlich wie im Browser (über Polyfill für ältere Browser). Kann auch isomorphic-fetch verwenden, was so ziemlich ein Wrapper um Node-Fetch für Node und das Fetch-Polyfill (oder bereits verfügbares Fetch) im Browser ist. Da ich keine Legacy-Browser unterstützen muss, verwende ich einfach das globale und richte das globale für die Verwendung in node.

Hey, Wreck (https://www.npmjs.com/package/wreck) ist das, was ich benutze

Ich würde etwas bevorzugen, das die Abruf-API auf dem Client nachahmt. Bibliotheken wie Axios, Superagent usw. sind Abstraktionen auf höherer Ebene auf einer Standardanforderungsbibliothek. Als Ersatz für die Anforderungsbibliothek auf niedriger Ebene möchte ich etwas sehen, das das Äquivalent auf niedriger Ebene auf dem Client für die Zwecke der universellen js-Entwicklung widerspiegelt. Bibliotheken wie Axios und Superagent können sich dann einfach neu implementieren, und ihre Benutzer können sie weiterhin verwenden, aber diese sollten für diesen Zweck nicht als grundlegend angesehen werden.

@Velveeta Ich habe mir die Axios- Codebasis angesehen und sehe keine Beweise dafür, dass sie auf einer "Standardanforderungsbibliothek auf niedrigerer Ebene" basiert. Sagen Sie mir bitte, wie Sie zu diesem Schluss gekommen sind?

Der Vergleich von @sindresorhus ist bei weitem der bessere Ansatz als meine obige Liste. https://github.com/sindresorhus/got#comparison

node-fetch/isomorphic-fetch ist für die meisten Kunden ein geeigneter Low-Level-Baustein. Ich würde gerne einen fetch-basierten Request-Shim sehen.

Ich würde fetch jeden Tag mit einer schöneren API umwickeln. Nun, ich denke, das ist nur eine Frage der Präferenz, aber zu implizieren, dass die Abruf-API großartig ist, nur weil sie ein De-facto-Standard in den Browsern ist, ist einfach falsch. Ich weiß, es ist weniger Rauschen, wenn es auf beiden Seiten isomorph ist, aber das macht es nicht besser.

Es gibt r2 von @mikeal selbst. Es soll ein spiritueller Nachfolger von request sein. Es hat eine Promise API und ist 16kb komprimiert.

Axios funktioniert vielleicht im Browser gut, aber das war nicht unsere Erfahrung damit auf Node.js. Außerdem bin ich mir nicht sicher, ob es noch aktiv gewartet wird.

@ kreig303 Ich habe mir die Interna von Axios nicht angesehen, also war mir das nicht bewusst. Sieht so aus, als würde es derzeit auf regulären XHRs basieren, was sinnvoll ist, da es sich um eine Lösung für Client- und Serveranfragen handelt. Ich meinte einfach, dass axios ziemlich funktionsreich ist, und etwas, das ein bisschen mehr nackte Knochen für ein grundlegendes Modul in Betracht zieht, wie ein Ersatz für Anfragen, und dann andere Bibliotheken mit mehr Funktionen darauf aufbauen lassen, wenn sie dies wünschen. Ich habe mich für etwas entschieden, das die Abruf-API widerspiegelt, speziell für den Zweck, sowohl auf dem Client als auch auf dem Server eine konsistente API zu haben (wie die XHRs, die Axios zugrunde liegen), und weil es der logische Nachfolger von XHR ist. Wenn ein schönerer API-Wrapper gewünscht wird, gibt es reichlich Gelegenheit, ihn zu verpacken und eine andere Bibliothek mit dieser optimalen API zu veröffentlichen, aber ich bin ganz für Funktions- und API-Parität zwischen Client und Server, wo immer dies möglich ist.

Nun, eines der Probleme, die wir anfordern, sind zu viele Funktionen und zu viel exponierter Status, selbst der, der als intern angesehen wird. Es ist Fluch und Segen zugleich, so viele Funktionen zu haben. Es ist ein Segen, denn deshalb ist es so beliebt, und es war das Erste. Es ist ein Fluch, denn ohne eine Menge ständiger Bemühungen, die Codebasis sauber, unkompliziert und generell spannend zu halten, stirbt das Projekt schließlich. Und das ist nicht einmal das Problem einer Anfrage, sondern die eigene Perspektive des Benutzers, immer etwas aus seiner eigenen Ebene herausnehmen zu wollen und es stattdessen woanders unter die Decke zu stecken.

Nun, ich denke, Axios haben den gleichen Glauben ..

Was wir stattdessen alle tun können, ist uns zumindest etwas Mühe zu geben, um zu verstehen, wie das Rad funktioniert, und dann zu versuchen, jede einzelne Aufgabe zu durchdenken und zu sehen, welches Rad am besten passt.

@ofrobots Das ist ein etwas selektiver Screenshot für eine so häufig verwendete Bibliothek. Hier ist meins:

FWIW Ich kann mich nicht erinnern, ob ich es als Back-End-Bibliothek verwendet habe, daher bin ich nicht in der Lage, Ihre Behauptungen zu überprüfen (es sei denn, Sie hatten einen besonderen Anwendungsfall, der nicht abgedeckt wurde).

@Velveeta Ich sehe, wohin du damit gehst, ich weiß nur nicht, ob Meta-Libs der richtige Weg sind.

Meine Stimme von Frontend ist für axios . Winzig, stabil und vorhersehbar.

Ich persönlich verwende Wretch sowohl für meine FE- als auch für BE-Projekte - hauptsächlich, weil die API wirklich intuitiv ist.

Ein Wrapper um Fetch - funktioniert auch gut mit Node-Fetch.

Für Leute, die nach einer axios -ähnlichen Erfahrung zusätzlich zur fetch API suchen, gibt es gaxios . Es wurde von einem Entwickler bei Google erstellt und unterstützt derzeit alle HTTP-Interaktionen des Node.js-Clients der Google-API. Daher scheint es sicher zu sein, es als kampferprobt und aktiv genutzt zu betrachten!

(👋 bei @JustinBeckwith)

Hey, Wreck (https://www.npmjs.com/package/wreck) ist das, was ich benutze

Es ist auch der zugrunde liegende HTTP-Client für das Hapijs-Framework. Die Umsetzung ist obendrein sehr sauber.

Es gibt r2 von @mikeal selbst. Es soll ein spiritueller Nachfolger von request sein. Es hat eine Promise API und ist 16kb komprimiert.

Diese Bibliothek wird nicht gepflegt. Wenn Sie eine ähnliche API wünschen, würde ich ky empfehlen, das ~1 KB minifiziert und gezippt ist und von denselben Leuten wie got gepflegt wird.

Axios funktioniert vielleicht im Browser gut, aber das war nicht unsere Erfahrung damit auf Node.js. Außerdem bin ich mir nicht sicher, ob es noch aktiv gewartet wird.

Ich verwende Axios in Node mit großer Zufriedenheit. Hauptsächlich in Lambdas und hauptsächlich, weil es reich an Funktionen ist, aber keine verrückte Abhängigkeitskette enthält. @ofrobots , welche Erfahrungen haben Sie damit in Node gemacht?

Als Frontend-fokussierter Typ, der von Zeit zu Zeit auch Node Js macht, waren Axiome meine erste Wahl. Einfache API von Facebook funktioniert auf Browsern und Knoten? Getan

Ich wusste nicht, dass es Facebook ist? Aber ja, das ist meine Goto-Bibliothek für den gesamten API-Zugriff.

Wir verwenden diese Bibliothek tinkoff-request https://github.com/TinkoffCreditSystems/tinkoff-request. Klein, funktioniert im Browser und auf dem Server und basiert auf dem Konzept von Plug-Ins. Die Bibliothek wurde erstellt, um die gleichzeitige Verwendung mehrerer Arten von komplexem Caching zu ermöglichen.

Hat jemand Typed-Rest-Client von Microsoft verwendet? Scheint ein gut gepflegtes Paket zu sein, das in TypeScript geschrieben wurde (für mich ist es ein großes Plus).

dies sollte wreck (aus dem Ökosystem hapi ) enthalten

Ich habe kürzlich https://github.com/grantila/fetch-h2 mit großem Erfolg verwendet

Gibt es derzeit einen bekannten kompatiblen Drop-In-Ersatz? Es ist in KOA integriert und gibt mir Stream-Probleme

Wie am Anfang der Ausgabe erwähnt, habe ich an einer anderen Bibliothek namens bent gearbeitet, die ich jetzt lieber verwende.

Seit einiger Zeit ist bent nicht mehr für die Verwendung im Browser konzipiert. Da die API jetzt ziemlich stabil ist, habe ich einige Zeit damit verbracht, eine Browserversion auf fetch zu schreiben. Anstatt zu versuchen, die Node.js-Version zu browserifizieren, ist die Browserversion ihr eigener Einstiegspunkt in package.json.

Also, ja, bent hat jetzt Browser-Unterstützung und es ist ziemlich gut:

• keine Abhängigkeiten oder Polyfills (vollständig auf fetch und ArrayBuffer aufgebaut, also kein Buffer- oder Stream-Polyfill und keine zu bündelnden Deps)
• ~2K-Webpack-Bundle, un-minifiziert oder gzippt (jemand sollte mir nach seinen bevorzugten Minifiern und Kompressoren mitteilen, was dies ist).
• Alle Tests werden in Headless Chrome bestanden, die in der Node.js-Version eine 100-prozentige Abdeckung aufweisen (es gibt immer noch keine großartige Möglichkeit, automatisierte Browserabdeckungstests durchzuführen).

Das ist großartig @mikeal

@csantanapr danke! :)

Axios kann Ihren Knotendienst zum Absturz bringen: https://github.com/axios/axios/issues/1804

Für mich sind die wichtigsten Bedenken:

• Funktioniert es mit minimaler Konfiguration in meiner Unternehmensumgebung? (Beitragende Faktoren: Unternehmensproxys sind HTTP für HTTP- und HTTPS-Ziele, nicht alle Proxys verarbeiten alle Zertifikate auf die gleiche Weise korrekt, ...)
  
  
  
  • Dieser hat mich vor etwa einem Jahr davon abgehalten, Request abzuschalten.
  
  
• Unterstützt es Streaming für Fälle, in denen ich beispielsweise Proxy-Uploads/Downloads von Dateien durchführen muss?

Danach ist es mir egal, wie die Benutzeroberfläche aussieht, solange die gängigsten Operationen bequem sind. Ich mache mir auch keine allzu großen Sorgen um die Größe auf der Serverseite, obwohl dies wichtig ist, wenn Sie dieselbe Bibliothek an beiden Enden wiederverwenden möchten.

EDIT: Yeeeaaaah kann nicht genau sagen, dass ich dir da die Schuld gebe.

EDIT 2: Ich denke, ich werde einen Blick auf node-libcurl werfen.

@joedski ya, das Proxy-Zeug wird außerhalb der Anfrage nicht allgemein unterstützt. Und ehrlich gesagt, angesichts der Menge an Arbeit, die es gekostet hat, das zum Laufen zu bringen und zu unterstützen, bin ich nicht überrascht, dass niemand es tun will, mich eingeschlossen ;) Ich habe es einmal gemacht und ich springe nicht gerade auf, um zu schreiben es wieder für gebogen 🤷🏽‍♀️

Endlich habe ich begonnen, die Bibliothek node-libcurl zu verwenden, um Anfragen von nodejs zu stellen. Weil es eine native Curl-Bibliothek verwendet, die sehr ausgereift und seit Jahren in der Produktion getestet ist. Es funktioniert einwandfrei mit allen Arten von Proxys, Weiterleitungen und verfügt über Promise- und Stream-Schnittstellen.

Teeny-Request (>1 Mio wöchentliche Downloads)

Drop-in-Ersatz auf Anfrage, aber viel kleiner – und mit weniger Optionen. Verwendet node-fetch unter der Haube. Setzen Sie es dort ein, wo Sie request verwenden würden.

node-fetch wird falsch gemeldet und nur die "Browser"-Version wird gemeldet (was den Punkt einer _Node.js_-Liste zunichte macht). Das scheint falsch gemessen worden zu sein:

• https://unpkg.com/[email protected]/browser.js

Stattdessen sollte eines der folgenden gemessen werden:

• https://unpkg.com/[email protected]/lib/index.js
• https://unpkg.com/[email protected]/lib/index.mjs
• https://unpkg.com/[email protected]/lib/index.es.js

Sie sind alle um ~40kb

unfetch wird ebenfalls falsch gemeldet:

• Die Homepage sagt , dass "Use in Node.JS by isomorphic-unfetch" behandelt wird, also sollte es die Kombination aus beiden melden.
• isomorphic-unfetch verwendet node-fetch ( code , docs ) für Node.js, daher sollte die gemeldete Größe mindestens der von node-fetch entsprechen (siehe meinen vorherigen Kommentar).

Da es so viel angesprochen wurde, sollte ich ein wenig über meine Erfahrung mit node-fetch sagen.

Zunächst einmal ist es eine ziemliche Leistung. Die Menge an Code und Entwicklungsaufwand, die dafür aufgewendet wurde, ist viel größer als das, was wir jemals in Auftrag gegeben haben. fetch scheint eine kleine API zu sein, und ich denke, die Leute gehen davon aus, dass der Aufwand, eine kompatible API in Node.js bereitzustellen, gering ist, aber das ist es wirklich nicht.

Infolgedessen ist die Codebasis massiv. Es ist eine beträchtliche Abhängigkeit in Node.js, die Sie in Browserpaketen wahrscheinlich überhaupt nicht sehen werden, aber es ist nicht so, als ob die Größe der Abhängigkeit in Node.js kein Problem wäre, insbesondere in serverlosen Umgebungen.

node-fetch ist beim Testen unverzichtbar, da es die gesamte Arbeit der vollständigen Emulation der APIs des Browsers erledigt, aber wenn Sie es in einer Anwendung verwenden, sogar in einer, die in Node.js und im Browser ausgeführt wird, ist es einfach zu viel Code und zu viel Umweg, um es wert zu sein.

Meiner Meinung nach besteht der derzeit richtige Ansatz für eine Bibliothek, die sowohl in Node.js als auch in Browsern ein HTTP-Client sein möchte, darin, eine einheitliche API mit einer geteilten Implementierung mit fetch im Browser und require(‘http’) zu implementieren fetch oder require(‘http’) abzielen und sich nicht auf die Emulation dieser APIs auf beiden Seiten verlassen. Dies ist tatsächlich viel einfacher als Sie vielleicht denken, wie Sie an der Implementierung von bent sehen können, die unglaublich klein ist https://github.com/mikeal/bent/tree/master/src

@mikeal Mir fällt das Quadrieren schwer

Infolgedessen ist die Codebasis massiv. Es ist eine beträchtliche Abhängigkeit in Node.js, die Sie in Browserpaketen wahrscheinlich überhaupt nicht sehen werden, aber es ist nicht so, als ob die Größe der Abhängigkeit in Node.js kein Problem wäre, insbesondere in serverlosen Umgebungen.

Welches ist mit der im OP aufgeführten Bündelgröße von 0,4 kB die kleinste aller angegebenen Alternativen?

@domenic Die Komplexität der Emulation der Browser-APIs ist das Hauptproblem, es ist viel unnötiger Code und Umwege beim Debuggen. Sie haben die Blob API , Sie haben eine Menge Rangordnung für die body , Sie haben fast 400 Zeilen von header marshalling , und das ist nicht einmal das Ansehen die eigentliche API, die offengelegt wird.

Wie ich schon sagte, es ist beeindruckend, aber es ist auch nur eine Menge knapper, cleverer und letztendlich unnötiger Code, wenn Sie etwas anderes tun möchten, als die fetch API zu emulieren.

@mikeal Sie haben nicht einmal erwähnt, dass eine Tonne mehr Code erforderlich ist, damit der Knotenabruf zu 100% mit der Abruf-API kompatibel ist: Es unterstützt keine lesbaren und beschreibbaren Streams von what-wg (etwas, das Sie beim Emulieren von Umgebungen benötigen wie Cloudflare Worker.

Hmm, ich verstehe immer noch nicht ganz, wie man "eine Tonne" "ultimativ unnötigen" Code mit "0,4 kB, weniger als jeder andere Eintrag in der Tabelle und 0,25-mal so groß wie gebogen " (was angeblich "das Richtige ist Ansatz" und "unglaublich klein").

@domenic vergleichen Sie die Größe des Browserpakets? Ich spreche von der Komplexität, diese in Node.js zu debuggen. Im Browser würde ich erwarten, dass der größte Teil des node-fetch -Codes nicht vorhanden ist, daher verstehe ich nicht wirklich, was Sie vergleichen.

Ich vergleiche den Wert im OP; Ich bin mir nicht sicher, wie das gemessen wird. Vielleicht wird es nicht richtig gemessen, was eine gute Information wäre, um das OP zu aktualisieren!

@domenic ah ja, das sind alles Browser-Bundle-Größen, und da der Beitrag ziemlich alt ist, sind viele von ihnen möglicherweise veraltet, obwohl die Zahl bent immer noch nah genug ist.

@root/request - ein 80/20 Drop-In-Ersatz, geschrieben in 500 LoC und NULL Abhängigkeiten:

Absichtlich erstellt und gegen das Verhalten von request.js getestet.

https://git.rootprojects.org/root/request.js

Hallo allerseits! Ich recherchiere ein wenig, um einen würdigen Ersatz für meine Projekte zu finden. Im Moment habe ich Folgendes zusammengestellt: https://github.com/emanuelcasco/http-packages-benchmark

Empfehlungen und Meinungen sind natürlich willkommen!

Da request jetzt offiziell veraltet ist, könnte ich nicht mehr betonen, wie wichtig es ist, postman-request offiziell als vollwertigen Drop-in-Ersatz für request und möglicherweise @root/request vorzuschlagen request benötigen und sich nicht um zB. Ströme.

Dies ermöglicht es jedem Paketbetreuer, request fallen zu lassen und die lästige Verfallsmeldung loszuwerden, ohne mehr als ein paar Minuten Entwicklungszeit mit diesem Problem zu verbringen und ohne seine gesamte Bibliothek oder App umgestalten zu müssen. Es hat mich einige Zeit und Frustration gekostet, herauszufinden, dass es solche Drop-In-Ersatzteile gibt.

Und ja, ich bin mir bewusst, dass nur "Abwertung" nichts kaputt macht. Ja, technisch gesehen kann jeder immer noch request verwenden und es möglicherweise noch Jahrzehnte lang verwenden. Das ist jedoch nicht das, wofür Abwertung verwendet werden soll. Deprecation soll als Aufruf zum Handeln fungieren, als "Gnadenfrist" für Leute, ihren Code zu aktualisieren, bis jemand irgendwo beschließt, einen Stecker zu ziehen.

Ich hasse es wirklich, wenn "deprecation" nur verwendet wird, um "end-of-support" oder "end-of-maintenance" zu kennzeichnen, wie es hier der Fall zu sein scheint. Aber ich würde mich viel weniger darum kümmern, das zu kaufen, wenn es einen offiziell unterstützten UND aktiv gepflegten Drop-In-Ersatz mit vollständiger Funktionalität wie postman-request gäbe.

Hat schon mal jemand darüber nachgedacht, die Wartung dieses Pakets an das Postman-Team zu übergeben? Anstatt request , warum schlagen Sie ihnen nicht vor, postman-request auf request zu portieren und sie die neuen offiziellen Betreuer werden zu lassen?

Tut mir leid, dass ich hier für meine eigene kleine Bibliothek werbe

Entwickelt, um nur in nodejs verwendet zu werden

const http = require('@zhangfuxing/http');
const assert = require('assert');

(async () => {
  // http
  const httpRes = await http.get('http://baidu.com');
  assert(httpRes.includes('<html>'));

  // https
  const httpsRes = await http.get('https://cnodejs.org/api/v1/topics?limit=1&mdrender=false');
  assert(httpsRes.success === true);

  // download file: use pipe
  const fs = require('fs');
  const res = await http.get('http://localhost:3000', {
    responseType: "stream"
  })
  res.pipe(require('fs').createWriteStream('zfx.txt'))
  // or use pipeline
  const stream = require('stream');
  const util = require('util');
  const pipeline = util.promisify(stream.pipeline);
  const res = await http.get(`${url}/stream`, {
    responseType: "stream"
  });
  await pipeline(res, fs.createWriteStream('zfx.txt'));

  // post Buffer
  const res = await http.post('http://localhost/upload', Buffer.from('abc'));
  assert(res.success === true);

  // post Stream
  const fs = require('fs');
  const readStream = fs.createReadStream('./index.js');
  const res = await http.post('http://localhost/upload', readStream);
  assert(res.success === true);

  // post json
  const data = {
    username: 'zfx',
    password: 'password'
  };
  const res = await http.post('http://localhost/upload', data);
  assert(res.success === true);

  // post application/x-www-form-urlencoded
  const data = {
    username: 'zfx',
    password: 'password'
  };
  const options = {
    headers: {
      'Content-Type': 'application/x-www-form-urlencoded'
    }
  };
  const res = await http.post('http://localhost/upload', data, options);
  assert(res.success === true);

  // post FormData
  const FormData = require('form-data');
  const form = new FormData();
  const fs = require('fs');
  const readStream = fs.createReadStream('./index.js');
  form.append('my_field', 'my value');
  form.append('my_buffer', Buffer.from('abc'));
  form.append('my_file', readStream);
  // Set filename by providing a string for options
  form.append('my_file', readStream, '1.js' );
  // provide an object.
  form.append('my_file', readStream, { 
    filename: 'bar.jpg', 
    contentType: 'image/jpeg', 
    knownLength: 19806
  });
  const formHeaders = form.getHeaders();
  const res = await http.post('http://localhost/upload', form, {
    headers: {
      ...formHeaders,
    },
  });
  assert(res.success === true);

  // head
  const res = await http.head(url);
  assert(res.statusCode === 200);
  assert(res.statusMessage === 'OK');
  assert(res.headers && typeof res.headers === 'object');
  assert(res.statusCode === 200);
  assert(res.data === '');

  // options
  const res = await http.options(url);
  assert(res === 'GET,HEAD,POST,PUT,PATCH,DELETE'); 
})().catch(console.error);

Ich habe festgestellt, dass Wretch die beste Option ist, wenn Sie moderne Typoskript-SPAs erstellen, da es von Anfang an in TS geschrieben ist. Entspricht praktisch Axios und unterstützt zusätzliche Middleware . Ich finde die API im Vergleich zu Ky auch an einigen Stellen etwas netter.

Irgendwelche von diesen unterstützen http2?

@sakalys got hat experimentelle HTTP2-Unterstützung, die in der nächsten Hauptversion (in Kürze erhältlich) integriert und stabil sein wird.

fast Drop-in-Ersatz?

https://github.com/googleapis/teeny-request

Wirklich traurig zu sehen, dass diese Bibliothek veraltet ist. Ich mag Axios, aber für einige Zwecke war Anfrage meine erste Wahl.

Irgendeine dieser Zeiten für Support-Anfragen? Wie die Zeit bis zum ersten Byte, Netzwerkverzögerung und so weiter?
Ich verwende die Anforderungsbibliothek für ein Projekt und das Timing ist entscheidend dafür.

Google bietet gaxios https://github.com/googleapis/gaxios - axios api over node-fetch an

Wir haben einen guten Vergleich zwischen got , request , node-fetch , axios und superagent in der got Readme : https://github.com/sindresorhus/got#comparison
_(PR willkommen, wenn Sie irgendwelche Ungenauigkeiten sehen. Wir haben versucht, es so neutral wie möglich zu halten)_

Got hat auch einen Migrationsleitfaden für den Umzug von request : https://github.com/sindresorhus/got/blob/master/migration-guides.md

Got's Migrationsleitfaden für den Umzug von request wurde _umgezogen_ nach:
https://github.com/sindresorhus/got/blob/master/documentation/migration-guides.md

Darf ich vorschlagen, postman-request hinzuzufügen? Das werde ich bei meinem nächsten Projekt ausprobieren. So steht es jedenfalls in der Dokumentation...

Dies ist ein Fork des ausgezeichneten Anforderungsmoduls, das in Postman Runtime verwendet wird. Es enthält einige Bugfixes, die nicht auf Anfrage behoben wurden.

Redaxios ist wie 800 Byte mit nativem Abruf https://github.com/developit/redaxios

Meine Güte!! Ich habe das aus 3 Stunden herausgefunden und meinen Code immer wieder überprüft. Und es gab mir Fehler 404, ich war frustriert. Vielen Dank. Ich denke, ich werde mit Fetch gehen.

https://www.npmjs.com/package/teeny-request ist eine weitere Option, die von Google APIs verwendet wird.

Wie Anfrage, aber viel kleiner - und mit weniger Optionen. Verwendet Node-Fetch unter der Haube. Setzen Sie es dort ein, wo Sie Anfrage verwenden würden. Verbessert die Lade- und Analysezeit von Modulen.

Was wäre besser node-fetch oder die gegabelte Version von requests , die jetzt von PostMan gepflegt wird. Ich habe meine Node-Reise gerade erst begonnen, also benötige ich etwas Einfaches.

Das Timeout von Axios scheint nie behoben zu werden👎🏿

Ich war sehr überrascht, Phin hier nicht zu sehen.

https://github.com/ethanent/phin

Wie wäre es mit url-request ?

https://github.com/Debdut/Url

Wie wäre es mit url-request ?

https://github.com/Debdut/Url

Noch etwas jung (1 Tag!) und es fehlen (daher) einige Features, sieht aber vielversprechend aus - wird genau beobachtet.

@cjk danke für dein Feedback, welche Funktionen werden dir gefallen? Wenn Sie konkreter werden könnten.

Schnell q. Was ist der Vorteil der Verwendung dieser Bibliotheken anstelle von nativem nodejs http ?

@cgarrovillo Kleiner Code => Mehr Wirkung

Probieren Sie URL-Anfrage aus, schauen Sie sich einfach den Funktionsumfang und die Möglichkeiten an 🤟

@cjk danke für dein Feedback, welche Funktionen werden dir gefallen? Wenn Sie konkreter werden könnten.

@Debdut Ich denke an Funktionen wie:

1. Authentifizierung
2. HTTP2
3. Proxy-Unterstützung
4. Kompression
5. Behandlung von Zeitüberschreitungen
6. benutzerdefinierte Haken
7. Abbruch anfordern

Aus den Dokumenten von url-request geht nicht hervor, welche davon unterstützt werden und wie.

Allerdings haben mir die vielen Beispiele gefallen, die Sie liefern!

Verwenden Sie einfach die Anfrage, bis sie nicht mehr funktioniert.

In Winkel rxjs und beobachtbar sind ausgezeichnet

Jede Bibliothek hat eine Keksdose wie eine Anfrage?

Testen der Got-HTTP-Bibliothek mit rotem Knoten. ✋

• npm installiert
• Kontext hinzugefügt
• Jetzt im Flow-Editor importiert _got_ in meine js-Funktion

Ergebnisse
Funktioniert gut bei HTTP-Anfragen. (einen Einzeltest gemacht).
FEHLGESCHLAGEN ❌ bei HTTPS-Anfragen. Ich habe :
RequestError: connect ECONNREFUSED 127.0.0.1:443

Zuerst dachte ich, dass dies etwas mit node-red env zu tun hat. Später wurde festgestellt, dass dies ein offenes Problem in Got Repo ist: https://github.com/sindresorhus/got/issues/1414. 👎
Und meiner Meinung nach Grund genug, stattdessen auf _axios_ zu setzen. ✅
Wollte nur, dass du es weißt.

@damdauvaotran Irgendeine Bibliothek hat eine Keksdose wie eine Anfrage?

Siehe got.js, der Migrationsleitfaden .

Warum wird Gaxios nicht erwähnt?

FWIW, hier ist ein NPM-Trends-Link , der alle oben genannten Projekte vergleicht. Obwohl dies nicht der einzige Faktor ist, der bei der Entscheidung eine Rolle spielt, ist Popularität für uns und bei den meisten Projekten ziemlich wichtig.
Zum jetzigen Zeitpunkt ist node-fetch die beliebteste Alternative.

Interessant @ericsnap ... node-fetch und axios stehen an erster bzw. dritter (fast zweiter) Stelle in der Popularität.

Und ich notiere den folgenden Slogan aus den Gaxios-Dokumenten :

Ein HTTP-Anforderungsclient, der eine Axios-ähnliche Schnittstelle über dem Knotenabruf bereitstellt

Gaxios kombiniert also zwei der beliebtesten Bibliotheken. Ich habe auf Gaxios umgestellt und es macht super viel Spaß, es zu benutzen.

node-fetch / axios

https://www.npmtrends.com/node-fetch-vs-got-vs-axios-vs-superagent

Nachdem ich eine Reihe der aktuellen Anfragealternativen überprüft habe, habe ich den Sprung in @sindresorhus gewagt . Ich brauchte ungefähr einen Tag, um mich an die API zu gewöhnen (Dokumente waren ziemlich gut). Ich habe aufgrund von extend und der Einrichtung von so viel an einem Ort eine erhebliche Verringerung des LoC erlebt, dann sind die Call-Sights und die Fehlerbehandlung normalerweise nur eine Handvoll LoC. Es fühlt sich so viel glatter an als der Bitte-, Bitte-Versprechen-, Bitte-Versprechen-Native-Tanz. Ein tolles Feature-Set auch. Tolle Arbeit und vielen Dank @sindresorhus!

Ich habe mich nicht auf die Migration gefreut, aber ich fühle mich jetzt so viel sauberer.