我应该为新项目使用“请求”模块吗? [英] Should I use the 'request' module for a new project?

查看:214
本文介绍了我应该为新项目使用“请求”模块吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

请求模块是Node.js的长期标准。他们最近已弃用该库。



我正在开始一个新项目,并正在寻找进行联网的最佳解决方案。我开始使用原生 https模块,但遇到了一个又一个问题。使用 request 模块似乎很容易,并且工作正常。还有许多其他库来代替请求 code>模块。



通常来说,应尽可能避免使用不推荐使用的库。



使用请求模块启动新项目是否不好?如果是这样,什么是新标准?

解决方案

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



可以自由选择时,我使用的是 got() 用于新项目。从替代列表中进行选择是个人决定,因此您只需要评估类型它们各自具有的界面以及它们具有什么功能。对于我通常使用这种类型的库所做的事情, got()似乎简单整洁,完全由承诺构建而成,可以满足我的需求,而且我没有遇到任何问题



Axios 节点获取 superagent 的优势在于,您可以在node.js和浏览器中使用类似的界面。



我尝试了弯曲,但没有单击它的编程界面。



我个人宁愿使用具有明确目标的库,并希望随着新的发展而不断发展在该语言中,nodejs库的新开发并随着时间的推移添加了新功能,而不是一个表示不会添加新功能的库。



我还喜欢使用具有从内核内置的Promise支持的库,而不是仅作为包装器添加,因为我现在使用Promise进行所有异步编程。 / p>




在检查替代方案时还有其他资源:



功能比较表(由 got()



从请求迁移到got()






而且,如果您想阅读有关为什么 request()库进入维护模式,请阅读此处



简而言之,这是一个古老的体系结构,侧面粘贴了许多功能,但是由于有很多模块依赖于此,因此它们无法真正破坏它们的功能。修复或平滑问题的API。而且,由于它非常受欢迎,因此阻碍了设计出更简洁界面的竞争解决方案的成功。因此,决定让以更现代的方式设计的替代方案继续向前发展, request()将进入维护模式以继续提供支持其他依赖于它的模块,但不尝试演变成更现代的界面。


The 'request' module has been a long-time standard for Node.js. They have recently deprecated the library.

I am starting a new project, and looking for the best solution to do my networking. I started off using the native 'https' module, but ran into problem after problem. Using the request module seemed to be easy and work just fine. There are also many other libraries to replace the request module.

Generally speaking, you should avoid using deprecated libraries when possible. But does that rule of thumb apply here?

Is it bad to start a new project with the 'request' module? If so, what is the new standard?

解决方案

I would personally not start a new project with the request() library unless it has a feature that no other library has that I absolutely need or unless I need another module that depends upon the request() module itself.

When I have the freedom to choose, I'm using got() for new projects instead. Choosing from the list of alternatives is a personal decision so you just have to evaluate the type of interface they each have and what features they have. For what I typically do with this type of library, got() seemed simple and clean, built from the ground up with promises, meets my needs and I've had no problems using it.

Axios, node-fetch and superagent have advantages in that you can use a similar interface in both node.js and in the browser. All are popular and in wide use.

I tried bent, but didn't click with its programming interface.

I'd personally rather be using libraries that have a stated objective to continue to evolve with new developments in the language, new developments in nodejs libraries and add new features over time rather than a library that says it will not be adding new features.

I also like using a library that has promise support built-in from the core rather than added on only as a wrapper since I do all asynchronous programming with promises now.


Some other resources in examining the alternatives:

Feature comparison chart (written by the makers of got())

Migrating to got() from request


And, if you want to read about why the request() library has gone into maintenance mode, read here.

In a nutshell, it's an old architecture with tons of features glued onto the side, but because there are so many modules dependent upon it, they can't really break their API to fix or smooth things out. And, because it's so popular, it is holding back the success of competing solutions that have designed a cleaner interface. So, the decision was made to let the alternatives that have been designed in a more modern way take the mantle going forward and request() will go into maintenance mode to continue to support the other modules that are dependent upon it, but not try to evolve into a more modern interface.

这篇关于我应该为新项目使用“请求”模块吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆