NodeJs及浏览器环境,如何应对虚拟请求远程接口的需求?
发布于 作者:苏南大叔 来源:程序如此灵动~

继续fetch
或者axios
请求远程接口的话题,本文侧重于虚拟服务器端的逻辑。所有服务器端的逻辑,都放在本地执行。这种方案,主打的就是一个timeout
可控。因为在一些场景下,多久能够解析到接口的返回值,这是个非常重要的问题,需要反复测试。而传统的方案组合里面,对timeout
时间的掌控就相对不靠谱多了。

苏南大叔的“程序如此灵动”博客,记录苏南大叔的编程经验文章。测试环境:chrome@131.0.6778.70
,nodejs@20.18.0
。本文的主要内容,在以前的文章里面也有提及,这里仅仅是个再次总结梳理的文章。对于本文是模拟的get
还是post
来说,一样都一样。get
和post
请求的区别不在这里。
前文回顾
前文回顾,很多篇文章都写过使用setTimeout()
精准模拟接口返回的事情,参考:
- https://newsn.net/say/react-await.html
- https://newsn.net/say/react-defer.html
- https://newsn.net/say/react-useloaderdata.html
其核心的技术方案,除了setTimeout()
外,还包括promise
的使用,参考:
仅模拟timeout
网上最流行的方案里面,基本上都是这么写的。尽管看起来比较不严谨。但是,贵在代码简单迅速精准解决问题。适用于对【网络请求】不敏感,对【时间把控】敏感的情形。
模拟代码一,参考代码:
模拟代码二,当然,也可以再精细一点:
后续的代码(不变的部分):
模拟timeout和response
上面的方案里面,主要强调了timeout
。实际上并没有考虑网络请求需要两个.then
才能处理的问题,也就是说有较大的概率下,上线的时候除了要替换这个虚拟请求函数外,还得替换下一步处理的代码。
所以,这里本地模拟一个Response
对象。那么,一个Response
对象是什么样的呢?在上一篇文章里面曾经留了个坑。
模拟response
(不完美,待完善):
这块儿写成class MyResponse(){}
的样子,应该会更好理解一些。
模拟网络请求,代码:
处理接口返回值(相对不动的部分):
结语
本文的代码,和网络上流传的代码存在较大差异,增加了苏南大叔对response
对象的理解。如果您对苏南大叔的代码不认可,可以留言指出问题所在。更多苏南大叔的JavaScript
经验文章,请参考:


