二十分钟封装,一个App先后台Http交互的实现

在React Native开发过程当中,几乎全部的app都须要使用到Http请求,因此fetch的封装必不可少,因为不一样app的请求参数,解析规则,token机制等彻底不同,因此在大多数App开发中,先后台Http请求的实现都是开发者本身封装的。react

封装一个先后台Http请求实现须要多久?git

可能有人回答是1小时,也有三、5小时甚至更长时间的,或者也有说先这样封装个大概,等到需求不知足的时候再改。github

花费1小时的时间不必定短,花费三、5的时间也不必定算长,具体要看先后台交互的复杂程度与开发者对交互实现的封装程度。npm

那这里咱们就引出了一个问题了,咱们一般说的app的Http请求【封装】,到底封装的是什么,咱们须要作哪些工做,能使用得app的接口请求更简单,易用且有较高的灵活性?在我看来这个“封装”主要分两个部分:json

  1. 数据交换 层面的封装,即:react-native

    • 实现先后台的互通,支持服务器要求的数据交换类型、格式等
    • 调用者能够自由设置请求的header、params等参数,程序根据不一样的设置也能保证请求能正确的发送给服务端并返回相应的结果
    • 支持超时、日志打印等一些基本功能
  2. 业务逻辑 层面的封装,即:
    • 入参:公共部分header、params的参数处理,避免在具体接口请求是传入没必要要与接口无关的参数
    • 出参:对后台返回的数据按约定好的规则作一层基础解析处理,避免在具体接口数据解析的时候作一些无心义的操做

从投入的时间上来看:
第一部分基本上要花掉开发者80%以上的时间来封装
第二部分须要消耗的时间可能不足20% 【以此推算,按上面1个小时的封装时间,用在逻辑封装部分的时间也就12分钟左右】api

咱们再回头看一下,第一部分的【数据交换】封装是否涉及到具体业务逻辑呢?答案是:没有。服务器

既然没有咱们为何不把第一部分的封装交给第三方框架呢,咱们只须要作第二部分的封装多省事,有这样第三方框架么?数据结构

答案是:有的,react-native-easy-app 就能够实现【先后台数据交换】层面的封装,经过这个开源库,咱们就只须要实现涉及【App业务逻辑】层面的封装便可。app


为验证 react-native-easy-app 的实用性,在这里咱们先来构想一个业务逻辑层面封装的需求:

  1. 请求接口的公共headers参数有:

    • version、channelCode、model、platform (全部接口)
    • accessToken、refreshToken、customerId (登陆后额外增长)
  2. 请求接口的公共params参数有:

    • customerId (登陆后额外增长)
  3. 后台返回的数据结构示例以下:
    { data: {}, successful:1, msg: 'request msg', code: 'xxx'}

  4. 请求状态码为503的时候表示accessToken过时,accessToken过时的状况下,须要从新获取新的accessToken并刷新因accessToken过时致使请求失败的接口

    1. accessToken、refreshToken在登陆成功后的response的headers中返回。

对于以上业务逻辑层面的需求,看看经过 react-native-easy-app 咱们能够怎么作。

XHttpConfig().initHttpLogOn(true)
    .initHeaderSetFunc((headers) => {
        headers['model'] = 'xiao mi';
        headers['version'] = '1.0.0';
        headers['platform'] = Platform.OS;
        headers['channelCode'] = 'channelOfficial';
        if (isLogin()) {
            headers['customerId'] = RNStorage.customerId;
            headers['accessToken'] = RNStorage.accessToken;
            headers['refreshToken'] = RNStorage.refreshToken;
        }
    })
    .initParamSetFunc(params => {
        if (isLogin()) {
            params['customerId'] = RNStorage.customerId;
        }
    })
    .initParseDataFunc((result, request, callback) => {
        let {success, json, message, status, response} = result;
        if (status === 503) {// accessToken过时标记
            this.refreshToken(request, callback);
        } else {
            let {data, successful, msg, code} = json;
            callback(success && successful === 1, data || {}, msg || message, code, response);
        }
    });

accessToken从新请求的实现及对失败接口的刷新:

refreshToken = (request, callback) => {
    if (global.hasQueryToken) {
        global.tokenExpiredList.push({request, callback});
    } else {
        global.hasQueryToken = true;
        global.tokenExpiredList = [{request, callback}];
        const refreshUrl = `${RNStorage.baseUrl}api/refreshToken?refreshToken=${RNStorage.refreshToken}`;
        fetch(refreshUrl).then(resp => {
            resp.json().then(({successful, data: {accessToken}}) => {
                if (successful === 1) {// 获取到新的accessToken
                    RNStorage.accessToken = accessToken;
                    global.tokenExpiredList.map(({request, callback}) => {
                        request.resendRequest(request, callback);
                    });
                    global.tokenExpiredList = [];
                } else {
                    console.log('Token 过时,退出登陆');
                }
            });
        }).catch(err => {
            console.log('Token 过时,退出登陆');
        }).finally(() => {
            global.hasQueryToken = false;
        });
    }
};

就这样对当前构想的app的逻辑层面的封装就实现了(实现上面的代码约70行,也许要超过20分钟 ,但相较于之前从零开的封装,是否是节约了大量的时间呢?)是否是清晰明了。固然,这只是代码片断,没有实际操做,就没办法证实上面的代码实现是实际有效的。


为了演示,先用 react native init HttpTestDemo 建立一个RN项目:示例项目:HttpTestDemo 修改并删除没必要要的布局或资源,结果以下:

二十分钟封装,一个App先后台Http交互的实现

假定有三个接口,分别为 api/login、api/userInfo 、api/refreshToken (为了省事,接口都以json文件替代

  • api/login 有两个必传参数:[userName、userPass];请求内容类型为:application/x-www-form-urlencoded;post请求
  • api/userInfo 无参数;请求内容类型为:application/json;get请求
  • api/refreshToken 必须参数refreshToken;请求内容类型为:application/json;get请求

https://react-native-fast-app.oss-cn-beijing.aliyuncs.com/api/login
https://react-native-fast-app.oss-cn-beijing.aliyuncs.com/api/userInfo
https://react-native-fast-app.oss-cn-beijing.aliyuncs.com/api/refreshToken

  1. react-native-fast-app 的说明文档,安装库:npm install react-native-fast-app --save

  2. 定义一个持久化对象,用于保存accessToken,customerId等参数:
export const RNStorage = {// 持久化数据列表
    customerId: undefined,//客户ID
    accessToken: undefined,//OAuth2.0 accessToken
    refreshToken: undefined,//OAuth2.0 refreshToken
    baseUrl: undefined,
    userInfo: undefined,
    hasLogin: false,
};

3.在页面的构造方法时调用 RNStorage的初始化操做;初始化完成以后,调用Http请求XHttpConfig的【业务逻辑】层初始化方法,这样就完成了,如今就能够调用接口了。

  • 调用登陆接口:(因为使用json文件的形式只能使用get请求)
import { XHttp } from 'react-native-easy-app';

login = () => {
    let params = {userName: 'zhangsan', userPass: '123456a'};
    XHttp().url('api/login').param(params).formEncoded().get((success, json, message, status, resonse) => {
        if (success) {
            if (resonse.headers && resonse.headers.map) {
                RNStorage.accessToken = resonse.headers.map['x-oss-meta-accesstoken'];
                RNStorage.refreshToken = resonse.headers.map['x-oss-meta-refreshtoken'];
            }
            RNStorage.customerId = json.customerId;
            RNStorage.hasLogin = true;
            this.setState({data: JSON.stringify(json)});
        } else {
            console.log('失败', message);
        }
    });
};

调用接口,经过框架自带的日志功能,能够看到,该拼的参数都拼接了,从header中也获取到了token

二十分钟封装,一个App先后台Http交互的实现

  • 调用获取用户我的信息接口:
import { XHttp } from 'react-native-easy-app';

queryUserInfo = () => {
    XHttp().url('api/userInfo').formJson().get((success, json, message) => {
        if (success) {
            RNStorage.userInfo = json;
            this.setState({data: JSON.stringify(json)});
        } else {
            console.log('失败', message);
        }
    });
};

调用接口,经过框架自带的日志功能,能够看到accessToken、refreshToken也正确的拼接了。

二十分钟封装,一个App先后台Http交互的实现

因为没有合适的服务器,token过时的状况就不演示了,只要请求refreshToken的接口正常请求就不会有问题。

至此一个完整的App 【业务逻辑】层面的封装就彻底实现了,从Http请求的配置到,refreshToken的从新请求到刷新失败接口,一共大概只用了70行代码左右,是否是相较于以前从零开始的fetch封装简单容易多了,节约了大量的封装时间呢?

担忧框架的灵活性?请参考 react-native-easy-app 详解与使用之(二) fetch 而且react-native-easy-app 开源库并不仅有Http请求的封装,还有更多功能,有兴趣的同窗能够查看此栏目的其它文章,你确定会有更多收获。

当前示例项目连接:HttpTestDemo

相关文章
相关标签/搜索