時々node.jsも行うフロントエンドに焦点を当てた人として、axiosは私の行き先です。
FacebookのEasyAPIは、ブラウザーとノードで機能しますか？ 終わり

@mikealとの最近の議論によると、私はBentを試してみました。 しばらくの間リクエストを使用していたNode.js開発者として、bentは間違いなく簡単な移行でした-強くお勧めします💖

@reconbot got 、 needle 、 urllibを追加することをお勧めします。

さて、ここで私自身の小さなライブラリを宣伝するのはちょっと間違っているように感じますが、それが問題の目標なので、ここにあります： request-composeは機能的で、promise、streams、および他の便利なオプション。そのほとんどは、リクエストで見つかったものに非常に近いものです。

それについての記事も書きました。 一般的な考え方は、誰もが自分のニーズに合わせて特別に調整された自分のHTTPクライアントを作成することを奨励されているということです。

バンドルサイズについてはわかりませんが、このクライアントはブラウザで使用するように設計されていませんが、かなり小さいはずです。

次の列をテーブルに追加するとよい場合があります。

• Githubの星の数（はい、これがライブラリを選択するときの唯一の要因ではないことはすでに知っています）
• npmダウンロードの数（おそらく毎週、npm Webサイトと同じ統計、そしてはい、これがlibを選択するときの唯一の要因ではないことを私はすでに知っています）

これらの数値を並べると、一部のライブラリには毎週数千の星と数百万のダウンロードがありますが、他のライブラリには数百があります。

私の2セント、無視して先に進んでも大丈夫です。コメントを修正したり異議を唱えたりする必要はありません。

@csantanapr同意します。機能セットも比較する価値があるかもしれません。 プロキシサポート、キャッシュサポート、認証機能など。リクエストの特定の機能を使用していて、それを他の場所で見つける必要がある場合は、それについて話す良い機会です。

axiosは、特にフロントエンダーとして私の投票を得ます。

一見の価値： ky （フロントエンド）とky-universal （同形）

Axiosユーザーはこちら。 そうすれば、ブラウザやnodejs（サーバーまたはサーバーレスで実行）などの環境に関係なく、すべてのチームが同じライブラリを使用できます。 非常によく維持されており、すべての人々がそれを愛しています。

got readmeのgot 、 request 、 node-fetch 、 axios 、およびsuperagentの間の良い比較があります： https ：//github.com/sindresorhus/got#comparison
（不正確な点があれば、PRを歓迎します。可能な限り中立に保つように努めました）

requestから移行するための移行ガイドもあります： https ：//github.com/sindresorhus/got/blob/master/migration-guides.md

私にとって、私はフェッチAPIのラッパーを実行する傾向があるので、ノードフェッチが私のgotoです。 ネガティブな側面にもかかわらず、私は通常それをノードのglobal.fetchにロードするので、ブラウザーの場合と同じように（古いブラウザーのポリフィルを介して）常に利用可能であると信頼できます。 isomorphic-fetchを使用することもできます。これは、ノードのノードフェッチのラッパーであり、ブラウザーでのフェッチポリフィル（または既に使用可能なフェッチ）です。 従来のブラウザーをサポートする必要がないため、グローバルを使用し、ノードで使用するグローバルを確立します。

ねえ、レック（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でフェッチをラップします。 まあ、それは好みの問題だと思いますが、ブラウザのデファクトスタンダードであるという理由だけでフェッチAPIが優れていることを意味するのは間違っています。 両側で同形にする方がノイズが少ないことはわかっていますが、それでも改善にはなりません。

@mikeal自身によるr2があります。 requestの精神的な後継者となることを目的としています。 Promise APIがあり、16kb圧縮されています。

Axiosはブラウザで問題なく動作する可能性がありますが、Node.jsでの経験ではありません。 また、それがもう積極的に維持されているかどうかはわかりません。

@ kreig303 axiosの内部を調べていないので、気づいていませんでした。 現在、通常のXHRに基づいているようです。これは、クライアントとサーバーの両方の要求に対するソリューションであるため、理にかなっています。 私は単に、axiosがかなり機能が豊富であることを意味し、リクエストの代わりのような基本モジュールとしてもう少し骨の折れるものを検討し、必要に応じて他のより機能が豊富なライブラリをその上に構築する必要があります。 クライアントとサーバーの両方で一貫性のあるAPIを使用するために（基本的にaxiosであるXHRのように）、フェッチAPIをミラーリングするものを選択しました。これは、XHRの論理的な後継であるためです。 より優れたAPIラッパーが必要な場合は、それをラップして、その最適なAPIを使用して別のライブラリをリリースする機会がたくさんありますが、可能な限り、クライアントとサーバー間の機能とAPIの同等性が必要です。

さて、私たちが要求している問題の1つは、機能が多すぎることと、内部と見なされているものでさえ、公開されている状態が多すぎることです。 非常に多くの機能を備えていることは、呪いと祝福の両方です。 それがとても人気がある理由であり、それが最初だったので、それは祝福です。 コードベースをクリーンでわかりやすく、一般的にエキサイティングなものに保つための多大な努力がなければ、プロジェクトは最終的には消滅するので、それは呪いです。 そして、それはリクエストの問題でもありません。それは、常に自分のレイヤーから何かを出したいというユーザー自身の視点であり、代わりに別の場所のブランケットの下に置きます。

まあ、私はアクシオスが同じ信仰を持っていると思います..

したがって、代わりに私たち全員ができることは、ホイールがどのように機能するかを理解するために少なくともある程度の努力を払い、次に、手元にある個々のタスクを検討し、どのホイールが最適かを確認することです。

@ofrobotsは、このような一般的に使用されているライブラリのスクリーンショットを少し選択したものです。 これが私のものです：

FWIWそれをバックエンドライブラリとして使用したかどうかは思い出せないので、私はあなたの主張を検証する立場にありません（あなたがそれをカバーしなかった独特のユースケースを持っていない限り）。

@Velveeta私はあなたがこれでどこに行くのかわかります、私はメタライブラリが行く方法であるかどうかだけわかりません。

フロントエンドからの私の投票はaxiosです。 小さく、安定していて、予測可能です。

私は個人的にFEプロジェクトとBEプロジェクトの両方にwretchを使用しています。これは主にAPIが非常に直感的だからです。

フェッチのラッパー-ノードフェッチでもうまく機能します。

fetch APIに加えてaxiosのような体験を求めている人のために、$ gaxiosがあります。 これはGoogleの開発者によって構築され、現在Google APIのNode.jsクライアントのすべてのHTTPインタラクションを強化しているため、バトルテストされて積極的に使用されていると考えるのは安全だと思われます。

（👋@ JustinBeckwithで）

ねえ、レック（https://www.npmjs.com/package/wreck）は私が使っているものです

また、hapijsフレームワークの基盤となるhttpクライアントでもあります。 実装は非常にクリーンに起動できます。

@mikeal自身によるr2があります。 requestの精神的な後継者となることを目的としています。 Promise APIがあり、16kb圧縮されています。

そのライブラリは維持されません。 同様のAPIが必要な場合は、 kyをお勧めします。これは、最小化およびgzip圧縮され、 gotと同じユーザーによって維持されます。

Axiosはブラウザで問題なく動作する可能性がありますが、Node.jsでの経験ではありません。 また、それがもう積極的に維持されているかどうかはわかりません。

私はNodeでaxiosを非常に満足して使用しています。 主にラムダで、主に機能が豊富でありながら、クレイジーな依存関係チェーンが付属していないためです。 @ofrobots Nodeでの経験は何ですか？

時々ノードjsも行うフロントエンドに焦点を当てた人として、公理は私の行き先です。 FacebookのEasyAPIは、ブラウザーとノードで機能しますか？ 終わり

Facebookだとは知らなかった？ しかし、はい、これはすべてのAPIアクセス用の私のgotoライブラリです。

このライブラリtinkoff-requesthttps://github.com/TinkoffCreditSystems/tinkoff-requestを使用します。 小さく、ブラウザとサーバーで動作し、プラグインの概念に基づいて構築されています。 ライブラリは、複数のタイプの複雑なキャッシュを同時に使用できるようにするために作成されました。

Microsoftのtyped-rest-clientを使用した人はいますか？ TypeScriptで書かれた手入れの行き届いたパッケージのようです（私にとっては大きなプラスです）。

これには、 wreck （ hapiエコシステムから）を含める必要があります

私は最近https://github.com/grantila/fetch-h2を使用して大成功を収めています

現在、互換性のある既知のドロップイン代替品はありますか？ それはKOAに統合されており、私にストリームトラブルを与えています

問題の冒頭で述べたように、私は現在使用することを好むbentという別のライブラリに取り組んでいます。

しばらくの間、 bentはブラウザで動作するように設計されていません。 APIはかなり安定しているので、 fetchの上にブラウザバージョンを書くのに少し時間を費やしました。 Node.jsバージョンをブラウザー化しようとする代わりに、ブラウザーバージョンはpackage.json内の独自のエントリポイントです。

つまり、 bentは現在ブラウザをサポートしており、非常に優れています。

• 依存関係またはポリフィルがゼロ（完全にフェッチとArrayBufferに基づいて構築されているため、バッファーまたはストリームのポリフィルとバンドルするdepsはありません）
• 〜2Kのwebpackバンドルは、縮小されていないか、gzipで圧縮されています（好みのミニファイアとコンプレッサーの後で、これが何であるかを誰かに知らせてください）。
• すべてのテストは、Node.jsバージョンで100％のカバレッジを持つヘッドレスクロームに合格しています（自動化されたブラウザーカバレッジテストを実行するための優れた方法はまだありません）

これは素晴らしい@mikeal

@csantanaprありがとう！ :)

axiosはノードサービスをクラッシュさせる可能性があります： https ：//github.com/axios/axios/issues/1804

私にとって、最大の懸念事項は次のとおりです。

• 私の企業環境では最小限の構成で動作しますか？ （要因：企業プロキシはHTTPターゲットとHTTPSターゲットの両方でHTTPであり、すべてのプロキシが同じ方法ですべての証明書を正しく処理するわけではありません...）
  
  
  
  • これは特に私が1年かそこら前にリクエストをオフにするのを止めました。
  
  
• たとえば、プロキシファイルのアップロード/ダウンロードが必要な場合に備えて、ストリーミングをサポートしていますか？

その後、最も一般的な操作が便利である限り、インターフェイスがどのように見えるかは気にしません。 サーバー側のサイズについてもあまり気にしませんが、両端で同じライブラリを再利用する場合は重要です。

編集：Yeeeaaaahは私がそこであなたを責めていると正確に言うことはできません。

編集2： node-libcurlを見てみようと思います。

@joedski ya、プロキシはリクエスト以外では広くサポートされていません。 そしてTBH、それを機能させてそれをサポートするのにかかった仕事の量を考えると、私を含めて誰もそれをやりたくないのは驚きではありません;）私は一度それをしました、そして私は正確に書くためにジャンプしていません曲がった場合はもう一度🤷🏽‍♀️

最後に、nodejsからリクエストを行うためにnode-libcurlライブラリを使い始めました。 ネイティブのcurlライブラリを使用しているため、非常に成熟しており、何年にもわたって本番環境でテストされています。 あらゆる種類のプロキシ、リダイレクトで問題なく動作し、promise＆streamインターフェースを備えています。

teeny-request （> 1mioの毎週のダウンロード）

リクエストのドロップイン交換ですが、はるかに小さく、オプションも少なくなっています。 内部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はNode.jsにnode-fetch（ code 、 docs ）を使用するため、報告されるサイズは少なくともnode-fetchのサイズである必要があります（私の前のコメントを参照）。

たくさん取り上げられてきたので、 node-fetchでの私の経験について少しお話ししたいと思います。

まず第一に、それはかなりの成果です。 それに費やされたコードとエンジニアリングの努力の量は、私たちがこれまでに要求したものよりもはるかに大きいです。 fetchは小さなAPIのように見え、Node.jsで互換性のあるAPIを提供するための努力は名目上のものだと思われていると思いますが、実際にはそうではありません。

その結果、コードベースは大規模になります。 これはNode.jsのかなりの依存関係であり、ブラウザーバンドルではまったく見られない可能性がありますが、特にサーバーレス環境では、依存関係のサイズがNode.jsで問題にならないわけではありません。

node-fetchは、ブラウザーのAPIを完全にエミュレートするすべての作業を実行するため、テストには不可欠ですが、アプリケーションで使用している場合は、Node.jsやブラウザーで実行されている場合でもそれはコードが多すぎて、間接参照が多すぎて価値がありません。

IMO、Node.jsとブラウザの両方でhttpクライアントになりたいライブラリの現時点での正しいアプローチは、ブラウザでfetchとrequire(‘http’)を使用して分割実装で統一されたAPIを実装することです。 Node.jsのfetchまたはrequire(‘http’)を直接ターゲットにしないでください。また、どちらの側でもこれらのAPIをエミュレートすることに依存しないでください。 信じられないほど小さいhttps://github.com/mikeal/bent/tree/master/srcであるbentの実装でわかるように、これは実際にはあなたが思っているよりもはるかに簡単です。

@mikeal二乗するのに苦労しています

その結果、コードベースは大規模になります。 これはNode.jsのかなりの依存関係であり、ブラウザーバンドルではまったく見られない可能性がありますが、特にサーバーレス環境では、依存関係のサイズがNode.jsで問題にならないわけではありません。

OPにリストされている0.4kBのバンドルサイズで、これは与えられたすべての選択肢の中で最小ですか？

@domenicブラウザAPIのエミュレートの複雑さが主な問題であり、デバッグしようとするときに多くの不要なコードと間接参照が発生します。 あなたはBlob APIを持っています、あなたはbodyのためにたくさんのマーシャリングを持っています、あなたはheader marshallingのほぼ400行を持っています、そしてそれは見ていません公開される実際のAPI。

私が言ったように、それは印象的ですが、 fetch APIをエミュレートする以外のことをしたいのであれば、それは非常に簡潔で巧妙で、最終的には不要なコードでもあります。

@mikealノードフェッチがフェッチAPIと100％互換性を持つために必要なコードが1トン多いことについても言及していません：what-wg（環境をエミュレートするときに必要なもの）からの読み取りおよび書き込み可能なストリームをサポートしていませんCloudflareワーカーのように。

うーん、「最終的に不要な」コードの「トン」を「0.4 kB、テーブル上の他のすべてのエントリよりも小さく、曲がったサイズの0.25倍」（おそらく「右」）で二乗する方法がまだよくわかりません。アプローチ」と「信じられないほど小さい」）。

@domenicは、ブラウザのバンドルサイズを比較していますか？ Node.jsでこれらをデバッグすることの複雑さについて話しています。 ブラウザでは、 node-fetchコードのほとんどが存在しないと予想されるため、何を比較しているのかよくわかりません。

OPの値を比較しています。 それがどのように測定されるのかわかりません。 おそらくそれは正しく測定されていないので、OPを更新するための良い情報になるでしょう！

@domenicああ、そうです、これらはすべてブラウザバンドルのサイズです。投稿はかなり古いため、 bentの数値はまだ十分に近いものの、それらの多くは古くなっている可能性があります。

@ root / request -500 LoCで記述された80/20のドロップイン置換、およびゼロの依存関係：

意図的に作成され、request.jsの動作に対してテストされています。

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

皆さんこんにちは！ 私のプロジェクトに代わるリクエストに値するものを見つけるために、少し調べてみました。 今のところ、これは私がまとめたものです： https ://github.com/emanuelcasco/http-packages-benchmark

もちろん、おすすめや意見も大歓迎です！

のrequestは正式に廃止されました。 request 、場合によって@root/requestの機能を備えた完全なドロップイン代替品として、 postman-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);

そもそもTSで書かれていることを考えると、最新のタイプスクリプトSPAを構築している場合は、 Wretchが最適なオプションであることがわかりました。 事実上Axiosと同等の機能であり、追加のミドルウェアをサポートします。 APIは、Kyと比較して、いくつかの場所で少し優れていると思います。

これらのいずれかがhttp2をサポートしていますか？

@sakalys gotは実験的なHTTP2サポートを備えており、これは組み込みで、次のメジャーリリース（間もなくリリース）で安定します。

交換のドロップに近い？

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

このライブラリが非推奨になるのを見るのは本当に悲しいことです。 私はアクシオスが好きですが、いくつかの目的のために、要求は私の最初の選択でした。

これらのサポートリクエストのタイミングはどれですか？ 最初のバイトまでの時間、ネットワークの遅れなど？
プロジェクトにリクエストライブラリを使用していますが、タイミングが重要です。

Googleはgaxiosを提供していますhttps://github.com/googleapis/gaxios-ノードフェッチを介したaxiosapi

got readmeのgot 、 request 、 node-fetch 、 axios 、およびsuperagentの間の良い比較があります： https ：//github.com/sindresorhus/got#comparison
_（不正確な点があれば、PRを歓迎します。可能な限り中立に保つように努めました）_

requestから移行するための移行ガイドもあります： https ：//github.com/sindresorhus/got/blob/master/migration-guides.md

requestから移動するためのGotの移行ガイドには、次のように_移動_されています。
https://github.com/sindresorhus/got/blob/master/documentation/migration-guides.md

postman-requestを追加することをお勧めしますか？ 次のプロジェクトでこれを試してみます。 とにかく、これはドキュメントでそれについて言われていることです...

これは、PostmanRuntime内で使用される優れたリクエストモジュールのフォークです。 リクエストで修正されていないいくつかのバグ修正が含まれています。

Redaxiosは、ネイティブフェッチを使用した800バイトのようなものですhttps://github.com/developit/redaxios

おやおや！ 私はこれを3時間から理解していて、コードを何度もチェックしていました。 そしてそれは私にエラー404を与えました、私はイライラしました。 どうもありがとう。 私はフェッチで行くと思います。

https://www.npmjs.com/package/teeny-requestは、GoogleAPIで使用されるもう1つのオプションです。

リクエストと同様ですが、はるかに小さく、オプションも少なくなります。 内部でノードフェッチを使用します。 リクエストを使用する場所にポップします。 モジュールのロードと解析時間を改善します。

node-fetchまたは現在PostManによって維持されているrequestsのフォークバージョンの方が良いでしょう。 Nodeジャーニーを始めたばかりなので、簡単なものが必要です。

axiosのタイムアウトは修正されていないようです👎🏿

ここにピンが見えないのはとても驚きました。

https://github.com/ethanent/phin

url-requestどうですか？

https://github.com/Debdut/Url

url-requestどうですか？

https://github.com/Debdut/Url

まだ少し若く（1日！）そして（したがって）いくつかの機能が欠けていますが、有望に見えます-注意深く見守っています。

@cjkフィードバックをありがとう、どの機能が好きですか？ もっと具体的にできれば。

クイックq。 ネイティブnodejshttpの代わりにこれらのライブラリを使用する利点は何ですか？

@cgarrovilloスモールコード=>より大きな影響

url-requestを試して、機能セットと可能性を見てください🤟

@cjkフィードバックをありがとう、どの機能が好きですか？ もっと具体的にできれば。

@Debdut私は次のような機能を考えています：

1. 認証
2. HTTP2
3. プロキシサポート
4. 圧縮
5. タイムアウト処理
6. カスタムフック
7. キャンセルをリクエストする

url-requestのドキュメントから、どれがどのようにサポートされているかは明らかではありません。

しかし、私はあなたが提供する多くの例が好きでした！

リクエストが機能しなくなるまで、リクエストを使い続けてください。

角度のあるrxjsとobservableは優れています

リクエストのようなクッキージャーを持っているライブラリはありますか？

ノードredでHTTPライブラリを取得しました。 ✋

• npmがインストールされました
• コンテキストに追加
• フローエディタで、js関数に_got_をインポートしました

結果
HTTPリクエストを実行するときに正常に機能します。 （単一のテストを行いました）。
HTTPS要求を行うときに失敗❌ 。 私が得た：
RequestError: connect ECONNREFUSED 127.0.0.1:443

最初は、これはnode-redenvに関連するものだと思いました。 後で、これはgot repoの未解決の問題であることがわかりました： https：//github.com/sindresorhus/got/issues/1414。 👎
そして私の意見では、代わりに_axios_を選択するのに十分な理由です。 ✅
ただあなたに知ってほしかった。

@damdauvaotranリクエストのようなクッキージャーを持っているライブラリはありますか？

移行ガイドのgot.jsを参照してください。

なぜgaxiosが言及されていないのですか？

FWIW、これは上部に記載されているすべてのプロジェクトを比較するNPMトレンドリンクです。 決定に関与する要因はそれだけではありませんが、人気は私たちとほとんどのプロジェクトにとって非常に重要です。
この記事の執筆時点では、 node-fetchが最も人気のある代替手段です。

興味深い@ericsnap ...node-fetchとaxiosの人気は、それぞれ1番目と3番目（ほぼ2番目）です。

そして、私はgaxiosドキュメントから次のストラップラインに注意します：

ノードフェッチの上にインターフェースのようなaxiosを提供するHTTPリクエストクライアント

したがって、gaxiosは最も人気のある2つのライブラリを組み合わせたものです。 私はgaxiosに変換してきましたが、使用するのはとても楽しいです。

node-fetch / axios

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

現在のリクエストの選択肢の束を確認した後、私は思い切って@sindresorhusを取得しました。 APIに慣れるのに約1日かかりました（ドキュメントはかなり良かったです）。 extendと1つの場所での設定により、LoCが大幅に減少しました。通常、コールサイトとエラー処理はほんの一握りのLoCです。 それは、リクエスト、リクエスト-プロミス、リクエスト-プロミス-ネイティブダンスよりもはるかに滑らかに感じます。 素晴らしい機能セットもあります。 素晴らしい仕事と@sindresorhusに感謝します！

移行を楽しみにしていませんでしたが、今はとてもきれいに感じています。