Как парень, ориентированный на внешний интерфейс, который также время от времени занимается node.js, я выбрал axios.
Easy API от Facebook работает в браузерах и узлах? Сделанный

Согласно недавнему обсуждению с @mikeal , я попробовал. Как разработчику Node.js, который уже некоторое время использует запрос, Bent определенно был легким переходом - настоятельно рекомендуется 💖

@reconbot Возможно, вы захотите добавить got , Needle и urllib .

Что ж, мне кажется неправильным продвигать здесь мою собственную маленькую библиотеку, но, поскольку это цель проблемы, вот она: request-compose — это функциональный HTTP-клиент с нулевым уровнем обработки операций с поддержкой промисов, потоков и кучи другие полезные опции, большинство из которых очень близки к найденным в запросе.

Я тоже написал об этом статью . Общая идея заключается в том, что всем рекомендуется создавать свои собственные HTTP-клиенты, специально адаптированные к их собственным потребностям.

Что касается размера пакета, я понятия не имею, но он должен быть довольно маленьким, хотя этот клиент никогда не предназначался для использования в браузере.

Было бы неплохо добавить в таблицу следующие столбцы:

• Количество звезд в Github (да я уже знаю, что это не единственный фактор при выборе lib)
• Количество загрузок npm (может быть, еженедельно, та же статистика, что и на сайте npm, и да, я уже знаю, что это не единственный фактор при выборе библиотеки)

Если сопоставить эти цифры, некоторые библиотеки имеют тысячи звезд и миллионы загрузок в неделю, а другие - сотни.

Мои 2 цента, можно игнорировать и двигаться дальше, не нужно исправлять или оспаривать комментарий.

@csantanapr Я согласен, возможно, стоит сравнить и наборы функций. Поддержка прокси, поддержка кеша, функции аутентификации и т. д. Если вы используете определенную функцию запроса и вам нужно найти ее в другом месте, самое время поговорить об этом.

axios получает мой голос, особенно в качестве внешнего интерфейса.

Стоит посмотреть: ky (интерфейс) и ky-universal (изоморфный)

Пользователь Axios здесь. Таким образом, все наши команды могут использовать одну и ту же библиотеку независимо от среды: браузер или nodejs (работает на сервере или без сервера). Очень ухоженный, и все наши люди любят его.

У нас есть хорошее сравнение между got , request , node-fetch , axios и superagent в файле readme got : https://github.com/sindresorhus/got#comparison
(Приветствуем PR, если вы видите какие-либо неточности. Мы постарались сделать это максимально нейтральным)

У Got также есть руководство по миграции для перехода с request : https://github.com/sindresorhus/got/blob/master/migration-guides.md .

Что касается меня, я склонен делать обертки вокруг fetch api, поэтому мой выбор — node-fetch. Несмотря на негативные аспекты, я обычно загружаю его на global.fetch в узле, поэтому я могу быть уверен, что он всегда доступен, как и в браузере (через полифилл для старых браузеров). Также можно использовать isomorphic-fetch , который в значительной степени является оболочкой для узла-выборки для узла и полифила выборки (или уже доступной выборки) в браузере. Поскольку мне не нужно поддерживать устаревшие браузеры, я просто использую глобальный и устанавливаю глобальный для использования в node.

Эй, я использую Wreck (https://www.npmjs.com/package/wreck).

Я бы предпочел что-то, что имитирует API выборки на клиенте. Такие библиотеки, как axios, superagent и т. д., представляют собой абстракции более высокого уровня поверх стандартной библиотеки запросов. В качестве замены низкоуровневой библиотеки запросов я хотел бы видеть что-то, что отражает низкоуровневый эквивалент на клиенте для целей универсальной разработки js. Такие библиотеки, как axios и superagent, могут затем просто переопределить себя поверх этого, и пользователи могут продолжать их использовать, но их не следует считать основополагающими для этой цели.

@Velveeta Я посмотрел кодовую базу axios и не увидел никаких доказательств того, что она основана на «стандартной библиотеке запросов более низкого уровня». Расскажите, пожалуйста, как вы пришли к такому выводу?

Сравнение @sindresorhus , безусловно, лучший подход, чем мой список выше. https://github.com/sindresorhus/got#comparison

node-fetch/isomorphic-fetch — это подходящий строительный блок низкого уровня для большинства клиентов. Я бы хотел увидеть прокладку запроса на основе выборки.

Я бы в любой день обернул выборку более удобным API. Что ж, я думаю, это просто вопрос предпочтений, но предполагать, что fetch API великолепен только потому, что он является стандартом де-факто в браузерах, просто неправильно. Я знаю, что меньше шума, если он изоморфен с обеих сторон, но это не делает его лучше.

Есть r2 от самого @mikeal . Он должен стать духовным преемником request . Он имеет API-интерфейс Promise и сжат до 16 КБ.

Axios может нормально работать в браузере, но в Node.js у нас такого не было. Кроме того, я не уверен, что он активно поддерживается.

@ kreig303 kreig303 Я не заглядывал внутрь axios, поэтому не знал об этом. Похоже, в настоящее время он основан на обычных XHR, что имеет смысл, поскольку это решение как для клиентских, так и для серверных запросов. Я просто имел в виду, что axios довольно многофункциональна, и что-то более простое следует рассмотреть для фундаментального модуля, например, замены для запроса, а затем позволить другим более многофункциональным библиотекам строиться поверх этого, если они того пожелают. Я выбрал что-то, что отражает API выборки, специально для того, чтобы иметь согласованный API как на клиенте, так и на сервере (например, XHR, который лежит в основе axios), и потому что это логический преемник XHR. Если желательна более приятная оболочка API, есть много возможностей обернуть ее и выпустить другую библиотеку с этим оптимальным API, но я полностью за паритет функций и API между клиентом и сервером, где бы это ни было возможно.

Что ж, одна из проблем, которые у нас есть в запросе, — это слишком много функций и слишком много открытого состояния, даже того, которое считается внутренним. Это и проклятие, и благословение иметь так много функций. Это благословение, потому что это так популярно, и это было первым. Это проклятие, потому что без огромного количества постоянных усилий по поддержанию кодовой базы в чистоте, простоте и, как правило, с ней интересно работать, проект в конечном итоге умирает. И это даже не проблема запроса, это собственная точка зрения пользователя, который всегда хочет положить что-то из своего собственного слоя и вместо этого положить это под одеяло где-то еще.

Ну наверное у аксиосов такая же вера..

Вместо этого мы все можем приложить хотя бы некоторые усилия к пониманию того, как работает колесо, а затем попытаться продумать каждую отдельную задачу и посмотреть, какое колесо подходит лучше всего.

@ofrobots это что-то вроде выборочного снимка экрана для такой широко используемой библиотеки. Вот мой:

FWIW Я не помню, использовал ли я его в качестве серверной библиотеки, поэтому я не в состоянии проверить ваши утверждения (если только у вас не было особого варианта использования, который он не охватывал).

@Velveeta Я понимаю, к чему вы клоните, я просто не знаю, подходят ли мета-библиотеки.

Мой голос от Frontend за axios . Маленький, стабильный и предсказуемый.

Я лично использую wretch как для своих FE-, так и для BE-проектов - в основном потому, что API действительно интуитивно понятен.

Обертка вокруг выборки — хорошо работает и с выборкой узла.

Для тех, кто ищет axios -подобный опыт поверх fetch API, есть gaxios . Он был создан разработчиком из Google и в настоящее время поддерживает все HTTP-взаимодействия клиента Node.js API Google , поэтому можно с уверенностью считать его протестированным и активно используемым!

(👋 в @JustinBeckwith)

Эй, я использую Wreck (https://www.npmjs.com/package/wreck).

Это также базовый http-клиент для фреймворка hapijs. Реализация очень чистая для загрузки.

Есть r2 от самого @mikeal . Он должен стать духовным преемником request . Он имеет API-интерфейс Promise и сжат до 16 КБ.

Эта библиотека не поддерживается. Если вам нужен аналогичный API, я бы порекомендовал ky , который имеет размер ~ 1 КБ и сжат с помощью gzip и поддерживается теми же людьми, что и got .

Axios может нормально работать в браузере, но в Node.js у нас такого не было. Кроме того, я не уверен, что он активно поддерживается.

Я с большим удовольствием использую axios в Node. В основном в лямбда-выражениях и в основном потому, что он многофункциональный, но не имеет сумасшедшей цепочки зависимостей. @ofrobots , каков ваш опыт работы с Node?

Как парень, ориентированный на фронтенд, который также время от времени занимается node js, я выбрал аксиомы. Easy API от Facebook работает в браузерах и узлах? Сделанный

Я не знал, что это был Facebook? Но да, это моя библиотека goto для любого доступа к API.

Мы используем эту библиотеку tinkoff-request https://github.com/TinkoffCreditSystems/tinkoff-request. Небольшой, работает в браузере и на сервере и построен на концепции плагинов. Библиотека создавалась для возможности одновременного использования нескольких типов комплексного кэширования.

Кто-нибудь пользовался typed-rest-client от Microsoft? Похоже, хорошо поддерживаемый пакет написан на TypeScript (для меня это большой плюс).

это должно включать wreck (из экосистемы hapi )

Недавно я с большим успехом использовал https://github.com/grantila/fetch-h2 .

Есть ли в настоящее время какая-либо известная совместимая сменная замена? Он интегрирован в KOA и доставляет мне проблемы со стримом

Как упоминалось в начале выпуска, я работаю над другой библиотекой, которую сейчас предпочитаю использовать, под названием bent .

Какое-то время bent не предназначался для работы в браузере. Поскольку сейчас API довольно стабилен, я потратил некоторое время на написание браузерной версии поверх fetch . Вместо того, чтобы пытаться браузерировать версию Node.js, версия браузера является собственной точкой входа в package.json.

Итак, у bent теперь есть поддержка браузера, и это неплохо:

• отсутствие зависимостей или полифилов (полностью построено на fetch и ArrayBuffer, поэтому нет полифиллов Buffer или Stream и нет зависимостей для связывания)
• Пакет веб-пакетов ~ 2K неминифицированный или сжатый gzip (кто-то должен сообщить мне, что это такое после их предпочтительных минификаторов и компрессоров).
• Все тесты проходят в безголовом хроме, который имеет 100% покрытие в версии Node.js (по-прежнему нет отличного способа провести автоматическое тестирование покрытия браузера).

Это здорово @mikeal

@csantanapr спасибо! :)

axios может привести к сбою службы вашего узла: https://github.com/axios/axios/issues/1804 .

Для меня главными опасениями являются:

• Работает ли он с минимальной конфигурацией в моей корпоративной среде? (содействующие факторы: корпоративные прокси-серверы используют HTTP как для целей HTTP, так и для HTTPS, не все прокси-серверы правильно обрабатывают все сертификаты одинаково, ...)
  
  
  
  • Это особенно помешало мне отключить Request год назад или около того.
  
  
• Поддерживает ли он потоковую передачу в тех случаях, когда мне нужно, скажем, загружать/загружать прокси-файлы?

После этого мне все равно, как выглядит интерфейс, лишь бы самые распространенные операции были удобны. Меня также не слишком беспокоит размер на стороне сервера, хотя это важно, если вы хотите повторно использовать одну и ту же библиотеку на обоих концах.

РЕДАКТИРОВАТЬ: Yeeeaaaah не могу точно сказать, что я виню вас там.

РЕДАКТИРОВАТЬ 2: Думаю, я посмотрю на node-libcurl .

@joedski ya, прокси-материалы широко не поддерживаются за пределами запроса. И TBH, учитывая объем работы, который потребовался, чтобы заставить это работать и поддерживать его, я не удивлен, что никто не хочет это делать, включая меня;) Я сделал это однажды, и я не то чтобы подпрыгиваю, чтобы написать это опять за загиб 🤷🏽‍♀️

Наконец-то я начал использовать библиотеку node-libcurl для выполнения запросов от nodejs. Потому что он использует нативную библиотеку curl, которая очень зрелая и проверена годами в производстве. Он безупречно работает со всеми видами прокси, перенаправлениями и имеет обещания и потоковые интерфейсы.

teeny-request (> 1 млн загрузок в неделю)

Вставная замена по запросу, но гораздо меньшего размера и с меньшим количеством опций. Использует node-fetch под капотом. Вставьте его там, где вы использовали бы request .

node-fetch сообщается неправильно, и сообщается только версия «браузера» (победив точку списка _Node.js_). Это то, что кажется неправильно измеренным:

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

Вместо этого следует измерить любой из них:

• 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

Они все вокруг ~ 40kb

unfetch также сообщается неправильно:

• На домашней странице говорится , что «Использование в Node.JS обрабатывается isomorphic-unfetch», поэтому он должен сообщать о комбинации обоих.
• isomorphic-unfetch использует node-fetch ( code , docs ) для Node.js, поэтому его заявленный размер должен быть не меньше, чем у node-fetch (см. мой предыдущий комментарий).

Поскольку об этом так много говорилось, я должен немного рассказать о своем опыте работы с node-fetch .

Во-первых, это большое достижение. Объем кода и инженерных усилий, затраченных на это, намного больше, чем то, что мы когда-либо запрашивали. fetch кажется небольшим API, и я думаю, что люди считают усилия по предоставлению совместимого API в Node.js номинальными, но на самом деле это не так.

В результате кодовая база огромна. Это значительная зависимость в Node.js, которую вы, вероятно, вообще не увидите в пакетах браузера, но это не значит, что размер зависимости не является проблемой в Node.js, особенно в бессерверных средах.

node-fetch незаменим при тестировании, потому что он выполняет всю работу по полной эмуляции API браузера, но если вы используете его в приложении, даже в том, которое запускается в Node.js и в браузере, это просто слишком много кода и слишком много косвенности, чтобы оно того стоило.

IMO, правильный подход в настоящее время для библиотеки, которая хочет быть http-клиентом как в Node.js, так и в браузерах, заключается в реализации единого API с раздельной реализацией, используя fetch в браузере и require(‘http’) в Node.js. Приложения и http-клиенты не должны напрямую ориентироваться на fetch или require(‘http’) и не должны полагаться на эмуляцию этих API с обеих сторон. На самом деле это намного проще, чем вы думаете, как вы можете видеть в реализации bent , которая невероятно мала https://github.com/mikeal/bent/tree/master/src .

@mikeal мне трудно собраться

В результате кодовая база огромна. Это значительная зависимость в Node.js, которую вы, вероятно, вообще не увидите в пакетах браузера, но это не значит, что размер зависимости не является проблемой в Node.js, особенно в бессерверных средах.

с размером пакета 0,4 КБ, указанным в OP, который является наименьшим из всех приведенных вариантов?

@domenic сложность эмуляции API браузера является основной проблемой, это много ненужного кода и косвенных действий при попытке отладки. У вас есть Blob API , у вас много сортировки для body , у вас есть почти 400 строк header marshalling , и это даже не смотря на фактический API, который раскрывается.

Как я уже сказал, это впечатляет, но это также просто тонна краткого, умного и, в конечном счете, ненужного кода, если вы хотите сделать что- нибудь, кроме эмуляции API fetch .

@mikeal , вы даже не упомянули, что для того, чтобы node-fetch был на 100% совместим с API-интерфейсом fetch, требуется еще тонна кода: он не поддерживает доступные для чтения и записи потоки из what-wg (то, что вам нужно при эмуляции сред как рабочие Cloudflare.

Хм, я до сих пор не совсем понимаю, как возвести в квадрат "тонну" "совершенно ненужного" кода с "0,4 КБ, меньше, чем любая другая запись в таблице, и в 0,25 раза больше, чем размер изогнутого " (который якобы является "правильным подход» и «невероятно маленький»).

@domenic вы сравниваете размер пакета браузера? Я говорю о сложности их отладки в Node.js. В браузере я ожидаю, что большая часть кода node-fetch не будет существовать, поэтому я действительно не понимаю, что вы сравниваете.

Я сравниваю значение в OP; Я не уверен, как это измеряется. Возможно, он измерен неправильно, что было бы хорошей информацией для обновления OP!

@domenic ах да, это все размеры пакетов браузера, и, поскольку сообщение довольно старое, многие из них могут быть устаревшими, хотя цифра bent все еще достаточно близка.

@root/request — вставная замена 80/20, написанная на 500 LoC, и НУЛЕВЫЕ зависимости:

Специально создан и протестирован на поведение request.js.

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

Всем привет! Я провожу небольшое исследование, чтобы найти достойную замену запросу для моих проектов. На данный момент это то, что я собрал: https://github.com/emanuelcasco/http-packages-benchmark

Рекомендации и мнения конечно же приветствуются!

Поскольку request теперь официально объявлен устаревшим, я не могу не подчеркнуть важность официального предложения postman-request в качестве полнофункциональной замены request и, возможно, @root/request для тех, кому просто нужно ограниченное подмножество request и не заботятся, например. потоки.

Это позволяет любому мейнтейнеру пакета отказаться от request и избавиться от раздражающего сообщения об устаревании, не тратя больше нескольких минут времени разработчиков на эту проблему и не рефакторируя всю свою библиотеку или приложение. Мне потребовалось некоторое время и разочарование, чтобы понять даже, что такие заменители существуют.

И да, я знаю, что просто "устаревшее" ничего не сломает. Да, технически каждый все еще может использовать request и, возможно, продолжать использовать его, возможно, даже десятилетиями. Однако это не то, для чего предполагается использовать устаревание. Устаревание должно действовать как призыв к действию, как «льготный период» для людей, чтобы обновить свой код, пока кто-то где-нибудь не решит выдернуть вилку.

Я очень, очень ненавижу, когда «устаревание» просто используется для обозначения «окончания поддержки» или «окончания обслуживания», как, кажется, здесь. Но я бы гораздо меньше беспокоился о покупке этого, если бы существовала официально поддерживаемая И активно поддерживаемая полнофункциональная замена, такая как postman-request .

На самом деле, кто-нибудь рассматривал возможность передачи обслуживания этого пакета команде Postman? Вместо того, чтобы осуждать request , почему бы не предложить им портировать postman-request на request и позволить им стать новыми официальными сопровождающими?

Извините, что рекламирую здесь свою маленькую библиотеку

Предназначен для использования только в 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);

Я нашел Wretch лучшим вариантом, если вы создаете современные SPA машинописного текста, учитывая, что он изначально написан на TS. Функционал аналогичен Axios и поддерживает дополнительное промежуточное ПО . Я думаю, что API немного лучше в паре мест по сравнению с Ky.

Любой из них поддерживает http2?

@sakalys got имеет экспериментальную поддержку HTTP2, которая будет встроена и станет стабильной в следующем крупном выпуске (скоро выйдет).

близка к замене?

https://github.com/googleapis/teeny-запрос

Очень грустно видеть, что эта библиотека устарела. Мне нравятся аксиомы, но для некоторых целей моим первым выбором был запрос.

Любое из этих сроков запроса поддержки? Как время до первого байта, задержка сети и так далее?
Я использую библиотеку запросов для проекта, и время для него имеет решающее значение.

Google предлагает gaxios https://github.com/googleapis/gaxios — axios api поверх node-fetch

У нас есть хорошее сравнение между got , request , node-fetch , axios и superagent в файле readme got : https://github.com/sindresorhus/got#comparison
_(Приветствуем PR, если увидите какие-либо неточности. Мы постарались сохранить максимально нейтральную информацию)_

У Got также есть руководство по миграции для перехода с request : https://github.com/sindresorhus/got/blob/master/migration-guides.md .

Руководство Got по переходу с request _перенесено_ на:
https://github.com/sindresorhus/got/blob/master/documentation/migration-guides.md

Могу ли я предложить добавить postman-request? Я попробую это в своем следующем проекте. Во всяком случае, так об этом говорится в документации...

Это форк отличного модуля запросов, который используется внутри Postman Runtime. Он содержит несколько исправлений, которые не исправлены в запросе.

Redaxios похож на 800 байт с использованием встроенной выборки https://github.com/developit/redaxios

Боже!! Я понял это за 3 часа, снова и снова проверяя свой код. И это выдало мне ошибку 404, я был расстроен. Большое спасибо. Думаю, я пойду с Фетчем.

https://www.npmjs.com/package/teeny-request — еще один вариант, используемый API Google.

То же, что запрос, но намного меньше и с меньшим количеством опций. Использует node-fetch под капотом. Вставьте его там, где вы будете использовать request. Улучшает время загрузки и разбора модулей.

Что было бы лучше node-fetch или разветвленная версия requests , которую теперь поддерживает PostMan. Я только начал свое путешествие по Node, поэтому мне нужно что-то простое.

тайм-аут axios, похоже, никогда не будет исправлен 👎🏿

Я был очень удивлен, не увидев здесь Фина.

https://github.com/ethantent/phin

Как насчет url-request ?

https://github.com/Debdut/URL

Как насчет url-request ?

https://github.com/Debdut/URL

Еще немного молодой (1 день!) и (поэтому) не хватает некоторых функций, но выглядит многообещающе - будем внимательно следить.

@cjk спасибо за отзыв, какие функции вам понравятся? Если бы можно было поконкретнее.

Быстрый вопрос В чем преимущество использования этих библиотек вместо собственного http узла nodejs?

@cgarrovillo Маленький код => Больше влияния

попробуйте url-request , просто посмотрите на набор функций и возможностей 🤟

@cjk спасибо за отзыв, какие функции вам понравятся? Если бы можно было поконкретнее.

@Debdut Я думаю о таких функциях, как:

1. Аутентификация
2. HTTP2
3. Прокси-поддержка
4. Сжатие
5. Обработка тайм-аута
6. пользовательские крючки
7. Отмена запроса

Из документов url-request не очевидно, какие из них поддерживаются и как.

Тем не менее, мне понравилось множество примеров, которые вы приводите!

Просто продолжайте использовать запрос, пока он не перестанет работать.

В angular rxjs и observable отлично

У любой библиотеки есть файл cookie, похожий на запрос?

Тестирование Got HTTP-библиотеки с красным узлом. ✋

• нпм установлен
• добавлено в контекст
• Теперь в редакторе потока импортировано _got_ в мою функцию js

Результаты
Отлично работает при выполнении HTTP-запросов. (сделал один тест).
НЕУДАЧА ❌ при выполнении HTTPS-запросов. Я получил :
RequestError: connect ECONNREFUSED 127.0.0.1:443

Сначала я подумал, что это что-то связанное с node-red env. Позже обнаружил, что это открытая проблема в репозитории got : https://github.com/sindresorhus/got/issues/1414. 👎
И, на мой взгляд, это достаточная причина, чтобы вместо этого использовать _axios_. ✅
Просто хотел, чтобы вы знали.

@damdauvaotran В любой библиотеке есть файл cookie, похожий на запрос?

См. got.js, руководство по миграции .

Почему гаксиос не упоминается?

FWIW, вот ссылка на тенденции NPM , в которой сравниваются все проекты, упомянутые вверху. Хотя это не единственный фактор, влияющий на решение, популярность очень важна для нас и для большинства проектов.
На момент написания этой статьи node-fetch — самая популярная альтернатива.

Интересно @ericsnap ... node-fetch и axios занимают первое и третье (почти второе) место по популярности соответственно.

И я отмечаю следующую строчку из документации gaxios :

Клиент HTTP-запросов, который предоставляет интерфейс, подобный axios, поверх node-fetch.

Итак, gaxios объединяет две самые популярные библиотеки. Я перешел на gaxios, и им очень весело пользоваться.

выборка узла / аксиомы

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

Изучив кучу текущих альтернативных запросов, я сделал решающий шаг @sindresorhus в got. Мне потребовалось около дня, чтобы привыкнуть к API (документы были довольно хорошими). Я столкнулся со значительным сокращением LoC из-за extend и установки такого большого количества настроек в одном месте, тогда как колл-сайты и обработка ошибок обычно представляют собой лишь несколько LoC. Это кажется намного более изящным, чем танец «просьба-обещание-просьба-обещание-просьба». Также отличный набор функций. Отличная работа и большое спасибо @sindresorhus!

Я не с нетерпением ждал перехода, но теперь я чувствую себя намного чище.