En tant que gars axé sur le frontend qui fait aussi de temps en temps node.js, axios a été mon choix.
L'API facile, de Facebook, fonctionne sur les navigateurs et les nœuds ? Terminé

Selon une discussion récente avec @mikeal , j'ai essayé Bent. En tant que développeur Node.js qui utilise request depuis un certain temps maintenant, bent était définitivement une transition facile - fortement recommandée 💖

@reconbot Vous voudrez peut-être ajouter got , needle et urllib .

Eh bien, c'est un peu mal de promouvoir ma propre petite bibliothèque ici, mais puisque c'est le but du problème, le voici : request-compose est un client HTTP fonctionnel, 0 deps, avec prise en charge des promesses, des flux et d'un tas de d'autres options utiles, dont la plupart sont très proches de celles trouvées dans la demande.

J'ai aussi écrit un article à ce sujet. L'idée générale est que chacun est encouragé à composer ses propres clients HTTP, spécifiquement adaptés à ses propres besoins.

Quant à la taille du bundle, je n'en ai aucune idée, mais elle devrait être assez petite, bien que ce client n'ait jamais été conçu pour être utilisé dans le navigateur.

Il serait peut-être bon d'ajouter les colonnes suivantes au tableau :

• Nombre d'étoiles dans Github (oui je sais déjà que ce n'est pas le seul facteur lors du choix d'une lib)
• Nombre de téléchargements npm (peut-être hebdomadaire, même statistique que le site Web npm, et oui je sais déjà que ce n'est pas le seul facteur lors du choix d'une bibliothèque)

En mettant côte à côte ces chiffres, certaines bibliothèques ont des milliers d'étoiles et des millions de téléchargements hebdomadaires, contre d'autres par centaines.

Mes 2 cents, OK pour ignorer et passer à autre chose, pas besoin de corriger ou de contester le commentaire.

@csantanapr Je suis d'accord, cela vaut peut-être aussi la peine de comparer les ensembles de fonctionnalités. Prise en charge du proxy, prise en charge du cache, fonctionnalités d'authentification, etc. Si vous utilisez une fonctionnalité spécifique de la demande et avez besoin de la trouver ailleurs, ce serait le bon moment pour en parler.

axios obtient mon vote, surtout en tant que front-ender.

A voir : ky (frontend) et ky-universal (isomorphe)

Utilisateur Axios ici. De cette façon, toutes nos équipes peuvent utiliser la même bibliothèque quel que soit l'environnement : navigateur ou nodejs (fonctionnant en serveur ou sans serveur). Très bien entretenu, et tout notre peuple l'adore.

Nous avons une bonne comparaison entre got , request , node-fetch , axios et superagent dans le got readme : https://github.com/sindresorhus/got#comparison
(PR bienvenue si vous voyez des inexactitudes. Nous avons essayé de le garder aussi neutre que possible)

Got a également un guide de migration pour passer de request : https://github.com/sindresorhus/got/blob/master/migration-guides.md

Pour moi, j'ai tendance à faire des wrappers autour de l'api de récupération, donc la récupération de nœud est mon goto. Malgré les aspects négatifs, je le charge généralement sur global.fetch dans le nœud, donc je peux compter sur sa disponibilité permanente, un peu comme dans le navigateur (via polyfill pour les anciens navigateurs). Peut également utiliser isomorphic-fetch qui est à peu près un wrapper autour de node-fetch pour node, et le fetch polyfill (ou fetch déjà disponible) dans le navigateur. Comme je n'ai pas à prendre en charge les navigateurs hérités, j'utilise simplement le global et j'établis le global à utiliser dans node.

Hey, Wreck (https://www.npmjs.com/package/wreck) est ce que j'utilise

Je préférerais quelque chose qui imite l'API de récupération sur le client. Les bibliothèques comme axios, superagent, etc. sont des abstractions de niveau supérieur au-dessus d'une bibliothèque de requêtes standard. En remplacement de la bibliothèque de requêtes de bas niveau, j'aimerais voir quelque chose qui reflète l'équivalent de bas niveau sur le client aux fins du développement js universel. Des bibliothèques comme axios et superagent peuvent alors simplement se réimplémenter en plus de cela, et ses utilisateurs peuvent continuer à les utiliser, mais celles-ci ne doivent pas être considérées comme fondamentales à cette fin.

@Velveeta Je suis allé voir la base de code axios et je ne vois aucune preuve qu'elle est basée sur une "bibliothèque de requêtes standard de niveau inférieur". Pouvez-vous me dire comment vous en êtes arrivé à cette conclusion ?

La comparaison de @sindresorhus est de loin la meilleure approche que ma liste ci-dessus. https://github.com/sindresorhus/got#comparison

node-fetch/isomorphic-fetch est un bloc de construction de bas niveau approprié pour la plupart des clients. J'aimerais voir une cale de demande basée sur la récupération.

Je voudrais envelopper la récupération avec une API plus agréable n'importe quel jour. Eh bien, je suppose que c'est juste une question de préférence, mais impliquer que l'API de récupération est géniale simplement parce que c'est un standard de facto dans les navigateurs est tout simplement faux. Je sais que c'est moins bruyant de l'avoir isomorphe des deux côtés, mais cela ne le rend pas meilleur.

Il y a r2 de @mikeal lui-même. Il est censé être un successeur spirituel de request . Il a une API Promise et est compressé à 16 Ko.

Axios peut fonctionner correctement dans le navigateur, mais cela n'a pas été notre expérience avec Node.js. De plus, je ne sais pas s'il est activement maintenu.

@ kreig303 Je n'ai pas examiné les composants internes d'axios, donc je n'en étais pas conscient. On dirait qu'il est actuellement basé sur des XHR réguliers, ce qui est logique, car il s'agit d'une solution pour les requêtes client et serveur. Je voulais simplement dire qu'axios est assez riche en fonctionnalités, et quelque chose d'un peu plus simple devrait être envisagé pour un module fondamental comme un remplacement pour la demande, puis laisser d'autres bibliothèques plus riches en fonctionnalités s'ajouter si elles le souhaitent. J'ai opté pour quelque chose qui reflète l'API de récupération spécifiquement dans le but d'avoir une API cohérente sur le client et le serveur (comme les XHR qui sous-tendent axios), et parce que c'est le successeur logique de XHR. Si un wrapper d'API plus agréable est souhaité, il existe de nombreuses possibilités de l'encapsuler et de publier une autre bibliothèque avec cette API optimale, mais je suis tout à fait pour la parité des fonctionnalités et des API entre le client et le serveur partout où cela peut être fait.

Eh bien, l'un des problèmes que nous avons dans la demande est trop de fonctionnalités et trop d'états exposés, même celui qui est considéré comme interne. C'est à la fois une malédiction et une bénédiction d'avoir autant de fonctionnalités. C'est une bénédiction parce que c'est pourquoi il est si populaire, et c'était le premier. C'est une malédiction car sans une énorme quantité d'efforts constants pour garder la base de code propre, simple et généralement passionnante à travailler, le projet finit par mourir. Et ce n'est même pas un problème de requête, c'est la propre perspective de l'utilisateur de vouloir toujours sortir quelque chose de sa propre couche, et de le mettre à la place sous la couverture ailleurs.

Eh bien, je suppose qu'axios a la même foi ..

Donc, ce que nous pouvons tous faire à la place, c'est mettre au moins un certain effort pour comprendre le fonctionnement de la roue, puis essayer de réfléchir à chaque tâche individuelle à accomplir et de voir quelle roue convient le mieux.

@ofrobots c'est un peu une capture d'écran sélective pour une bibliothèque aussi populaire. Voilà le mien:

FWIW Je ne me souviens pas si je l'avais utilisé comme bibliothèque principale, donc je ne suis pas en mesure de vérifier vos affirmations (sauf si vous aviez un cas d'utilisation particulier qu'il ne couvrait pas).

@Velveeta Je vois où vous voulez en venir, je ne sais tout simplement pas si les méta-libs sont la voie à suivre.

Mon vote de Frontend est pour axios . Minuscule, stable et prévisible.

Personnellement, j'utilise misérable pour mes projets FE et BE - principalement parce que l'API est vraiment intuitive.

Un wrapper autour de la récupération - fonctionne également bien avec la récupération de nœud.

Pour ceux qui recherchent une expérience de type axios en plus de l'API fetch , il y a gaxios . Il a été construit par un développeur de Google et alimente actuellement toutes les interactions HTTP du client Node.js de l'API Google , il semble donc sûr de le considérer comme testé et activement utilisé !

(👋 chez @JustinBeckwith)

Hey, Wreck (https://www.npmjs.com/package/wreck) est ce que j'utilise

C'est aussi le client http sous-jacent pour le framework hapijs. La mise en œuvre est très propre pour démarrer.

Il y a r2 de @mikeal lui-même. Il est censé être un successeur spirituel de request . Il a une API Promise et est compressé à 16 Ko.

Cette bibliothèque n'est pas entretenue. Si vous voulez une API similaire, je recommanderais ky , qui est ~1kb minifié et gzippé, et maintenu par les mêmes personnes que got .

Axios peut fonctionner correctement dans le navigateur, mais cela n'a pas été notre expérience avec Node.js. De plus, je ne sais pas s'il est activement maintenu.

J'utilise axios dans Node avec une grande satisfaction. Principalement dans les lambdas et principalement parce qu'il est riche en fonctionnalités mais qu'il ne vient pas avec une chaîne de dépendance folle. @ofrobots quelle a été votre expérience avec Node ?

En tant que gars axé sur le front-end qui fait également du node js de temps en temps, les axiomes ont été mon choix. L'API facile, de Facebook, fonctionne sur les navigateurs et les nœuds ? Terminé

Je ne savais pas que c'était Facebook ? Mais oui, c'est ma bibliothèque goto pour tous les accès API.

Nous utilisons cette bibliothèque tinkoff-request https://github.com/TinkoffCreditSystems/tinkoff-request. Petit, fonctionne dans le navigateur et sur le serveur et repose sur le concept de plug-ins. La bibliothèque a été créée pour permettre l'utilisation simultanée de plusieurs types de mise en cache complexe.

Quelqu'un a-t-il utilisé typed-rest-client de Microsoft ? On dirait un package bien entretenu écrit en TypeScript (pour moi, c'est un gros plus).

cela devrait inclure wreck (de l'écosystème hapi )

J'ai récemment utilisé https://github.com/grantila/fetch-h2 avec beaucoup de succès

Existe-t-il actuellement un remplaçant compatible connu ? Il est intégré à KOA et me pose des problèmes de flux

Comme mentionné au début du numéro, j'ai travaillé sur une autre bibliothèque que je préfère maintenant utiliser, appelée bent .

Pendant un certain temps, bent n'a pas été conçu pour fonctionner dans le navigateur. Étant donné que l'API est assez stable maintenant, j'ai passé du temps à écrire une version du navigateur au-dessus de fetch . Au lieu d'essayer de naviguer dans la version Node.js, la version du navigateur est son propre point d'entrée dans package.json.

Donc, oui, bent est maintenant compatible avec les navigateurs et c'est plutôt bien :

• zéro dépendances ou polyfills (entièrement construit sur fetch et ArrayBuffer, donc pas de polyfill Buffer ou Stream et pas de deps à regrouper)
• ~ 2K webpack bundle non minifié ou gzippé (quelqu'un devrait me faire savoir ce que c'est après ses minificateurs et compresseurs préférés).
• Tous les tests passent en chrome sans tête, qui ont une couverture de 100 % dans la version Node.js (n'ont toujours pas un excellent moyen de faire des tests de couverture de navigateur automatisés)

C'est super @mikeal

@csantanapr merci ! :)

axios peut planter votre service de nœud : https://github.com/axios/axios/issues/1804

Pour moi, les principales préoccupations sont :

• Fonctionne-t-il avec une configuration minimale dans mon environnement d'entreprise ? (facteurs contributifs : les proxys d'entreprise sont HTTP pour les cibles HTTP et HTTPS, tous les proxys ne gèrent pas correctement tous les certificats, de la même manière, ...)
  
  
  
  • Celui-ci m'a particulièrement empêché d'éteindre Request il y a environ un an.
  
  
• Prend-il en charge le streaming, pour les cas où j'ai besoin, par exemple, de télécharger/télécharger des fichiers proxy ?

Après cela, je me fiche de l'apparence de l'interface tant que les opérations les plus courantes sont pratiques. Je ne suis pas non plus trop préoccupé par la taille, côté serveur, bien que cela soit important si vous souhaitez réutiliser la même bibliothèque aux deux extrémités.

EDIT : Yeeeeaaah ne peut pas exactement dire que je vous en veux.

EDIT 2 : Je suppose que je vais jeter un œil à node-libcurl .

@joedski ya, les trucs de proxy ne sont pas largement pris en charge en dehors de la demande. Et TBH, étant donné la quantité de travail qu'il a fallu pour que cela fonctionne et pour le soutenir, je ne suis pas surpris que personne ne veuille le faire, y compris moi;) Je l'ai fait une fois et je ne saute pas exactement pour écrire encore pour plié 🤷🏽‍♀️

Enfin, j'ai commencé à utiliser la bibliothèque node-libcurl pour faire des requêtes à partir de nodejs. Parce qu'il utilise la bibliothèque curl native, qui est très mature et testée pendant des années en production. Il fonctionne parfaitement avec tous les types de proxys, de redirections et possède des interfaces de promesse et de flux.

teeny-request (> 1 million de téléchargements hebdomadaires)

Remplacement instantané sur demande, mais beaucoup plus petit - et avec moins d'options. Utilise node-fetch sous le capot. Insérez-le là où vous utiliseriez request .

node-fetch est signalé de manière incorrecte et seule la version "navigateur" est signalée (vaincre le point d'une liste _Node.js_). Voici ce qui semble mal mesuré :

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

Au lieu de cela, l'un ou l'autre de ces éléments doit être mesuré :

• 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

Ils sont tous autour de ~ 40kb

unfetch est également signalé de manière incorrecte :

• La page d'accueil indique que "L'utilisation dans Node.JS est gérée par isomorphic-unfetch", il devrait donc signaler la combinaison des deux.
• isomorphic-unfetch utilise node-fetch ( code , docs ) pour Node.js, donc sa taille signalée doit être au moins celle de node-fetch (voir mon commentaire précédent).

Comme cela a été tellement évoqué, je devrais parler un peu de mon expérience avec node-fetch .

Tout d'abord, c'est tout un exploit. La quantité de code et d'efforts d'ingénierie qui y ont été consacrés est bien supérieure à ce que nous avons jamais mis en demande. fetch semble être une petite API et je pense que les gens supposent que l'effort pour fournir une API compatible dans Node.js est nominal, mais ce n'est vraiment pas le cas.

En conséquence, la base de code est massive. Il s'agit d'une dépendance importante dans Node.js, que vous ne verrez probablement pas du tout dans les ensembles de navigateurs, mais ce n'est pas comme si la taille de la dépendance n'était pas un problème dans Node.js, en particulier dans les environnements sans serveur.

node-fetch est indispensable lors des tests car il fait tout le travail d'émulation complète des API du navigateur, mais si vous l'utilisez dans une application, même une qui est exécutée dans Node.js et dans le navigateur, c'est juste trop de code et trop d'indirection pour en valoir la peine.

IMO, la bonne approche à l'heure actuelle pour une bibliothèque qui souhaite être un client http à la fois dans Node.js et dans les navigateurs consiste à implémenter une API uniforme avec une implémentation fractionnée en utilisant fetch dans le navigateur et require(‘http’) dans Node.js. Les applications et les clients http ne doivent pas cibler directement fetch ou require(‘http’) et ne doivent pas s'appuyer sur l'émulation de ces API de part et d'autre. C'est en fait beaucoup plus facile que vous ne le pensez, comme vous pouvez le voir dans l'implémentation de bent qui est incroyablement petit https://github.com/mikeal/bent/tree/master/src

@mikeal j'ai du mal à m'adapter

En conséquence, la base de code est massive. Il s'agit d'une dépendance importante dans Node.js, que vous ne verrez probablement pas du tout dans les ensembles de navigateurs, mais ce n'est pas comme si la taille de la dépendance n'était pas un problème dans Node.js, en particulier dans les environnements sans serveur.

avec la taille de paquet de 0,4 Ko indiquée dans l'OP, quelle est la plus petite de toutes les alternatives proposées ?

@domenic la complexité de l'émulation de l'API du navigateur est le principal problème, c'est beaucoup de code inutile et d'indirection lors de la tentative de débogage. Vous avez le Blob API , vous avez beaucoup de marshalling pour le body , vous avez près de 400 lignes de header marshalling , et cela ne regarde même pas l'API réelle qui est exposée.

Comme je l'ai dit, c'est impressionnant, mais c'est aussi juste une tonne de code laconique, intelligent et finalement inutile si vous voulez faire autre chose qu'émuler l'API fetch .

@mikeal , vous n'avez même pas mentionné qu'il y a une tonne de code supplémentaire requis pour que la récupération de nœud soit compatible à 100 % avec l'API de récupération : elle ne prend pas en charge les flux lisibles et inscriptibles de what-wg (quelque chose dont vous avez besoin lors de l'émulation d'environnements comme Cloudflare Workers.

Hmm, je ne comprends toujours pas très bien comment concilier "une tonne" de code "finalement inutile" avec "0,4 ko, moins que toutes les autres entrées de la table et 0,25x la taille de courbé " (ce qui est censé être "le bon approche" et "incroyablement petit").

@domenic comparez -vous la taille du bundle de navigateur ? Je parle de la complexité du débogage de ceux-ci dans Node.js. Dans le navigateur, je m'attendrais à ce que la plupart du code node-fetch soit inexistant, donc je ne comprends pas vraiment ce que vous comparez.

Je compare la valeur dans l'OP; Je ne sais pas comment cela est mesuré. Peut-être qu'il n'est pas mesuré correctement, ce qui serait une bonne information pour mettre à jour l'OP avec !

@domenic ah oui, ce sont toutes des tailles de bundle de navigateur, et comme le message est assez ancien, beaucoup d'entre eux peuvent être obsolètes bien que le bent soit encore assez proche.

@root/request - un remplacement direct 80/20 écrit en 500 LoC et ZÉRO dépendances :

Créé et testé contre le comportement de request.js, exprès.

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

Salut à tous! Je fais une petite recherche afin de trouver un remplaçant digne d'une demande pour mes projets. Pour l'instant, voici ce que j'ai rassemblé : https://github.com/emanuelcasco/http-packages-benchmark

Les recommandations et les avis sont bien sûr les bienvenus !

Étant donné request est désormais officiellement obsolète, je ne saurais trop insister sur l'importance de proposer officiellement postman-request en remplacement de request et éventuellement @root/request pour ceux qui ont juste besoin d'un sous-ensemble limité de request et qui ne s'en soucient pas, par exemple. ruisseaux.

Cela permet à n'importe quel mainteneur de paquet de laisser tomber request et de se débarrasser du message de dépréciation ennuyeux sans passer plus de quelques minutes de temps de développement sur ce problème, et sans avoir à refactoriser toute sa bibliothèque ou son application. Il m'a fallu un certain temps et de la frustration pour comprendre même que de tels remplaçants existent.

Et oui, je suis conscient que la "dépréciation" ne casse rien. Oui, techniquement, tout le monde peut toujours utiliser request et peut-être continuer à l'utiliser pendant peut-être même des décennies à venir. Cependant, ce n'est pas à cela que l'amortissement est censé servir. La dépréciation EST censée agir comme un appel à l'action, comme une "période de grâce" pour que les gens mettent à jour leur code jusqu'à ce que quelqu'un quelque part décide de débrancher une prise.

Je déteste vraiment, vraiment quand la "dépréciation" est simplement utilisée pour marquer la "fin du support" ou la "fin de la maintenance", comme cela semble être le cas ici. Mais je serais beaucoup moins dérangé d'acheter ceci, s'il y avait un remplacement complet de fonctionnalités officiellement pris en charge ET activement maintenu comme postman-request .

En fait, quelqu'un a-t-il envisagé de confier la maintenance de ce package à l'équipe Postman ? Au lieu de déprécier request , pourquoi ne pas leur proposer de porter postman-request vers request et de les laisser devenir les nouveaux mainteneurs officiels ?

Désolé de promouvoir ma propre petite bibliothèque ici

Conçu pour être utilisé uniquement dans nodejs

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);

J'ai trouvé que Wretch était la meilleure option si vous construisez des SPA dactylographiés modernes, étant donné qu'il est écrit en TS pour commencer. Est effectivement la même fonctionnalité qu'Axios et prend en charge des intergiciels supplémentaires . Je pense que l'API est un peu plus agréable à certains endroits que Ky.

L'un d'entre eux prend en charge http2 ?

@sakalys got a un support HTTP2 expérimental, qui sera intégré et stable dans la prochaine version majeure (bientôt disponible).

près de baisse de remplacement?

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

Vraiment triste de voir cette bibliothèque obsolète. J'aime axios, mais pour certains objectifs, la demande était mon premier choix.

L'un de ces délais de demande d'assistance ? Comme le temps du premier octet, le décalage du réseau, etc.
J'utilise la bibliothèque de requêtes pour un projet et le timing est crucial pour cela.

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

Nous avons une bonne comparaison entre got , request , node-fetch , axios et superagent dans le got readme : https://github.com/sindresorhus/got#comparison
_(PR bienvenue si vous voyez des inexactitudes. Nous avons essayé de le garder aussi neutre que possible)_

Got a également un guide de migration pour passer de request : https://github.com/sindresorhus/got/blob/master/migration-guides.md

Le guide de migration de Got pour passer de request a _déplacé_ vers :
https://github.com/sindresorhus/got/blob/master/documentation/migration-guides.md

Puis-je suggérer d'ajouter postman-request ? Je vais essayer celui-ci sur mon prochain projet. En tout cas, c'est ce qui est dit à ce sujet sur la documentation...

Il s'agit d'un fork de l'excellent module de requête, qui est utilisé dans Postman Runtime. Il contient quelques corrections de bogues qui ne sont pas corrigées dans la demande.

Redaxios est comme 800 octets en utilisant la récupération native https://github.com/developit/redaxios

Dieu ! J'étais en train de comprendre cela à partir de 3 heures, j'ai vérifié mon code encore et encore. Et cela m'a donné l'erreur 404, j'étais frustré. Merci beaucoup. Je pense que je vais aller avec Fetch.

https://www.npmjs.com/package/teeny-request est une autre option, utilisée par les API Google.

Comme demande, mais beaucoup plus petit - et avec moins d'options. Utilise la récupération de nœud sous le capot. Insérez-le là où vous utiliseriez request. Améliore le temps de chargement et d'analyse des modules.

Quoi de mieux node-fetch ou la version fourchue de requests qui est maintenant maintenue par PostMan. Je viens juste de commencer mon parcours Node, j'ai donc besoin de quelque chose de simple.

Le délai d'attente d'axios semble ne jamais être corrigé👎🏿

J'ai été très surpris de ne pas voir phin ici.

https://github.com/ethanent/phin

Que diriez-vous url-request ?

https://github.com/Debdut/Url

Que diriez-vous url-request ?

https://github.com/Debdut/Url

Encore un peu jeune (1 jour !) et (donc) manque de certaines fonctionnalités, mais semble prometteur - à surveiller de près.

@cjk merci pour vos commentaires, quelles fonctionnalités aimerez-vous ? Si vous pouviez être plus précis.

Rapide Q. Quel est l'avantage d'utiliser ces bibliothèques au lieu du http natif nodejs ?

@cgarrovillo Petit code => Plus d'impact

essayez url-request , regardez simplement l'ensemble des fonctionnalités et les possibilités 🤟

@cjk merci pour vos commentaires, quelles fonctionnalités aimerez-vous ? Si vous pouviez être plus précis.

@Debdut Je pense à des fonctionnalités telles que :

1. Authentification
2. HTTP2
3. Prise en charge de proxy
4. Compression
5. Gestion du délai d'attente
6. crochets personnalisés
7. Demande l'annulation

Il n'est pas évident d'après les documents de url-request lesquels sont pris en charge et comment.

Cependant, j'ai aimé les nombreux exemples que vous fournissez!

Continuez simplement à utiliser request jusqu'à ce qu'il cesse de fonctionner.

Les rxjs angulaires et observables sont excellents

Une bibliothèque a une boîte à cookies comme une demande ?

Test de la bibliothèque HTTP obtenue avec le nœud rouge. ✋

• npm installé
• ajouté au contexte
• Maintenant dans l'éditeur de flux, importé _got_ dans ma fonction js

Résultats
Fonctionne bien lors de requêtes HTTP. (fait un seul test).
FAILS ❌ lors de requêtes HTTPS. J'ai eu :
RequestError: connect ECONNREFUSED 127.0.0.1:443

Au début, je pensais que c'était quelque chose lié à l'env node-red. Plus tard, il s'agit d'un problème ouvert dans got repo : https://github.com/sindresorhus/got/issues/1414. 👎
Et à mon avis, c'est une raison suffisante pour opter pour _axios_ à la place. ✅
Je voulais juste que vous sachiez.

@damdauvaotran Toute bibliothèque a une boîte à biscuits comme demande ?

Voir got.js, le guide de migration .

Pourquoi gaxios n'est-il pas mentionné ?

FWIW, voici un lien sur les tendances NPM qui compare tous les projets mentionnés en haut. Bien que ce ne soit pas le seul facteur impliqué dans la décision, la popularité est assez importante pour nous et sur la plupart des projets.
Au moment d'écrire ces lignes, node-fetch est l'alternative la plus populaire.

Intéressant @ericsnap ... node-fetch et axios sont respectivement premier et troisième (presque deuxième) en popularité.

Et je note le slogan suivant des docs gaxios :

Un client de requête HTTP qui fournit une interface de type axios au-dessus de la récupération de nœud

Gaxios combine donc deux des bibliothèques les plus populaires. Je me suis converti à gaxios et c'est super amusant à utiliser.

récupération de nœud / axios

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

Après avoir examiné un tas d'alternatives de demande actuelles, j'ai franchi le pas @sindresorhus dans got. Il m'a fallu environ une journée pour m'habituer à l'API (la documentation a été assez bonne). J'ai connu une réduction significative de LoC en raison de extend et de la configuration de tant de choses au même endroit, alors les vues d'appel et la gestion des erreurs ne sont généralement qu'une poignée de LoC. Cela semble tellement plus lisse que la danse demande, demande-promesse, demande-promesse-indigène. Un excellent ensemble de fonctionnalités également. Excellent travail et merci beaucoup @sindresorhus !

Je n'attendais pas la migration avec impatience, mais je me sens tellement plus propre maintenant.