Como un tipo enfocado en la interfaz que también hace node.js de vez en cuando, axios ha sido mi opción.
Easy API, de Facebook, funciona en navegadores y nodos. Hecho

Según una discusión reciente con @mikeal , lo intenté con Bent. Como desarrollador de Node.js que ha estado usando request durante un tiempo, doblar fue definitivamente una transición fácil, muy recomendable 💖

@reconbot Es posible que desee agregar got , needle y urllib .

Bueno, se siente un poco mal promocionar mi propia pequeña biblioteca aquí, pero dado que ese es el objetivo del problema, aquí está: request-compose es un cliente HTTP funcional de 0 deps con soporte para promesas, flujos y un montón de otras opciones útiles, la mayoría de las cuales son muy cercanas a las que se encuentran en solicitud.

También escribí un artículo al respecto. La idea general es animar a todos a crear sus propios clientes HTTP, específicamente adaptados a sus propias necesidades.

En cuanto al tamaño del paquete, no tengo idea, pero debería ser bastante pequeño, aunque este cliente nunca fue diseñado para usarse en el navegador.

Podría ser bueno agregar las siguientes columnas a la tabla:

• Número de estrellas en Github (sí, ya sé que este no es el único factor al elegir una librería)
• Número de descargas de npm (quizás semanalmente, la misma estadística que el sitio web de npm, y sí, ya sé que este no es el único factor al elegir una librería)

Al comparar estos números, algunas bibliotecas tienen miles de estrellas y millones de descargas semanales, mientras que otras tienen cientos.

Mis 2 centavos, está bien ignorar y seguir adelante, no es necesario corregir o disputar el comentario.

@csantanapr Estoy de acuerdo, también podría valer la pena comparar conjuntos de funciones. Soporte de proxy, soporte de caché, funciones de autenticación, etc. Si usa una función específica de solicitud y necesita encontrarla en otro lugar, este sería un buen momento para hablar sobre ello.

axios recibe mi voto, especialmente como front-ender.

Vale la pena echarle un vistazo: ky (frontend) y ky-universal (isomorfo)

Usuario de Axios aquí. De esa manera, todos nuestros equipos pueden usar la misma biblioteca independientemente del entorno: navegador o nodejs (ejecutándose en servidor o sin servidor). Muy bien mantenido, y a toda nuestra gente le encanta.

Tenemos una buena comparación entre got , request , node-fetch , axios y superagent en el archivo Léame got : https://github.com/sindresorhus/got#comparison
(PR bienvenido si ve alguna inexactitud. Hemos tratado de mantenerlo lo más neutral posible)

Got también tiene una guía de migración para pasar de request : https://github.com/sindresorhus/got/blob/master/migration-guides.md

Para mí, tiendo a hacer envoltorios alrededor de la API de búsqueda, por lo que la búsqueda de nodos es mi goto. A pesar de los aspectos negativos, generalmente lo cargo en global.fetch en el nodo, por lo que puedo confiar en que siempre estará disponible, como en el navegador (a través de polyfill para navegadores más antiguos). También puede usar isomorphic-fetch que es más o menos un envoltorio alrededor de node-fetch para node, y el polyfill de búsqueda (o búsqueda ya disponible) en el navegador. Como no tengo que admitir navegadores heredados, solo uso el global y establezco el global para usar en node.

Oye, Wreck (https://www.npmjs.com/package/wreck) es lo que uso

Preferiría algo que imite la API de búsqueda en el cliente. Las bibliotecas como axios, superagent, etc. son abstracciones de nivel superior además de una biblioteca de solicitudes estándar. Como reemplazo de la biblioteca de solicitudes de bajo nivel, me gustaría ver algo que refleje el equivalente de bajo nivel en el cliente para el desarrollo de js universal. Librerías como axios y superagent pueden volver a implementarse además de eso, y sus usuarios pueden continuar usándolas, pero no deben considerarse fundamentales para este propósito.

@Velveeta Fui y miré el código base de axios y no veo evidencia de que se base en una "biblioteca de solicitud estándar de nivel inferior". Por favor, dime cómo llegaste a esta conclusión.

La comparación de @sindresorhus es, con mucho, el mejor enfoque que mi lista anterior. https://github.com/sindresorhus/got#comparison

node-fetch/isomorphic-fetch es un bloque de construcción de bajo nivel adecuado para la mayoría de los clientes. Me encantaría ver una corrección de solicitud basada en búsqueda.

Envolvería fetch con una API más agradable cualquier día. Bueno, supongo que es solo una cuestión de preferencia, pero dar a entender que la API de búsqueda es excelente solo porque es un estándar de facto en los navegadores es simplemente incorrecto. Sé que es menos ruido tenerlo isomorfo en ambos lados, pero eso no lo hace mejor.

Hay r2 del mismo @mikeal . Está destinado a ser un sucesor espiritual de request . Tiene una API Promise y está comprimido en 16kb.

Axios puede funcionar bien en el navegador, pero esa no ha sido nuestra experiencia con Node.js. Además, no estoy seguro de si ya se mantiene activamente.

@ kreig303 No he investigado las partes internas de axios, así que no estaba al tanto de eso. Parece que actualmente se basa en XHR normales, lo que tiene sentido, ya que es una solución para las solicitudes del cliente y del servidor. Simplemente quise decir que axios es bastante rico en funciones, y se debe considerar algo un poco más básico para un módulo fundamental como un reemplazo para la solicitud, y luego dejar que otras librerías más ricas en funciones se construyan encima de eso si lo desean. Opté por algo que refleje la API de búsqueda específicamente con el propósito de tener una API consistente tanto en el cliente como en el servidor (como los XHR que subyacen a axios), y porque es el sucesor lógico de los XHR. Si se desea un envoltorio de API más agradable, hay muchas oportunidades para envolverlo y lanzar otra biblioteca con esa API óptima, pero estoy totalmente a favor de la paridad de funciones y API entre el cliente y el servidor donde sea que se pueda hacer.

Bueno, uno de los problemas que tenemos en la solicitud son demasiadas funciones y demasiado estado expuesto, incluso el que se considera interno. Es a la vez una maldición y una bendición tener tantas funciones. Es una bendición porque es por eso que es tan popular, y fue el primero. Es una maldición porque sin una gran cantidad de esfuerzo constante para mantener el código base limpio, sencillo y, en general, emocionante para trabajar, el proyecto finalmente muere. Y eso ni siquiera es un problema de solicitud, es la propia perspectiva del usuario de querer siempre sacar algo de su propia capa y, en cambio, ponerlo debajo de la manta en otro lugar.

Bueno, supongo que los axios tienen la misma fe..

Entonces, lo que todos podemos hacer en su lugar es esforzarnos al menos un poco para comprender cómo funciona la rueda, y luego tratar de pensar en cada tarea individual en cuestión y ver qué rueda encaja mejor.

@ofrobots es una captura de pantalla un poco selectiva para una biblioteca de uso tan popular. Aquí está el mío:

FWIW No recuerdo si lo usé como una biblioteca de back-end, por lo que no estoy en condiciones de verificar sus afirmaciones (a menos que tenga un caso de uso peculiar que no cubrió).

@Velveeta Veo a dónde vas con esto, simplemente no sé si las meta-libs son el camino a seguir.

Mi voto de Frontend es por axios . Diminuto, estable y predecible.

Yo personalmente uso wretch para mis proyectos FE y BE, principalmente porque la API es muy intuitiva.

Un envoltorio alrededor de la recuperación: también funciona bien con la recuperación de nodos.

Para las personas que buscan una experiencia similar a axios además de la API de fetch , existe gaxios . Fue creado por un desarrollador de Google y actualmente impulsa todas las interacciones HTTP del cliente Node.js de la API de Google , por lo que parece seguro considerarlo probado en batalla y utilizado activamente.

(👋 en @JustinBeckwith)

Oye, Wreck (https://www.npmjs.com/package/wreck) es lo que uso

También es el cliente http subyacente para el marco hapijs. La implementación es muy limpia para arrancar.

Hay r2 del mismo @mikeal . Está destinado a ser un sucesor espiritual de request . Tiene una API Promise y está comprimido en 16kb.

Esa biblioteca no se mantiene. Si desea una API similar, recomendaría ky , que es de ~1kb minimizado y comprimido con gzip, y mantenido por las mismas personas que got .

Axios puede funcionar bien en el navegador, pero esa no ha sido nuestra experiencia con Node.js. Además, no estoy seguro de si ya se mantiene activamente.

Uso axios en Node con gran satisfacción. Principalmente en lambdas y principalmente porque es rico en características pero no viene con una cadena de dependencia loca. @ofrobots ¿cuál ha sido tu experiencia con él en Node?

Como un tipo enfocado en la interfaz que también hace node js de vez en cuando, axioms ha sido mi opción. Easy API, de Facebook, funciona en navegadores y nodos. Hecho

¿No sabía que era Facebook? Pero sí, esta es mi biblioteca goto para todos los accesos a la API.

Usamos esta biblioteca tinkoff-request https://github.com/TinkoffCreditSystems/tinkoff-request. Pequeño, funciona en el navegador y en el servidor y se basa en el concepto de complementos. La biblioteca se creó para permitir el uso simultáneo de varios tipos de almacenamiento en caché complejo.

¿Alguien usó typed-rest-client de Microsoft? Parece un paquete bien mantenido escrito en TypeScript (para mí es una gran ventaja).

esto debería incluir wreck (del ecosistema hapi )

Recientemente he estado usando https://github.com/grantila/fetch-h2 con gran éxito

¿Existe actualmente algún reemplazo directo compatible conocido? Está integrado en KOA y me da problemas de transmisión.

Como se mencionó al comienzo de la edición, he estado trabajando en otra biblioteca que ahora prefiero usar llamada bent .

Durante un tiempo bent no ha sido diseñado para funcionar en el navegador. Dado que la API es bastante estable ahora, pasé algún tiempo escribiendo una versión del navegador además de fetch . En lugar de tratar de buscar la versión de Node.js, la versión del navegador es su propio punto de entrada en package.json.

Entonces, ya, bent tiene compatibilidad con el navegador ahora y es bastante bueno:

• cero dependencias o polyfills (completamente construido en fetch y ArrayBuffer, por lo que no hay polyfill de Buffer o Stream y no hay dependencias para agrupar)
• Paquete web de ~2K sin minificar o comprimido con gzip (alguien debería decirme qué es esto después de sus minificadores y compresores preferidos).
• Todas las pruebas están pasando en cromo sin cabeza, que tiene una cobertura del 100 % en la versión de Node.js (todavía no hay una excelente manera de realizar pruebas de cobertura de navegador automatizadas)

Esto es genial @mikeal

@csantanapr gracias! :)

axios puede bloquear su servicio de nodo: https://github.com/axios/axios/issues/1804

Para mí, las principales preocupaciones son:

• ¿Funciona con una configuración mínima en mi entorno corporativo? (factores que contribuyen: los proxies corporativos son HTTP para los objetivos HTTP y HTTPS, no todos los proxies manejan todos los certificados correctamente, de la misma manera, ...)
  
  
  
  • Este en particular me impidió apagar Solicitud hace un año más o menos.
  
  
• ¿Es compatible con la transmisión, para aquellos casos en los que necesito, por ejemplo, cargas/descargas de archivos proxy?

Después de eso, no me importa cómo se ve la interfaz siempre que las operaciones más comunes sean convenientes. Tampoco me preocupa demasiado el tamaño del lado del servidor, aunque eso es importante si desea reutilizar la misma biblioteca en ambos extremos.

EDITAR: Yeeeaaaah no puedo decir exactamente que te culpo allí.

EDICIÓN 2: Supongo que echaré un vistazo a node-libcurl .

@joedski ya, las cosas del proxy no son ampliamente compatibles fuera de la solicitud. Y TBH, dada la cantidad de trabajo que se necesitó para que funcionara y para respaldarlo, no me sorprende que nadie quiera hacerlo, incluyéndome a mí;) Lo hice una vez y no estoy exactamente saltando para escribir de nuevo por doblado 🤷🏽‍♀️

Finalmente, comencé a usar la biblioteca node-libcurl para realizar solicitudes desde nodejs. Porque utiliza la biblioteca curl nativa, que es muy madura y ha sido probada durante años en producción. Funciona a la perfección con todo tipo de proxies, redireccionamientos y tiene interfaces de promesa y transmisión.

teeny-request (>1 millón de descargas semanales)

Reemplazo directo por pedido, pero mucho más pequeño y con menos opciones. Usa node-fetch debajo del capó. Póngalo donde usaría request .

node-fetch se informa incorrectamente y solo se informa la versión del "navegador" (lo que anula el punto de una lista _Node.js_). Esto es lo que parece estar mal medido:

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

En su lugar, cualquiera de estos debe medirse:

• 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

Son todos alrededor de ~ 40kb

unfetch también se informa incorrectamente:

• La página de inicio dice que "El uso en Node.JS se maneja mediante isomorphic-unfetch", por lo que debería informar la combinación de ambos.
• isomorphic-unfetch usa node-fetch ( code , docs ) para Node.js, por lo que su tamaño informado debe ser al menos el de node-fetch (ver mi comentario anterior).

Dado que se ha mencionado tanto, debo decir un poco sobre mi experiencia con node-fetch .

En primer lugar, es todo un logro. La cantidad de código y esfuerzo de ingeniería que se ha invertido es mucho mayor de lo que solicitamos. fetch parece una API pequeña y creo que la gente asume que el esfuerzo por proporcionar una API compatible en Node.js es nominal, pero en realidad no lo es.

Como resultado, la base de código es masiva. Es una dependencia considerable en Node.js, que probablemente no verá en los paquetes de navegador, pero no es que el tamaño de la dependencia no sea un problema en Node.js, particularmente en entornos sin servidor.

node-fetch es indispensable cuando se prueba porque hace todo el trabajo de emular completamente las API del navegador, pero si lo usa en una aplicación, incluso una que se ejecuta en Node.js y en el navegador, es demasiado código y demasiada indirección para que valga la pena.

En mi opinión, el enfoque correcto en este momento para una biblioteca que quiere ser un cliente http tanto en Node.js como en los navegadores es implementar una API uniforme con una implementación dividida usando fetch en el navegador y require(‘http’) en Node.js. Las aplicaciones y los clientes http no deben apuntar a fetch o require(‘http’) directamente y no deben depender de la emulación de estas API en ninguno de los lados. En realidad, esto es mucho más fácil de lo que piensas, como puedes ver en la implementación de bent que es increíblemente pequeño https://github.com/mikeal/bent/tree/master/src

@mikeal me está costando cuadrar

Como resultado, la base de código es masiva. Es una dependencia considerable en Node.js, que probablemente no verá en los paquetes de navegador, pero no es que el tamaño de la dependencia no sea un problema en Node.js, particularmente en entornos sin servidor.

con el tamaño de paquete de 0,4 kB enumerado en el OP, ¿cuál es la más pequeña de todas las alternativas dadas?

@domenic, la complejidad de emular las API del navegador es el problema principal, es una gran cantidad de código innecesario e indirección cuando se intenta depurar. Tienes el Blob API , tienes mucha clasificación para el body , tienes casi 400 líneas de header marshalling , y eso sin siquiera mirar la API real que queda expuesta.

Como dije, es impresionante, pero también es solo un montón de código conciso, inteligente y, en última instancia, innecesario si desea hacer algo excepto emular la API fetch .

@mikeal , ni siquiera mencionaste que se requiere una tonelada más de código para que node-fetch sea 100% compatible con la API de recuperación: no admite transmisiones legibles y escribibles de what-wg (algo que necesita al emular entornos como trabajadores de Cloudflare.

Hmm, todavía no entiendo muy bien cómo cuadrar "una tonelada" de código "en última instancia innecesario" con "0,4 kB, menos que cualquier otra entrada en la tabla y 0,25 veces el tamaño de doblado " (que supuestamente es "el derecho acercamiento" e "increíblemente pequeño").

@domenic , ¿está comparando el tamaño del paquete del navegador? Estoy hablando de la complejidad de depurar estos en Node.js. En el navegador, esperaría que la mayor parte del código node-fetch no exista, por lo que realmente no entiendo lo que está comparando.

Estoy comparando el valor en el OP; No estoy seguro de cómo se mide eso. ¡Quizás no se mide correctamente, lo que sería una buena información para actualizar el OP!

@domenic ah, sí, esos son todos los tamaños de paquetes de navegador, y dado que la publicación es bastante antigua, muchos de ellos pueden estar desactualizados, aunque la cifra bent todavía es lo suficientemente cercana.

@root/request : un reemplazo directo 80/20 escrito en 500 LoC y CERO dependencias:

Creado y probado contra el comportamiento de request.js, a propósito.

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

¡Hola a todos! Estoy investigando un poco para encontrar un reemplazo digno de una solicitud para mis proyectos. Por ahora, esto es lo que he reunido: https://github.com/emanuelcasco/http-packages-benchmark

Se aceptan recomendaciones y opiniones por supuesto!

Como request ahora está oficialmente en desuso, no podría enfatizar más la importancia de proponer oficialmente postman-request como un reemplazo directo completo de funciones para request , y posiblemente @root/request para aquellos que solo necesitan un subconjunto limitado de request y no les importa, por ejemplo. arroyos

Esto permite que cualquier mantenedor de paquetes suelte request y se deshaga del molesto mensaje de obsolescencia sin gastar más de unos minutos de tiempo de desarrollo en este problema y sin tener que refactorizar toda su biblioteca o aplicación. Me tomó bastante tiempo y frustración darme cuenta incluso de que tales reemplazos directos existen.

Y sí, soy consciente de que solo "desaprobar" no rompe nada. Sí, técnicamente todo el mundo puede seguir usando request y posiblemente seguir usándolo durante las próximas décadas. Sin embargo, no es para eso para lo que se supone que debe usarse la desaprobación. Se supone que la obsolescencia actúa como un llamado a la acción, como un "período de gracia" para que las personas actualicen su código hasta que alguien en algún lugar decida desconectarse.

Realmente, realmente odio cuando "desuso" se usa simplemente para marcar "fin de soporte" o "fin de mantenimiento", como parece ser el caso aquí. Pero me molestaría mucho menos comprar esto, si hubiera un reemplazo directo con características completas respaldadas oficialmente Y mantenidas activamente como postman-request .

De hecho, ¿alguien ha considerado entregar el mantenimiento de este paquete al equipo de Postman? En lugar de desaprobar request , ¿por qué no proponerles que transfieran postman-request a request y dejar que se conviertan en los nuevos mantenedores oficiales?

Lamento promocionar mi pequeña biblioteca aquí.

Diseñado para usarse solo en 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);

Descubrí que Wretch es la mejor opción si está creando SPA mecanografiados modernos, dado que, para empezar, está escrito en TS. Tiene efectivamente las mismas funciones que Axios y es compatible con middleware adicional . Creo que la API es un poco mejor en un par de lugares en comparación con Ky también.

¿Alguno de estos admite http2?

@sakalys got tiene compatibilidad con HTTP2 experimental, que se integrará y será estable en la próxima versión principal (disponible pronto).

¿Cerca de caída en el reemplazo?

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

Realmente triste ver que esta biblioteca está obsoleta. Me gusta axios, pero para algunos propósitos, la solicitud fue mi primera elección.

¿Alguno de estos tiempos de solicitud de soporte? ¿Te gusta el tiempo hasta el primer byte, el retraso de la red, etc.?
Estoy usando la biblioteca de solicitudes para un proyecto y el tiempo es crucial para ello.

Google ofrece gaxios https://github.com/googleapis/gaxios - axios api sobre node-fetch

Tenemos una buena comparación entre got , request , node-fetch , axios y superagent en el archivo Léame got : https://github.com/sindresorhus/got#comparison
_(PR bienvenido si ve alguna inexactitud. Hemos tratado de mantenerlo lo más neutral posible)_

Got también tiene una guía de migración para pasar de request : https://github.com/sindresorhus/got/blob/master/migration-guides.md

La guía de migración de Got para pasar de request se ha _movido_ a:
https://github.com/sindresorhus/got/blob/master/documentation/migration-guides.md

¿Puedo sugerir agregar postman-request? Probaré este en mi próximo proyecto. De todos modos, esto es lo que se dice al respecto en la documentación ...

Esta es una bifurcación del excelente módulo de solicitud, que se usa dentro de Postman Runtime. Contiene algunas correcciones de errores que no se corrigen en la solicitud.

Redaxios es como 800 bytes usando búsqueda nativa https://github.com/developit/redaxios

¡¡Dios mio!! Me di cuenta de esto después de 3 horas, revisé mi código una y otra vez. Y me dio el error 404, estaba frustrado. Muchas gracias. Creo que iré con Fetch.

https://www.npmjs.com/package/teeny-request es otra opción, utilizada por las API de Google.

Como pedido, pero mucho más pequeño y con menos opciones. Utiliza búsqueda de nodos debajo del capó. Póngalo donde usaría la solicitud. Mejora el tiempo de carga y análisis de los módulos.

¿Qué sería mejor node-fetch o la versión bifurcada de requests que ahora mantiene PostMan? Recién comencé mi viaje de Node, así que necesito algo simple.

El tiempo de espera de axios parece que nunca se arregla 👎🏿

Me sorprendió mucho no ver a Phin aquí.

https://github.com/ethenent/phin

¿Qué tal url-request ?

https://github.com/Debdut/Url

¿Qué tal url-request ?

https://github.com/Debdut/Url

Todavía un poco joven (¡1 día!) y (por lo tanto) carece de algunas características, pero parece prometedor: lo observaré de cerca.

@cjk gracias por sus comentarios, ¿qué características le gustarán? Si pudieras ser más específico.

rápido q. ¿Cuál es la ventaja de usar estas bibliotecas en lugar de nodejs http nativos?

@cgarrovillo Código pequeño => Más impacto

intente url-request , solo mire el conjunto de características y posibilidades 🤟

@cjk gracias por sus comentarios, ¿qué características le gustarán? Si pudieras ser más específico.

@Debdut Estoy pensando en características como:

1. Autenticación
2. HTTP2
3. Proxy-soporte
4. Compresión
5. Manejo de tiempos de espera
6. ganchos personalizados
7. Solicitar una cancelación

No es obvio a partir de los documentos de url-request cuáles de ellos son compatibles y cómo.

Sin embargo, ¡me gustaron los muchos ejemplos que proporcionas!

Solo sigue usando request hasta que deje de funcionar.

En angular rxjs y observables son excelentes

¿Alguna librería tiene un tarro de galletas como una solicitud?

Prueba Obtuve la biblioteca HTTP con el nodo rojo. ✋

• npm instalado
• agregado al contexto
• Ahora en el editor de flujo, importé _got_ en mi función js

Resultados
Funciona bien cuando se realizan solicitudes HTTP. (hizo una sola prueba).
FALLA ❌ al hacer solicitudes HTTPS. Tengo :
RequestError: connect ECONNREFUSED 127.0.0.1:443

Al principio pensé que esto era algo relacionado con node-red env. Más tarde se encontró que este es un problema abierto en el repositorio: https://github.com/sindresorhus/got/issues/1414. 👎
Y en mi opinión, es motivo suficiente para optar por _axios_. ✅
Sólo quería que supieras.

@damdauvaotran ¿ Alguna biblioteca tiene un contenedor de cookies como una solicitud?

Consulte got.js, la guía de migración .

¿Por qué no se menciona a gaxios ?

FWIW, aquí hay un enlace de tendencias de NPM que compara todos los proyectos mencionados en la parte superior. Si bien no es el único factor involucrado en la decisión, la popularidad es muy importante para nosotros y en la mayoría de los proyectos.
Al escribir estas líneas, node-fetch es la alternativa más popular.

Interesante @ericsnap ... node-fetch y axios son el primero y el tercero (casi el segundo) en popularidad, respectivamente.

Y observo el siguiente eslogan de los documentos de gaxios :

Un cliente de solicitud HTTP que proporciona una interfaz similar a axios sobre la búsqueda de nodos

Entonces, gaxios combina dos de las bibliotecas más populares. Me he estado convirtiendo a gaxios y es muy divertido de usar.

búsqueda de nodos / axios

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

Después de revisar un montón de las alternativas de solicitud actuales, me sumergí @sindresorhus en got. Me tomó alrededor de un día acostumbrarme a la API (los documentos han sido bastante buenos). Experimenté una reducción significativa en la LoC debido a extend y la configuración de tanto en un solo lugar, luego las vistas de llamadas y el manejo de errores generalmente son solo un puñado de LoC. Se siente mucho más ingenioso que el baile de petición, petición-promesa, petición-promesa-nativa. Un gran conjunto de características también. Gran trabajo y muchas gracias @sindresorhus!

No esperaba con ansias la migración, pero ahora me siento mucho más limpio.