接口返回码处理

最新推荐文章于 2024-09-04 12:02:59 发布

刘彦青-Yannis

最新推荐文章于 2024-09-04 12:02:59 发布

阅读量3.8k

点赞数

分类专栏： java开发笔记编程思想

本文链接：https://blog.csdn.net/ityqing/article/details/79312664

版权

java开发笔记同时被 2 个专栏收录

69 篇文章 4 订阅

订阅专栏

编程思想

7 篇文章 1 订阅

订阅专栏

一般错误信息会以错误码的方式返回,而我们页面显示可能需要显示具体的错误信息,这样的话我们不妨将错误信息依键值对的方式存放, 错误码作为key,错误信息作为value。使用的时候通过错误码获取错误信息返回就行了

Map方式:

public class ErrorCodeConstant {
	
	public static Map<Integer, String> errcodemap = new LinkedHashMap<Integer, String>();
	static {
		errcodemap.put(-1, "系统繁忙，此时请开发者稍候再试");
		errcodemap.put(0, "请求成功");
		errcodemap.put(40001, "获取access_token时AppSecret错误，或者access_token无效。请开发者认真比对AppSecret的正确性，或查看是否正在为恰当的公众号调用接口");
		errcodemap.put(40002, "不合法的凭证类型");
		errcodemap.put(40003, "不合法的OpenID，请开发者确认OpenID（该用户）是否已关注公众号，或是否是其他公众号的OpenID");
		errcodemap.put(40004, "不合法的媒体文件类型");
		errcodemap.put(40005, "不合法的文件类型");
		errcodemap.put(40006, "不合法的文件大小");
		errcodemap.put(40007, "不合法的媒体文件id");
		errcodemap.put(40008, "不合法的消息类型");
		errcodemap.put(40009, "不合法的图片文件大小");
		errcodemap.put(40010, "不合法的语音文件大小");
		errcodemap.put(40011, "不合法的视频文件大小");
		errcodemap.put(40012, "不合法的缩略图文件大小");
		errcodemap.put(40013, "不合法的AppID，请开发者检查AppID的正确性，避免异常字符，注意大小写");
		errcodemap.put(40014, "不合法的access_token，请开发者认真比对access_token的有效性（如是否过期），或查看是否正在为恰当的公众号调用接口");
		errcodemap.put(40015, "不合法的菜单类型");
		errcodemap.put(40016, "不合法的按钮个数");		
		
	}
}

使用的时候获取错误信息就可以了：

public String getErrorMsg() {
		JSONObject j = JSONObject.fromObject(json);
		try {
			int code = j.getInt("errcode");
			return WeiXinErrorCodeConstant.errcodemap.get(code);
		} catch (Exception e) {
		}
		return WeiXinErrorCodeConstant.errcodemap.get(0);
	}

1,当返回码过多时适合用map存放返回码与返回信息

2,一般在调用第三方接口时使用这种方式,我们拿第三方接口返回的错误码去map中查找我们要显示的内容

Enum :

public enum AppLoginStatusEnum {

    MISS_PARAMS(0, "参数信息错误！"),
    SYS_ERROR(1,"系统异常！"),
    CODE_ERROR(2, "code编码错误！"),
    LOGIN_CODE_ERR(3,"验证码错误，请重新获取验证码！");

    private int code;
    private String desc;

    AppLoginStatusEnum(int code, String desc) {
        this.code = code;
        this.desc = desc;
    }

    public static AppLoginStatusEnum valueOfStatus(int code) {
        for (AppLoginStatusEnum appLoginStatusEnum : values()) {
            if (appLoginStatusEnum.getCode() == code) { return appLoginStatusEnum; }
        }
        return null;
    }

    public int getCode() {
        return code;
    }

    public void setCode(int code) {
        this.code = code;
    }

    public String getDesc() {
        return desc;
    }

    public void setDesc(String desc) {
        this.desc = desc;
    }

测试:

public class TestEnum {
	public static void main(String[] args) {
		System.out.println("错误码:"+AppLoginStatusEnum.LOGIN_CODE_ERR.getCode());
		System.out.println("错误信息："+AppLoginStatusEnum.LOGIN_CODE_ERR.getDesc());
	}
}

- 我们自己定义接口自己定义返回码时适合用这种方式

- 根据实际情况选择返回不同的数据，比如有些系统除了返回code，msg，data外还会返回请求的url和请求时间戳

以下摘自极客时间：

服务端把错误码反馈给客户端有两个目的，一是客户端可以展示错误码方便排查问题，二是客户端可以根据不同的错误码来做交互区分。

对于第一点方便客户端排查问题，服务端应该进行适当的收敛和规整错误码，而不是把服务内可能遇到的、来自各个系统各个层次的错误码，一股脑地扔给客户端提示给用户。

我的建议是，开发一个错误码服务来专门治理错误码，实现错误码的转码、分类和收敛逻辑，甚至可以开发后台，让产品来录入需要的错误码提示消息。

此外，我还建议错误码由一定的规则构成，比如错误码第一位可以是错误类型（比如 A 表示错误来源于用户；B 表示错误来源于当前系统，往往是业务逻辑出错，或程序健壮性差等问题；C 表示错误来源于第三方服务），第二、第三位可以是错误来自的系统编号（比如 01 来自用户服务，02 来自商户服务等等），后面三位是自增错误码 ID。

对于第二点对不同错误码的交互区分，我觉得更好的做法是服务端驱动模式，让服务端告知客户端如何处理，说白了就是客户端只需要照做即可，不需要感知错误码的含义（即便客户端显示错误码，也只是用于排错）。

比如，服务端的返回可以包含 actionType 和 actionInfo 两个字段，前者代表客户端应该做的交互动作，后者代表客户端完成这个交互动作需要的信息。其中，actionType 可以是 toast（无需确认的消息提示）、alert（需要确认的弹框提示）、redirectView（转到另一个视图）、redirectWebView（打开 Web 视图）等（这个类型可以体现在code中，在code中加上错误级类型位）；actionInfo 就是 toast 的信息、alert 的信息、redirect 的 URL 等。

由服务端来明确客户端在请求 API 后的交互行为，主要的好处是灵活和统一两个方面。灵活在于两个方面：

第一，在紧急的时候还可以通过 redirect 方式进行救急。比如，遇到特殊情况需要紧急进行逻辑修改的情况时，我们可以直接在不发版的情况下切换到 H5实现。

第二是，我们可以提供后台，让产品或运营来配置交互的方式和信息（而不是改交互，改提示还需要客户端发版）。统一：有的时候会遇到不同的客户端（比如 iOS、Android、前端），对于交互的实现不统一的情况，如果 API 结果可以规定这部分内容，那就可以彻底避免这个问题。