我应该为新项目使用“请求”模块吗？

Question

该“请求”模块一直Node.js的经过较长时间的标准 他们最近弃用了该库。

我正在开始一个新项目，并正在寻找进行网络连接的最佳解决方案。我开始使用原生的“https”模块，但遇到了一个又一个问题。使用该request模块似乎很容易并且工作得很好。还有许多其他库可以替换该request模块。

一般来说，您应该尽可能避免使用已弃用的库。但是这个经验法则在这里适用吗？

使用“请求”模块开始一个新项目是不是很糟糕？如果是，新标准是什么？

Answer 1

我个人不会使用该request()库开始一个新项目，除非它具有我绝对需要的其他库所没有的功能，或者除非我需要另一个依赖于该request()模块本身的模块。

当我有选择的自由时，我将got()用于新项目。从备选方案列表中进行选择是个人决定，因此您只需评估它们各自具有的界面类型以及它们具有的功能。对于我通常使用这种类型的库所做的事情，got()看起来简单而干净，从头开始构建 Promise，满足我的需求，我使用它没有任何问题。

Axios、node-fetch和superagent 的优势在于您可以在 node.js 和浏览器中使用类似的界面。所有这些都很受欢迎并被广泛使用。

我尝试了Bent，但没有点击它的编程界面。

我个人更愿意使用具有明确目标的库，以继续随着语言的新发展、nodejs 库的新发展以及随着时间的推移添加新功能而发展，而不是使用表示不会添加新功能的库。

我也喜欢使用一个从核心内置 Promise 支持的库，而不是仅作为包装器添加，因为我现在使用 Promise 进行所有异步编程。

检查替代方案的其他一些资源：

功能对比图（作者编写got()）

从请求迁移到 got()

而且，如果您想了解request()库为何进入维护模式，请阅读此处。

简而言之，这是一个旧架构，大量功能粘在侧面，但由于依赖于它的模块太多，他们无法真正打破 API 来修复或解决问题。而且，由于它如此受欢迎，它阻碍了设计更简洁界面的竞争解决方案的成功。因此，决定让以更现代的方式设计的替代方案继续前进，request()并将进入维护模式以继续支持依赖它的其他模块，但不会尝试演变成更现代的界面。