Como um cara focado em frontend que também faz node.js de tempos em tempos, axios tem sido minha escolha.
API fácil, do Facebook, funciona em navegadores e node? Feito

Por uma discussão recente com @mikeal , tentei Bent. Como um desenvolvedor Node.js que usa request há algum tempo, bent foi definitivamente uma transição fácil - altamente recomendado 💖

@reconbot Você pode adicionar got , agulha e urllib .

Bem, parece meio errado promover minha própria pequena biblioteca aqui, mas como esse é o objetivo do problema, aqui está: request-compose é um cliente HTTP funcional 0 deps com suporte para promessas, fluxos e um monte de outras opções úteis, a maioria das quais muito próximas das encontradas na solicitação.

Também escrevi um artigo sobre isso. A ideia geral é que todos sejam incentivados a compor seus próprios clientes HTTP, especificamente adaptados às suas próprias necessidades.

Quanto ao tamanho do pacote, não faço ideia, mas deve ser bem pequeno, embora esse cliente nunca tenha sido projetado para ser usado no navegador.

Pode ser bom adicionar as seguintes colunas à tabela:

• Número de estrelas no Github (sim eu já sei que esse não é o único fator na hora de escolher uma lib)
• Número de downloads npm (talvez semanalmente, mesma estatística do site npm, e sim eu já sei que esse não é o único fator na hora de escolher uma lib)

Ao colocar lado a lado esses números algumas libs têm milhares de estrelas e milhões de downloads semanais, contra outras centenas.

Meus 2 centavos, OK para ignorar e seguir em frente, não há necessidade de corrigir ou contestar o comentário.

@csantanapr Concordo, pode valer a pena comparar os conjuntos de recursos também. Suporte de proxy, suporte de cache, recursos de autenticação etc. Se você usa um recurso específico de solicitação e precisa encontrá-lo em outro lugar, este seria um bom momento para falar sobre isso.

axios recebe meu voto, especialmente como front-ender.

Vale a pena dar uma olhada: ky (frontend) e ky-universal (isomórfico)

Usuário do Axios aqui. Dessa forma, todas as nossas equipes podem usar a mesma biblioteca independente do ambiente: navegador ou nodejs (executando em servidor ou sem servidor). Muito bem conservado, e todo o nosso povo adora.

Temos uma boa comparação entre got , request , node-fetch , axios e superagent no readme got : https://github.com/sindresorhus/got#comparison
(Bem-vindo ao PR se você encontrar alguma imprecisão. Tentamos mantê-lo o mais neutro possível)

Got também tem um guia de migração para migrar de request : https://github.com/sindresorhus/got/blob/master/migration-guides.md

Para mim, costumo fazer wrappers em torno da fetch api, então node-fetch é meu goto. Apesar dos aspectos negativos, costumo carregá-lo em global.fetch no node, então posso confiar que ele estará sempre disponível, assim como no navegador (via polyfill para navegadores mais antigos). Também pode usar isomorphic-fetch que é praticamente um wrapper em torno de node-fetch para node, e o fetch polyfill (ou já disponível fetch) no navegador. Como não preciso dar suporte a navegadores legados, apenas uso o global e estabeleço o global para uso em node.

Ei, Wreck (https://www.npmjs.com/package/wreck) é o que eu uso

Eu preferiria algo que imitasse a API de busca no cliente. Libs como axios, superagent, etc são abstrações de nível superior em cima de uma biblioteca de solicitação padrão. Como substituto para a biblioteca de solicitação de baixo nível, gostaria de ver algo que espelhe o equivalente de baixo nível no cliente para fins de desenvolvimento universal de js. Bibliotecas como axios e superagent podem simplesmente se reimplementar em cima disso, e seus usuários podem continuar usando-as, mas elas não devem ser consideradas fundamentais para esse propósito.

@Velveeta Fui e examinei a base de código do axios e não vejo evidências de que ela seja baseada em uma "biblioteca de solicitação padrão de nível inferior". Por favor, me diga como você chegou a essa conclusão?

A comparação do @sindresorhus é de longe a melhor abordagem do que minha lista acima. https://github.com/sindresorhus/got#comparison

node-fetch/isomorphic-fetch é um bloco de construção de baixo nível adequado para a maioria dos clientes. Eu adoraria ver um calço de solicitação baseado em busca.

Eu envolveria a busca com uma API melhor a qualquer dia. Bem, acho que é apenas uma questão de preferência, mas implicar que a API de busca é ótima apenas porque é um padrão de fato nos navegadores está errado. Eu sei que é menos barulhento tê-lo isomórfico em ambos os lados, mas isso não o torna melhor.

Tem r2 do próprio @mikeal . Destina-se a ser um sucessor espiritual de request . Possui uma API Promise e é compactado em 16kb.

O Axios pode funcionar bem no navegador, mas essa não foi nossa experiência com ele no Node.js. Além disso, não tenho certeza se ele é mantido ativamente mais.

@ kreig303 Eu não examinei os componentes internos do axios, então não sabia disso. Parece que atualmente é baseado em XHRs regulares, o que faz sentido, pois é uma solução para solicitações de clientes e servidores. Eu simplesmente quis dizer que o axios é bastante rico em recursos, e algo um pouco mais básico deve ser considerado para um módulo fundamental, como um substituto para solicitação, e, em seguida, permitir que outras bibliotecas mais ricas em recursos sejam construídas em cima disso, se desejarem. Optei por algo que espelhe a API de busca especificamente para fins de ter uma API consistente tanto no cliente quanto no servidor (como os XHR's subjacentes aos axios) e porque é o sucessor lógico do XHR's. Se um wrapper de API melhor for desejado, há muitas oportunidades para envolvê-lo e liberar outra biblioteca com essa API ideal, mas sou a favor da paridade de recursos e API entre cliente e servidor onde quer que isso possa ser feito.

Bem, um dos problemas que temos na solicitação é muitos recursos e muito estado exposto, mesmo aquele que é considerado interno. É uma maldição e uma bênção ter tantos recursos. É uma bênção porque é por isso que é tão popular, e foi o primeiro. É uma maldição porque sem uma grande quantidade de esforço constante para manter a base de código limpa, direta e geralmente empolgante de se trabalhar, o projeto eventualmente morre. E isso nem é um problema de solicitação, é a própria perspectiva do usuário de sempre querer colocar algo fora de sua própria camada e, em vez disso, colocá-lo debaixo do cobertor em outro lugar.

Bem, eu acho que axios tem a mesma fé ..

Então, o que todos nós podemos fazer é colocar pelo menos algum esforço em entender como a roda funciona e, em seguida, tentar pensar em cada tarefa individual em mãos e ver qual roda se encaixa melhor.

@ofrobots isso é uma captura de tela seletiva para uma biblioteca tão popularmente usada. Aqui está o meu:

FWIW Não me lembro se a usei como uma biblioteca de back-end, então não estou em posição de verificar suas reivindicações (a menos que você tenha um caso de uso peculiar que não cobriu).

@Velveeta Eu vejo onde você está indo com isso, só não sei se meta-libs são o caminho a seguir.

Meu voto do Frontend é para axios . Minúsculo, estável e previsível.

Eu pessoalmente uso o wretch para meus projetos FE e BE - principalmente porque a API é realmente intuitiva.

Um wrapper em torno de fetch - funciona bem com node-fetch também.

Para pessoas que procuram uma experiência semelhante a axios em cima da API fetch , existe gaxios . Ele foi desenvolvido por um desenvolvedor do Google e atualmente alimenta todas as interações HTTP do cliente Node.js da API do Google , então parece seguro considerá-lo testado em batalha e usado ativamente!

(👋 em @JustinBeckwith)

Ei, Wreck (https://www.npmjs.com/package/wreck) é o que eu uso

É também o cliente http subjacente para a estrutura hapijs. A implementação é muito limpa para inicializar.

Tem r2 do próprio @mikeal . Destina-se a ser um sucessor espiritual de request . Possui uma API Promise e é compactado em 16kb.

Essa biblioteca não é mantida. Se você quiser uma API semelhante, eu recomendaria ky , que é ~1kb reduzido e compactado e mantido pelas mesmas pessoas que got .

O Axios pode funcionar bem no navegador, mas essa não foi nossa experiência com ele no Node.js. Além disso, não tenho certeza se ele é mantido ativamente mais.

Eu uso axios em Node com muita satisfação. Principalmente em lambdas e principalmente porque é rico em recursos, mas não vem com uma cadeia de dependência maluca. @ofrobots qual tem sido sua experiência com isso no Node?

Como um cara focado em frontend que também faz node js de tempos em tempos, axioms tem sido minha escolha. API fácil, do Facebook, funciona em navegadores e node? Feito

Eu não sabia que era Facebook? Mas sim, esta é minha biblioteca goto para todos os acessos à API.

Usamos esta biblioteca tinkoff-request https://github.com/TinkoffCreditSystems/tinkoff-request. Small, funciona no navegador e no servidor e é construído sobre o conceito de plug-ins. A biblioteca foi criada para permitir o uso simultâneo de vários tipos de cache complexo.

Alguém usou typed-rest-client da Microsoft? Parece um pacote bem mantido escrito em TypeScript (para mim é uma grande vantagem).

isso deve incluir wreck (do ecossistema hapi )

Recentemente, tenho usado https://github.com/grantila/fetch-h2 com grande sucesso

Existe atualmente alguma substituição drop-in compatível conhecida? Ele está integrado ao KOA e me dá problemas de fluxo

Como foi mencionado no início da edição, tenho trabalhado em outra biblioteca que agora prefiro usar chamada bent .

Por um tempo bent não foi projetado para funcionar no navegador. Como a API está bastante estável agora, passei algum tempo escrevendo uma versão do navegador em cima de fetch . Em vez de tentar navegar na versão do Node.js, a versão do navegador é seu próprio ponto de entrada no package.json.

Então, ya, bent tem suporte para navegador agora e é muito bom:

• zero dependências ou polyfills (totalmente construído em busca e ArrayBuffer, portanto, sem buffer ou polyfill de fluxo e sem deps para agrupar)
• ~2K webpack bundle un-minified ou gzipped (alguém deve me informar o que é isso depois de seus minifiers e compressores preferidos).
• Todos os testes estão passando no headless chrome, que tem 100% de cobertura na versão Node.js (ainda não tem uma ótima maneira de fazer testes automatizados de cobertura do navegador)

Isso é ótimo @mikeal

@csantanapr obrigado! :)

axios pode travar seu serviço de nó: https://github.com/axios/axios/issues/1804

Para mim, as principais preocupações são:

• Funciona com configuração mínima no meu ambiente corporativo? (fatores contribuintes: proxies corporativos são HTTP para destinos HTTP e HTTPS, nem todos os proxies tratam todos os certificados corretamente, da mesma maneira, ...)
  
  
  
  • Este particularmente me impediu de desligar o Request há um ano ou mais.
  
  
• Ele suporta streaming, para aqueles casos em que eu preciso, digamos, uploads/downloads de arquivos proxy?

Depois disso, não me importo com a aparência da interface, desde que as operações mais comuns sejam convenientes. Também não estou muito preocupado com o tamanho do lado do servidor, embora isso seja importante se você quiser reutilizar a mesma biblioteca em ambas as extremidades.

EDIT: Yeeeaaaah não posso dizer exatamente que eu culpo você aí.

EDIT 2: Acho que vou dar uma olhada em node-libcurl .

@joedski ya, o material do proxy não é amplamente suportado fora da solicitação. E TBH, dada a quantidade de trabalho que levou para fazer isso funcionar e apoiá-lo, não estou surpreso que ninguém queira fazer isso, inclusive eu ;) Eu fiz isso uma vez e não estou exatamente pulando para escrever de novo para torto 🤷🏽‍♀️

Finalmente, comecei a usar a biblioteca node-libcurl para fazer solicitações de nodejs. Porque ele usa a biblioteca curl nativa, que é muito madura e testada por anos em produção. Funciona perfeitamente com todos os tipos de proxies, redirecionamentos e possui interfaces de promessa e fluxo.

teeny-request (> 1 milhão de downloads semanais)

Substituição drop-in a pedido, mas muito menor - e com menos opções. Usa node-fetch sob o capô. Coloque-o onde você usaria request .

node-fetch está sendo reportado incorretamente e apenas a versão "browser" é reportada (derrotando o ponto de uma lista _Node.js_). Isto é o que parece ser medido erroneamente:

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

Em vez disso, qualquer um deles deve ser medido:

• 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

Eles estão todos em torno de ~ 40kb

unfetch também é informado incorretamente:

• A página inicial diz que "O uso no Node.JS é tratado por isomorphic-unfetch", portanto, deve relatar a combinação de ambos.
• isomorphic-unfetch usa node-fetch ( code , docs ) para Node.js, então seu tamanho relatado deve ser pelo menos o de node-fetch (veja meu comentário anterior).

Já que foi tão falado, devo falar um pouco sobre minha experiência com node-fetch .

Em primeiro lugar, é uma grande conquista. A quantidade de código e esforço de engenharia que foi investido nele é muito maior do que o que já pedimos. fetch parece uma API pequena e acho que as pessoas assumem que o esforço para fornecer uma API compatível em Node.js é nominal, mas na verdade não é.

Como resultado, a base de código é enorme. É uma dependência considerável no Node.js, que você provavelmente não verá em pacotes de navegadores, mas não é como se o tamanho da dependência não fosse um problema no Node.js, principalmente em ambientes sem servidor.

node-fetch é indispensável na hora de testar porque faz todo o trabalho de emular totalmente as APIs do navegador, mas se você estiver usando em um aplicativo, mesmo que esteja sendo executado em Node.js e no navegador, é apenas muito código e muita indireção para valer a pena.

IMO, a abordagem correta neste momento para uma biblioteca que deseja ser um cliente http tanto no Node.js quanto nos navegadores é implementar uma API uniforme com uma implementação dividida usando fetch no navegador e require(‘http’) em Node.js. Aplicativos e clientes http não devem segmentar fetch ou require(‘http’) diretamente e não devem depender da emulação dessas APIs em nenhum dos lados. Na verdade, isso é muito mais fácil do que você imagina, como você pode ver na implementação de bent que é incrivelmente pequena https://github.com/mikeal/bent/tree/master/src

@mikeal estou tendo dificuldade em fazer quadratura

Como resultado, a base de código é enorme. É uma dependência considerável no Node.js, que você provavelmente não verá em pacotes de navegadores, mas não é como se o tamanho da dependência não fosse um problema no Node.js, principalmente em ambientes sem servidor.

com o tamanho do pacote de 0,4 kB listado no OP, qual é a menor de todas as alternativas dadas?

@domenic a complexidade de emular as APIs do navegador é o principal problema, é muito código desnecessário e indireção ao tentar depurar. Você tem o Blob API , você tem muita organização para o body , você tem quase 400 linhas de header marshalling , e isso nem é olhar para a API real que é exposta.

Como eu disse, é impressionante, mas também é apenas uma tonelada de código conciso, inteligente e, em última análise, desnecessário se você quiser fazer qualquer coisa , exceto emular a API fetch .

@mikeal você nem mencionou que há uma tonelada a mais de código necessária para que o node-fetch seja 100% compatível com a API de busca: ele não suporta fluxos legíveis e graváveis ​​de what-wg (algo que você precisa ao emular ambientes como os Trabalhadores da Cloudflare.

Hmm, eu ainda não entendo muito bem como quadrado "uma tonelada" de código "ultimamente desnecessário" com "0,4 kB, menos do que qualquer outra entrada na mesa e 0,25x o tamanho do dobrado " (que é supostamente "o abordagem" e "incrivelmente pequeno").

@domenic você está comparando o tamanho do pacote do navegador? Estou falando sobre a complexidade de depurá-los no Node.js. No navegador, eu esperaria que a maior parte do código node-fetch fosse inexistente, então realmente não entendo o que você está comparando.

Estou comparando o valor no OP; Não tenho certeza de como isso é medido. Talvez não seja medido corretamente, o que seria uma boa informação para atualizar o OP!

@domenic ah sim, esses são todos os tamanhos de pacotes de navegadores e, como o post é bastante antigo, muitos deles podem estar desatualizados, embora o valor de bent ainda esteja próximo o suficiente.

@root/request - uma substituição drop-in 80/20 escrita em 500 LoC e dependências ZERO:

Criado e testado em relação ao comportamento de request.js, de propósito.

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

Olá a todos! Estou fazendo uma pequena pesquisa para encontrar um substituto digno de um pedido para meus projetos. Por enquanto, é isso que eu montei: https://github.com/emanuelcasco/http-packages-benchmark

Recomendações e opiniões são bem-vindas, claro!

Às request agora está oficialmente obsoleto, eu não poderia enfatizar mais a importância de propor oficialmente postman-request como um substituto completo para request , e possivelmente @root/request para aqueles que precisam apenas de um subconjunto limitado de request e não se importam com isso, por exemplo. fluxos.

Isso permite que qualquer mantenedor de pacote elimine request e se livre da mensagem de descontinuação irritante sem gastar mais do que alguns minutos de tempo de desenvolvimento com esse problema e sem precisar refatorar toda a biblioteca ou aplicativo. Levei algum tempo e frustração para descobrir até mesmo que essas substituições imediatas existem.

E sim, estou ciente de que apenas "depreciação" não quebra nada. Sim, tecnicamente todos ainda podem usar request e possivelmente continuar a usá-lo por talvez até décadas vindouras. Não é para isso que a depreciação deve ser usada, no entanto. A depreciação deve agir como um chamado à ação, como um "período de graça" para as pessoas atualizarem seu código até que alguém em algum lugar decida puxar um plugue.

Eu realmente odeio quando "reprovação" é usada apenas para marcar "fim do suporte" ou "fim da manutenção", como parece ser o caso aqui. Mas eu ficaria muito menos incomodado em comprar isso, se houvesse uma substituição completa de recursos com suporte oficial e ativamente mantida como postman-request .

Aliás, alguém já pensou em entregar a manutenção desse pacote para a equipe do Postman? Em vez de depreciar request , por que não propor para eles portar postman-request para request e deixá-los se tornarem os novos mantenedores oficiais?

Desculpe promover minha própria pequena biblioteca aqui

Projetado para ser usado apenas em 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);

Descobri que o Wretch é a melhor opção se você estiver construindo SPAs modernos datilografados, dado que está escrito em TS para começar. É efetivamente igual ao Axios e suporta middleware adicional . Eu acho que a API é um pouco melhor em alguns lugares em comparação com Ky também.

Qualquer um destes suporte http2?

@sakalys got tem suporte HTTP2 experimental, que será integrado e estável na próxima versão principal (em breve).

perto da queda na substituição?

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

Muito triste ver esta biblioteca sendo obsoleta. Eu gosto de axios, mas para alguns propósitos, o pedido foi minha primeira escolha.

Qualquer um desses tempos de solicitação de suporte? Como o tempo para o primeiro byte, atraso de rede e assim por diante?
Estou usando a biblioteca de solicitação para um projeto e o tempo é crucial para isso.

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

Temos uma boa comparação entre got , request , node-fetch , axios e superagent no readme got : https://github.com/sindresorhus/got#comparison
_(PR bem-vindo se você encontrar alguma imprecisão. Tentamos mantê-lo o mais neutro possível)_

Got também tem um guia de migração para migrar de request : https://github.com/sindresorhus/got/blob/master/migration-guides.md

O guia de migração do Got para migrar de request foi _moved_ para:
https://github.com/sindresorhus/got/blob/master/documentation/migration-guides.md

Posso sugerir adicionar postman-request? Vou testar este no meu próximo projeto. De qualquer forma, isso é o que é dito sobre isso na documentação ...

Este é um fork do excelente módulo de solicitação, que é usado dentro do Postman Runtime. Ele contém algumas correções de bugs que não são corrigidas na solicitação.

Redaxios é como 800 bytes usando busca nativa https://github.com/developit/redaxios

Poxa!! Eu estava descobrindo isso a partir de 3 horas, verifiquei meu código várias vezes. E me deu erro 404, fiquei frustrado. Muito obrigado. Acho que vou com Fetch.

https://www.npmjs.com/package/teeny-request é outra opção, usada pelas APIs do Google.

Como pedido, mas muito menor - e com menos opções. Usa node-fetch sob o capô. Coloque-o onde você usaria request. Melhora o tempo de carregamento e análise dos módulos.

O que seria melhor node-fetch ou a versão bifurcada de requests que agora é mantida pelo PostMan. Acabei de começar minha jornada no Node, então exijo algo simples.

o tempo limite do axios parece nunca ser corrigido👎🏿

Fiquei muito surpreso por não ver Phin aqui.

https://github.com/ethanent/phin

Que tal url-request ?

https://github.com/Debdut/Url

Que tal url-request ?

https://github.com/Debdut/Url

Ainda um pouco jovem (1 dia!) e (assim) carece de alguns recursos, mas parece promissor - vai assistir de perto.

@cjk obrigado pelo feedback, quais recursos você vai gostar? Se puder ser mais específico.

Q rápido. Qual é a vantagem de usar essas bibliotecas em vez de nodejs nativos http ?

@cgarrovillo Código Pequeno => Mais Impacto

tente url-request , basta olhar para o conjunto de recursos e possibilidades 🤟

@cjk obrigado pelo feedback, quais recursos você vai gostar? Se puder ser mais específico.

@Debdut Estou pensando em recursos como:

1. Autenticação
2. HTTP2
3. Suporte de proxy
4. Compressão
5. Tratamento de tempo limite
6. ganchos personalizados
7. Requisitar cancelamento

Não é óbvio nos documentos de url-request quais deles são suportados e como.

No entanto, gostei dos muitos exemplos que você fornece!

Basta continuar usando o pedido até que ele pare de funcionar.

Em angular rxjs e observável são excelentes

Qualquer lib tem cookie jar como request?

Testando a biblioteca HTTP obtida com o nó vermelho. ✋

• npm instalado
• adicionado ao contexto
• Agora no editor de fluxo, importei _got_ na minha função js

Resultados
Funciona bem ao fazer solicitações HTTP. (feito um único teste).
FALHA ❌ ao fazer solicitações HTTPS. Eu obtive :
RequestError: connect ECONNREFUSED 127.0.0.1:443

No começo eu pensei que isso era algo relacionado ao env node-red. Mais tarde, descobri que este é um problema aberto no repositório obtido : https://github.com/sindresorhus/got/issues/1414. 👎
E, na minha opinião, é motivo suficiente para optar por _axios_. ✅
Só queria que você soubesse.

@damdauvaotran Qualquer lib tem cookie jar como request?

Consulte got.js, o guia de migração .

Por que gaxios não é mencionado?

FWIW, aqui está um link de tendências do NPM que compara todos os projetos mencionados no topo. Embora não seja o único fator envolvido na decisão, a popularidade é muito importante para nós e para a maioria dos projetos.
No momento da redação deste artigo, node-fetch é a alternativa mais popular.

Interessante @ericsnap ... node-fetch e axios são o primeiro e o terceiro (quase o segundo) em popularidade, respectivamente.

E observo o seguinte slogan dos documentos do gaxios :

Um cliente de solicitação HTTP que fornece uma interface tipo axios sobre a busca de nó

Então gaxios combina duas das bibliotecas mais populares. Estou convertendo para gaxios e é super divertido de usar.

busca de nó / axios

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

Depois de revisar um monte de alternativas de solicitação atuais, eu mergulhei @sindresorhus em got. Levei cerca de um dia para me acostumar com a API (os documentos têm sido bastante bons). Eu experimentei uma redução significativa no LoC devido a extend e configurando tanto em um só lugar, então os pontos de chamada e o tratamento de erros geralmente são apenas um punhado de LoC. Parece muito mais escorregadio do que a dança pedido, pedido-promessa, pedido-promessa-nativo. Um grande conjunto de recursos também. Ótimo trabalho e muito obrigado @sindresorhus!

Eu não estava ansioso pela migração, mas me sinto muito mais limpo agora.