作为一个专注于前端并且时不时做 node.js 的人，axios 一直是我的首选。
来自 Facebook 的 Easy API 适用于浏览器和节点？ 完毕

根据最近与@mikeal的讨论，我尝试了一下。 作为一个已经使用 request 一段时间的 Node.js 开发人员，bent 绝对是一个简单的过渡 - 强烈推荐💖

@reconbot您可能想要添加got 、 needle和urllib 。

好吧，在这里推广我自己的小库感觉有点不对，但既然这是问题的目标，那就是： request-compose是一个功能性的、0 依赖的 HTTP 客户端，支持 Promise、流和一堆其他有用的选项，其中大部分与请求中的选项非常接近。

我还写了一篇关于它的文章。 总体思路是鼓励每个人编写自己的 HTTP 客户端，专门针对自己的需求量身定制。

至于捆绑包的大小，我不知道，但它应该非常小，尽管这个客户端从未设计用于在浏览器中使用。

向表中添加以下列可能会更好：

• Github 中的星数（是的，我已经知道这不是选择库时的唯一因素）
• npm 下载次数（可能每周一次，与 npm 网站的统计数据相同，是的，我已经知道这不是选择库时的唯一因素）

当把这些数字放在一起时，一些库每周有数千颗星和数百万次下载，而其他库则有数百个。

我的 2 美分，可以忽略并继续前进，无需纠正或质疑评论。

@csantanapr我同意，比较功能集也可能值得。 代理支持，缓存支持，身份验证功能等。如果您使用请求的特定功能并且需要在其他地方找到它，这将是谈论它的好时机。

axios得到我的投票，尤其是作为前端。

值得一看： ky （前端）和ky-universal （同构）

Axios 用户在这里。 这样，无论环境如何，我们所有的团队都可以使用相同的库：浏览器或 nodejs（在服务器或无服务器中运行）。 维护得很好，我们所有的人都喜欢它。

我们在got自述文件中对 $ got 、 request 、 node-fetch 、 axios和superagent进行了很好的比较： https ://github.com/sindresorhus/got#comparison
（如果您发现任何不准确之处，欢迎公关。我们已尽量保持中立）

Got 还有一个从request迁移的迁移指南： https ://github.com/sindresorhus/got/blob/master/migration-guides.md

对我来说，我倾向于围绕 fetch api 进行包装，所以 node-fetch 是我的首选。 尽管有负面影响，我通常将它加载到节点中的global.fetch上，因此我可以依赖它始终可用，就像在浏览器中一样（通过旧浏览器的 polyfill）。 也可以使用isomorphic-fetch ，它几乎是 node-fetch 的包装器，以及浏览器中的 fetch polyfill（或已经可用的 fetch）。 由于我不必支持旧版浏览器，所以我只使用全局，并建立全局以在 node.js 中使用。

嘿，我使用的是 Wreck (https://www.npmjs.com/package/wreck)

我更喜欢模仿客户端上的 fetch api 的东西。 像 axios、superagent 等库是标准请求库之上的更高级别的抽象。 作为低级请求库的替代品，为了通用 js 开发，我希望看到一些在客户端上反映低级等价物的东西。 然后像 axios 和 superagent 这样的库可以在此基础上重新实现自己，它的用户可以继续使用它们，但这些不应该被视为此目的的基础。

@Velveeta我去查看了axios代码库，没有看到任何证据表明它基于“低级标准请求库”。 请告诉我你是怎么得出这个结论的？

@sindresorhus的比较是迄今为止比我上面的列表更好的方法。 https://github.com/sindresorhus/got#comparison

node-fetch/isomorphic-fetch是适合大多数客户的低级构建块。 我很想看到一个基于 fetch 的请求 shim。

任何一天我都会用更好的 API 来包装 fetch。 好吧，我想这只是一个偏好问题，但暗示 fetch API 很棒只是因为它是浏览器中的事实标准是错误的。 我知道让它两边同构会减少噪音，但这并没有让它变得更好。

@mikeal本人有r2 。 它旨在成为request的精神继承者。 它有一个 Promise API，压缩为 16kb。

Axios 可能在浏览器中可以正常工作，但这不是我们在 Node.js 上使用它的经验。 另外，我不确定它是否已被积极维护。

@kreig303我没有研究 axios 的内部结构，所以我没有意识到这一点。 看起来它目前基于常规 XHR，这是有道理的，因为它是客户端和服务器请求的解决方案。 我只是说 axios 的功能非常丰富，应该考虑一些更简单的东西作为基础模块，比如替换请求，然后如果他们愿意，可以让其他功能更丰富的库在此基础上构建。 我选择了一些镜像 fetch API 的东西，特别是为了在客户端和服务器上拥有一致的 API（比如作为 axios 的基础的 XHR），并且因为它是 XHR 的逻辑继承者。 如果需要更好的 API 包装器，则有很多机会来包装它并发布具有最佳 API 的另一个库，但我完全支持客户端和服务器之间的功能和 API 奇偶性，只要它可以完成。

好吧，我们要求的问题之一是功能太多，暴露状态太多，即使是被认为是内部的。 拥有这么多功能既是诅咒也是祝福。 这是一种祝福，因为这就是它如此受欢迎的原因，而且它是第一个。 这是一个诅咒，因为如果没有大量的持续努力来保持代码库的清洁、简单和令人兴奋的工作，项目最终会死掉。 这甚至不是请求的问题，而是用户自己的观点，即总是想把一些东西放在他们自己的层之外，而不是把它放在其他地方的毯子下。

好吧，我猜 axios 也有同样的信念..

因此，我们可以做的，就是至少投入一些精力来了解轮子的工作原理，然后尝试仔细考虑手头的每一项任务，看看哪个轮子最适合。

@ofrobots对于这样一个常用的库来说，这是一个选择性的截图。 这是我的：

FWIW 我不记得我是否将它用作后端库，因此我无法验证您的声明（除非您有一个未涵盖的特殊用例）。

@Velveeta我知道你要去哪里，我只是不知道元库是否是要走的路。

我来自前端的投票是axios 。 微小、稳定且可预测。

我个人在我的 FE 和 BE 项目中都使用wretch——主要是因为 API 非常直观。

fetch 的包装器 - 也适用于 node-fetch。

对于在fetch API 之上寻求类似axios体验的人们，有gaxios 。 它由 Google 的开发人员构建，目前支持Google API 的 Node.js 客户端的所有 HTTP 交互，因此认为它经过实战测试和积极使用似乎是安全的！

（👋@JustinBeckwith）

嘿，我使用的是 Wreck (https://www.npmjs.com/package/wreck)

它也是 hapijs 框架的底层 http 客户端。 该实现非常干净启动。

@mikeal本人有r2 。 它旨在成为request的精神继承者。 它有一个 Promise API，压缩为 16kb。

该库未维护。 如果你想要一个类似的 API，我会推荐ky ，它被压缩和 gzip 压缩了 ~1kb，并由与got相同的人维护。

Axios 可能在浏览器中可以正常工作，但这不是我们在 Node.js 上使用它的经验。 另外，我不确定它是否已被积极维护。

我非常满意地在 Node 中使用 axios。 主要在 lambdas 中，主要是因为它功能丰富，但没有疯狂的依赖链。 @ofrobots您在 Node 中使用它的经验是什么？

作为一个专注于前端的人，偶尔也会做 node js，axioms 一直是我的首选。 来自 Facebook 的 Easy API 适用于浏览器和节点？ 完毕

我不知道这是脸书？ 但是，是的，这是我用于所有 API 访问的 goto 库。

我们使用这个库 tinkoff-request https://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现在有了浏览器支持，而且非常好：

• 零依赖或 polyfill（完全建立在 fetch 和 ArrayBuffer 之上，因此没有 Buffer 或 Stream polyfill，也没有要捆绑的依赖项）
• ~2K webpack 包未压缩或压缩（有人应该让我知道在他们首选的压缩器和压缩器之后这是什么）。
• 所有测试都在无头 chrome 中通过，它在 Node.js 版本中具有 100% 的覆盖率（仍然没有很好的方法来进行自动浏览器覆盖率测试）

这很棒@mikeal

@csantanapr谢谢！ :)

axios 可以使您的节点服务崩溃： https ://github.com/axios/axios/issues/1804

对我来说，最担心的是：

• 它是否适用于我的公司环境中的最少配置？ （促成因素：公司代理对于 HTTP 和 HTTPS 目标都是 HTTP，并非所有代理都以相同的方式正确处理所有证书，...）
  
  
  
  • 这个特别阻止了我一年左右关闭请求。
  
  
• 对于我需要代理文件上传/下载的情况，它是否支持流式传输？

之后，我不在乎界面是什么样子，只要最常用的操作方便即可。 我也不太关心服务器端的大小，但如果你想在两端重用相同的库，这很重要。

编辑： Yeeeaaaah 不能完全说我在那里责怪你。

编辑2：我想我会看看node-libcurl 。

@joedski是的，代理的东西在请求之外没有得到广泛的支持。 TBH，考虑到让它工作和支持它所花费的工作量，我并不惊讶没有人愿意这样做，包括我；）我已经做过一次，我并没有完全跳起来写再次弯曲🤷🏽‍♀️

最后，我开始使用node-libcurl库从 nodejs 发出请求。 因为它使用了原生 curl 库，该库非常成熟并经过多年的生产测试。 它可以完美地与各种代理、重定向一起工作，并具有承诺和流接口。

极小的请求（>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 处理”，所以它应该报告两者的组合。
• 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 fetch或require(‘http’)目标，并且不应依赖于在任一端模拟这些 API。 这实际上比您想象的要容易得多，正如您在bent的实现中看到的那样，它非常小https://github.com/mikeal/bent/tree/master/src

@mikeal我很难开平方

因此，代码库非常庞大。 它在 Node.js 中是一个相当大的依赖项，您可能在浏览器包中根本看不到，但在 Node.js 中，依赖项大小并不是问题，尤其是在无服务器环境中。

使用 OP 中列出的 0.4 kB 包大小，这是所有给定替代方案中最小的？

@domenic模拟浏览器 API 的复杂性是主要问题，在尝试调试时有很多不必要的代码和间接。 你有Blob API ，你有很多编组body ，你有近 400 行header marshalling ，这甚至没有看暴露的实际 API。

就像我说的，它令人印象深刻，但如果你想做除了模拟fetch API 之外的任何事情，它也只是大量简洁、聪明且最终不必要的代码。

@mikeal ，您甚至没有提到要与 fetch API 100% 兼容 node-fetch 需要更多代码：它不支持来自 what-wg 的可读和可写流（在模拟环境时需要的东西）像 Cloudflare Workers。

嗯，我仍然不太明白如何将“一吨”“最终不必要”的代码与“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

当然欢迎提出建议和意见！

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

如果您正在构建现代 typescript SPA，我发现Wretch是最佳选择，因为它一开始是用 TS 编写的。 实际上功能等同于 Axios 并支持额外的中间件。 我认为 API 在几个地方也比 Ky 好一点。

这些都支持http2吗？

@sakalys got具有实验性 HTTP2 支持，它将在下一个主要版本（即将推出）中内置且稳定。

更换接近下降？

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

看到这个库被弃用真的很难过。 我喜欢 axios，但出于某些目的，请求是我的第一选择。

这些支持请求时间中的任何一个吗？ 比如第一个字节的时间，网络延迟等等？
我正在为一个项目使用请求库，时间对它来说至关重要。

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

我们在got自述文件中对 $ got 、 request 、 node-fetch 、 axios和superagent进行了很好的比较： https ://github.com/sindresorhus/got#comparison
_（如果您发现任何不准确之处，欢迎公关。我们已尽量保持中立）_

Got 还有一个从request迁移的迁移指南： https ://github.com/sindresorhus/got/blob/master/migration-guides.md

Got's migration guide for move from request has _moved_ to:
https://github.com/sindresorhus/got/blob/master/documentation/migration-guides.md

我可以建议添加邮递员请求吗？ 我将在我的下一个项目中尝试这个。 无论如何，这就是文档中所说的......

这是在 Postman Runtime 中使用的优秀请求模块的一个分支。 它包含一些未在请求中修复的错误修正。

Redaxios 就像 800 字节使用本机获取https://github.com/developit/redaxios

天哪！！ 我在 3 个小时后才弄清楚这一点，一次又一次地检查我的代码。 它给了我错误 404，我很沮丧。 非常感谢。 我想我会选择 Fetch。

https://www.npmjs.com/package/teeny-request是另一个选项，由 Google API 使用。

像请求一样，但要小得多 - 选项也更少。 在后台使用 node-fetch。 将其弹出到您将使用请求的位置。 改进模块的加载和解析时间。

node-fetch或现在由 PostMan 维护的requests的分叉版本会更好。 我才刚刚开始我的 Node 之旅，所以需要一些简单的东西。

axios 的超时时间似乎永远无法修复👎🏿

我很惊讶在这里没有看到 phin。

https://github.com/ethanent/phin

url-request怎么样？

https://github.com/Debdut/Url

url-request怎么样？

https://github.com/Debdut/Url

仍然有点年轻（1 天！）并且（因此）缺乏一些功能，但看起来很有希望 - 将密切关注。

@cjk感谢您的反馈，您喜欢哪些功能？ 如果你能更具体一点。

快速问。 使用这些库而不是本机 nodejs http有什么好处？

@cgarrovillo小代码 => 更多影响

试试url-request ，看看功能集和可能性🤟

@cjk感谢您的反馈，您喜欢哪些功能？ 如果你能更具体一点。

@Debdut我正在考虑以下功能：

1. 验证
2. HTTP2
3. 代理支持
4. 压缩
5. 超时处理
6. 自定义挂钩
7. 取消请求

从url-request的文档中不清楚哪些是受支持的以及如何支持的。

但是，我喜欢您提供的许多示例！

继续使用 request 直到它停止工作。

在 angular rxjs 和 observable 方面非常出色

任何库都有类似请求的cookie jar？

测试得到了带有红色节点的 HTTP 库。 ✋

• 已安装 npm
• 添加到上下文中
• 现在在流编辑器中，在我的 js 函数中导入了 _got_

结果
在进行 HTTP 请求时工作正常。 （进行了一次测试）。
失败 ❌进行 HTTPS 请求时。 我有 ：
RequestError: connect ECONNREFUSED 127.0.0.1:443

起初我认为这与 node-red env 有关。 后来发现这是got repo 中的一个未解决问题： https://github.com/sindresorhus/got/issues/1414。 👎
在我看来，选择 _axios_ 就足够了。 ✅
只是想让你知道。

@damdauvaotran任何库都有类似请求的cookie jar？

请参阅 got.js，迁移指南。

为什么没有提到gaxios ？

FWIW，这是一个 NPM 趋势链接，它比较了顶部提到的所有项目。 虽然这不是决定的唯一因素，但受欢迎程度对我们和大多数项目都非常重要。
在撰写本文时， node-fetch是最受欢迎的替代方案。

有趣的@ericsnap ... node-fetch 和 axios 分别排名第一和第三（接近第二）。

我注意到gaxios 文档中的以下标语：

一个 HTTP 请求客户端，在 node-fetch 之上提供类似 axios 的接口

所以gaxios结合了两个最流行的库。 我一直在转换为 gaxios，使用起来非常有趣。

节点获取/axios

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

在查看了一堆当前的请求替代方案之后，我已经采取了@sindresorhus的尝试。 我花了大约一天的时间来适应 API（文档已经相当不错了）。 由于extend和在一个地方设置了这么多，我经历了 LoC 的显着减少，然后调用视线和错误处理通常只有少数 LoC。 感觉比请求、请求-承诺、请求-承诺-原生舞蹈要流畅得多。 一个很棒的功能集。 伟大的工作，非常感谢@sindresorhus！

我并不期待迁移，但我现在感觉干净多了。