远场通信服务
前言
我之所以想写这篇文章主要是之前在开发鸿小易以及调试流式传输能力的时候,都是按照学长之前的活动去沿用了之前的请求代码,再加以调整,但并没有真正理解Remote Communication Kit
和Network Kit
在HTTP请求方面的差异,所以我将借这篇文章来进行一下二者的简单对比。
简介
还是先放传送门:
Network Kit
网络服务模块就是以往我所使用的基础的网络请求模块,可以应对绝大多数的网络请求需求,但它也有着明显的缺陷。
- 不支持基地址设置:关于这一点我在之前axios的学习笔记中就提到过,绝大多数公司服务器所提供的API接口都是用同一个基地址加上后续资源路径的模式,如果公司整体更换域名,不设置基地址而是去逐一设置的话会导致难以进行升级维护和改造重构。
- 不支持设置拦截器:这一点也同样是在使用axios遇到的问题,在获取到数据后我们可以通过设置拦截器来对数据进行处理,统一对响应状态码进行判断,再提取出我们搜索需要的字段数据进行返回,而非直接整体返回,这样就可以保障代码的复用性以及可维护性。
- 不支持捕获详细的跟踪信息:在SSE模式的流式传输中我们需要对各个数据包的事件
event
字段进行解析,并依据解析结果来去进行数据的处理,这一点Network Kit
并不能做到。
Remote Communication Kit
通过远场通信服务的概述我们就可以看到,远场通信服务诞生的初衷就是为了弥补Network Kit
的不足,它可以通过设置基地址和拦截器来对网络请求进行统一的管理,同时也可以通过设置监听器来对网络请求的状态进行监听,从而实现对网络请求的统一管理和控制。
二者对比
功能分类 | 功能名称 | 功能描述 | NetWork Kit | Remote Communication Kit |
---|---|---|---|---|
基础功能 | 发送PATCH类型请求 | 以PATCH的方式请求。 | 不支持 | 支持 |
基础功能 | 设置会话中URL的基地址 | 会话中URL的基地址将自动加在URL前面,除非URL是一个绝对的URL。 | 不支持 | 支持 |
基础功能 | 取消自动重定向 | HTTP请求自动重定向。 | 不支持 | 支持 |
基础功能 | 拦截请求和响应 | 在请求后或响应前进行拦截。 | 不支持 | 支持 |
基础功能 | 取消请求 | 发送请求前取消、发送请求过程中取消、请求接收后取消。 | 不支持 | 支持 |
基础功能 | 响应缓存 | 是否使用缓存,请求时优先读取缓存。缓存跟随当前进程生效,新缓存会替换旧缓存 | 不支持 | 支持 |
基础功能 | 设置响应数据的类型 | 设置数据以何种方式返回,将要响应的数据类型可设置为string、object、arraybuffer等类型。 | 支持 | 不支持 |
基础功能 | 定义允许的HTTP响应内容的最大字节数 | 服务器成功响应时,在获取数据前校验响应内容的最大字节数。 | 支持 | 不支持 |
证书验证 | 自定义证书校验 | 自定义逻辑校验客户端和服务端的证书,判断是否可以连接。 | 不支持 | 支持 |
证书验证 | 忽略SSL校验 | 在建立SSL连接时不验证服务器端的SSL证书。 | 不支持 | 支持 |
DNS | 自定义DNS解析 | 包括自定义DNS服务器或静态DNS规则 | 不支持 | 支持 |
特有功能 | 捕获详细的跟踪信息 | 在会话中的HTTP请求期间捕获详细的跟踪信息。跟踪有助于调试、性能分析和深入了解通信过程中的数据流。 | 不支持 | 支持 |
特有功能 | 数据打点,获取HTTP请求的具体数据 | HTTP请求各阶段的定时信息。 | 不支持 | 支持 |
通过上表我们可以看到,虽然远场通信在绝大多数情况都可以满足我们的需求,但也有少部分功能如对响应类型以及最大字节数的限制是远场通信服务所不具备的,所以我们还是需要视具体情况而定,在必要的时候第三方库也是很好的解决方案。
此文章版权归XBXyftx所有,如有转载,请註明来自原作者
评论