服务API设计之——API错误返回规范

API错误返回规范

禁止通过抛异常形式返回API业务错误

API禁止抛Checked异常,即业务处理上的参数错误、逻辑错误、业务错误等禁止通过抛异常形式返回,应用Response#code, message表达业务错误。

注:不要逼调用方到处写try{}catch()。

  • 正例:
1
Response<T> saveDesposit(...);
  • 反例:
1
T saveDesposit(...) throws ServiceException, IllegalArgumentException, ValidationException;

禁止通过抛异常形式返回API业务错误

API禁止抛Checked异常,即业务处理上的参数错误、逻辑错误、业务错误等禁止通过抛异常形式返回,应用Response#code, message表达业务错误。

注:不要逼调用方到处写try{}catch()。

  • 正例:
1
Response<T> saveDesposit(...);
  • 反例:
1
T saveDesposit(...) throws ServiceException, IllegalArgumentException, ValidationException;

需要调用方做错误细分处理的,API提供方务必一并提供判断工具类

  • 正例:
1
2
3
4
5
6
7
8
9
10
11
public void saveXXX(){
    Response<T> result = xxxWriteService(...)
    if (!result.isSuccess()){
        if (xxxUtils.isBankUnSupport(result.getCode)){   <<<API提供方提供工具类解析code含义,且code含义可持续迭代更新,调用方无感知。
            //银行渠道未开通,需要特殊提示
            ...
        }else{
            ...
        }
    }
}
  • 反例:
1
2
3
4
5
6
7
8
9
10
11
public void saveXXX(){
    Response<T> result = xxxWriteService(...)
    if (!result.isSuccess()){
        if ("10101".equals(result.getCode)){   <<<调用方按API提供方的错误码值做硬编码,代码耦合。
            //银行渠道未开通,需要特殊提示
            ...
        }else{
            ...
        }
    }
}

【推荐】API返回可直接显示给用户的中文提示信息

API失败时,只有API实现方最清楚是什么原因,该怎么提示。那么,请提供对应的提示信息。

我们系统中存在一些用国际化风格的error message,而当前的国际化实现方式真如你想的那么好用吗?

error message国际化原理:
  • 代码中的提示信息国际化配置文件

image-20180930154223074

  • 国际化提示原理

image-20180930162340975

1) 提示信息国际化的行为发生在Web层,Web层启动时会加载Web层的resources/messages提示信息文件

2)当REST API需要返回提示信息时,Web会根据HTTP 请求中的Locale值(例如:zh_CN、zh_TW、en_US、es_ES_Traditional_WIN等)来决定返回哪一种语言的提示信息。将errorMessage以此种语言方式返回给浏览器进行提示。

问题:

1)在分布式系统中,各个应用按领域自治,其resources/messages只维护了自身业务需要的errorMessage。

2)当图中C Service 将errorMessage = template.status.not.match 返回给 XX Service,XX Service直接透传给XX Web的情况下,XX Web的resources/messages是不包括template.status.not.match的,所以此errorMessage将无法正确的展示其本应该提示的信息。

所以,推荐API返回可直接显示给用户的中文提示信息。

  • 正例:
1
2
3
4
5
6
7
8
9
10
11
12
public Response<Boolean> saveTemplate(...) {

    try{
        ...
    }catch(StateMachineException e){
        log.warn("...");
        ...
        return Response.fail("模板配置正在审核中,请在审核完成后再更新");
    }catch(Exception e){
        ...
    }
}
  • 反例:
1
2
3
4
5
6
7
8
9
10
11
12
public Response<Boolean> saveTemplate(...) {

    try{
        ...
    }catch(StateMachineException e){
        log.warn("...");
        ...
        return Response.fail("模板管理状态机异常");
    }catch(Exception e){
        ...
    }
}

【推荐】返回具备可读性,引导性的错误提示信息

  • 正例:
1
2
3
4
5
6
7
8
9
10
11
12
public Response<Boolean> saveTemplate(...) {

    try{
        ...
    }catch(StateMachineException e){
        log.warn("...");
        ...
        return Response.fail("模板配置正在审核中,请在审核完成后再更新");
    }catch(Exception e){
        ...
    }
}
  • 反例:

例1

1
2
3
4
5
6
7
8
9
10
11
12
public Response<Boolean> saveTemplate(...) {

    try{
        ...
    }catch(StateMachineException e){
        log.warn("...");
        ...
        return Response.fail("模板管理状态机异常");  <<<< 你作为用户,是不是吓一跳?
    }catch(Exception e){
        ...
    }
}

例2

1
2
3
4
5
6
7
8
9
10
11
12
public Response<Boolean> saveTemplate(...) {

    try{
        ...
    }catch(StateMachineException e){
        log.warn("...");
        ...
        return Response.fail(e.getMessage());    <<<< message谁都看不懂,没有任何意义
    }catch(Exception e){
        ...
    }
}

转载于:https://my.oschina.net/u/3667677/blog/3096627

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
第一部分 理论与理由 第1章 软件开发的艺术 4 1.1 理性主义,经验主义以及无绪 4 1.2 软件的演变过程 6 1.3 大型软件 8 1.4 漂亮,真理和优雅 9 1.5 更好的无绪 12 第2章 设计API的动力之源 14 2.1 分布式开发 14 2.2 模块化应用程序 16 2.3 交流互通才是一切 20 2.4 经验主义编程方式 22 2.5 开发第一个版本通常比较容易 24 第3章 评价API好坏的标准 26 3.1 方法和字段签名 26 3.2 文件及其内容 27 3.3 环境变量和命令行选项 29 3.4 文本信息也是API 30 3.5 协议 32 3.6 行为 35 3.7 国际化支持和信息国际化 35 3.8 API的广泛定义 37 3.9 如何检查API的质量 37 3.9.1 可理解性 37 3.9.2 一致性 38 3.9.3 可见性 39 3.9.4 简单的任务应该有简单的方案 40 3.9.5 保护投资 40 第4章 不断变化的目标 42 4.1 第一个版本远非完美 42 4.2 向后兼容 43 4.2.1 源代码兼容 43 4.2.2 二进制兼容 44 4.2.3 功能兼容——阿米巴变形虫效应 50 4.3 面向用例的重要性 52 4.4 API设计评审 55 4.5 一个API的生命周期 56 4.6 逐步改善 60 第二部分 设计实战 第5章 只公开你要公开的内容 67 5.1 方法优于字段 68 5.2 工厂方法优于构造函数 70 5.3 让所有内容都不可更改 71 5.4 避免滥用setter方法 72 5.5 尽可能通过友元的方式来公开功能 73 5.6 赋予对象创建者更多权利 77 5.7 避免暴露深层次继承 82 第6章 面向接口而非实现进行编程 85 6.1 移除方法或者字段 87 6.2 移除或者添加一个类或者接口 88 6.3 向现有的继承体系中添加一个接口或者类 88 6.4 添加方法或者字段 88 6.5 Java中接口和类的区别 90 6.6 弱点背后的优点 91 6.7 添加方法的另一种方案 92 6.8 抽象类有没有用呢 94 6.9 要为增加参数做好准备 95 6.10 接口VS.类 97 第7章 模块化架构 98 7.1 模块化设计的类型 100 7.2 组件定位和交互 103 7.3 编写扩展点 116 7.4 循环依赖的必要性 117 7.5 满城尽是Lookup 121 7.6 Lookup的滥用 126 第8章 设计API时要区分其目标用户群 129 8.1 C和Java语言中如何定义API和SPI 129 8.2 API演进不同于SPI演进 131 8.3 java.io.Writer这个类从JDK 1.4到JDK 5的演进 131 8.4 合理分解API 143 第9章 牢记可测试性 147 9.1 API设计和测试 148 9.2 规范的光环正在褪去 151 9.3 好工具让API设计更简单 153 9.4 兼容性测试套件 155 第10章 与其他API协作 158 10.1 谨慎使用第三方API 158 10.2 只暴露抽象内容 162 10.3 强化API的一致性 164 10.4 代理和组合 168 10.5 避免API的误用 176 10.6 不要滥用JavaBeans那种监听器机制 180 第11章 API具体运行时的一些内容 184 11.1 不要冒险 186 11.2 可靠性与无绪 189 11.3 同步和死锁 191 11.3.1 描述线程模型 192 11.3.2 Java Monitors中的陷阱 193 11.3.3 触发死锁的条件 196 11.3.4 测试死锁 201 11.3.5 对条件竞争进行测试 204 11.3.6 分析随机故障 206 11.3.7 日志的高级用途 208 11.3.8 使用日志记录程序控制流程 210 11.4 循环调用的问题 215 11.5 内存管理 218 第12章 声明式编程 223 12.1 让对象不可变 225 12.2 不可变的行为 229 12.3 文档兼容性 230 第三部分 日常生活 第13章 极端的意见有害无益 236 13.1 API必须是漂亮的 237 13.2 API必须是正确的 237 13.3 API应该尽量简单 240 13.4 API必须是高性能的 242 13.5 API必须绝对兼容 242 13.6 API必须是对称的 245 第14章 
1. 介绍 2 2. 系统架构 10 3. 卡的架构 11 3.1. 运行时环境 11 3.2. 卡的管理者(Card Manager) 12 3.2.1. GlobalPlatform运行时环境(OPEN) 12 3.2.2. 发行者安全域 12 3.2.3. 卡持有者的校验方法 13 3.3. 安全域(Secure Domains) 13 3.4. GP的API(Open Platform API) 13 3.5. 卡的内容 13 4. 安全架构 15 4.1. 目标 15 4.2. 安全职责 15 4.2.1. 卡发行者(Card Issuer) 15 4.2.2. 应用提供者(Application Provider) 16 4.2.3. 控制授权中心机构(Controlling Authority) 16 4.2.4. 卡上组件的安全要求 16 4.2.4.1. 对运行时环境的安全要求 16 4.2.4.2. 对OPEN的安全要求 17 4.2.4.3. 对发行者安全域的安全要求 17 4.2.4.4. 对CVM处理者的安全要求 17 4.2.4.5. 对安全域的安全要求 17 4.2.4.6. 对应用的安全要求 18 4.2.5. 后台系统的安全要求 18 4.3. 加密支持 18 4.3.1. 卡内容的完整性校验和数据鉴别 18 4.3.1.1. 装载文件数据块HASH 18 4.3.1.2. 装载文件数据块签名 19 4.3.1.3. 委托管理令牌 19 4.3.1.4. 收条 19 4.3.2. 安全通讯 19 5. 生命周期模型 21 5.1. 卡的生命周期 21 5.1.1. 卡生命周期的状态 21 5.1.1.1. OP_READY状态 21 5.1.1.2. INITIALIZED状态 22 5.1.1.3. SECURED状态 22 5.1.1.4. CARD_LOCKED状态 22 5.1.1.5. TERMINATED状态 22 5.1.2. 卡生命周期状态的迁移 23 5.2. 可执行装载文件的生命周期(Excutable Load File Life Cycle) 24 5.2.1. 可执行装载文件的生命周期 25 5.2.1.1. LOADED状态 25 5.2.1.2. 可执行装载文件的删除 25 5.2.2. 可执行模块的生命周期 25 5.3. 卡内应用和安全域的生命周期 25 5.3.1. 卡内应用的生命周期状态 26 5.3.1.1. INSTALLED状态 26 5.3.1.2. SELECTBLE状态 26 5.3.1.3. LOCKED状态 26 5.3.1.4. 应用的删除 27 5.3.1.5. 应用特定生命周期状态 27 5.3.2. 安全域的生命周期状态 28 5.3.2.1. INSTALL状态 28 5.3.2.2. SELECTABLE状态 28 5.3.2.3. PERSONALIZED状态 28 5.3.2.4. LOCKED状态 28 5.3.2.5. 安全域的删除 29 5.4. 卡的生命周期和AP生命周期状态的演示 30 6. 卡的管理者(CM) 32 6.1. 概述 32 6.1.1. OPEN 32 6.1.2. 发行者安全域 33 6.1.3. CVM处理者 34 6.2. CM的服务 34 6.2.1. 应用访问OPEN服务 34 6.2.2. 应用访问CVM服务 34 6.2.3. 应用访问发行者安全域的服务 35 6.2.4. 发行者域访问应用服务 35 6.4. 卡内容的管理 41 6.4.1. 卡内容的装载和安装 41 6.4.1.1. 卡内容的装载 42 6.4.1.2. 卡内容的安装 43 6.4.2. 内容的移除 45 6.4.2.1. 应用的移除 45 6.4.2.2. 可执行装载文件的移除 46 6.4.2.3. 可执行装载文件和相关应用的移除 47 6.4.3. 内容的移交(context Extradition) 48 6.5. 委托管理 48 6.6. GP的注册表 49 6.6.1. 发行者域数据元素的描述 49 6.6.1.1. 发行者安全域的AID 50 6.6.1.2. 卡的生命周期状态 50 6.6.2. 应用/可执行装载文件/可执行模块的数据元素的描述 50 6.6.2.1. 应用/可执行装载文件/可执行模块的AID 50 6.6.2.2. 应用/可执行装载文件/可执行模块的生命周期 50 6.6.2.3. 资源分配 50 6.6.2.4. 应用的权限 51 6.6.2.5. 相关联安全域的AID 52 6.7. 安全管理 52 6.7.1. 应用的锁定 53 6.7.2. 卡的锁定 54 6.7.3. 卡的终止 55 6.7.4. 操作频率的检查 56 6.7.4.1. 卡内容的装载和安装时的频率检查 56 6.7.4.2. 异常操作频率检查 56 6.7.5. 跟踪和事件的记载 57 6.7.6. 安全内容的装载和安装 57 6.7.6.1. 装载文件的数据块HASH值 57 6.7.6.2. 令牌 57 6.7.6.3. 装载文件数据块的签名 57 6.8. 发行者安全域 58 6.8.1. 发行者的标识号 58 6.8.2. 卡的Image号 58 6.8.3. 卡的识别数据 59 6.8.4. 卡上的密钥信息 59 7. 安全域 63 7.1. 概述 63 7.2. 安全域服务 64 7.2.1. 访问安全域服务的应用 64 7.2.2. 访问应用的安全域 65 7.3. 个人化支持 65 7.4. 运行时消息支持 66 7.5. DAP验证 67 7.6. 代理管理 68 7.6.1. 代理下载 68 7.6.2. 代理安装 69 7.6.3. 代理移交 70 7.6.4. 代理删除 71 7.7. 代理管理令牌、收条及DAP验证 72 7.7.1. 下载令牌 72 7.7.2. 下载收条 73 7.7.3. 安装、移交令牌 73 7.7.4. 安装收条 73 7.7.5. 移交收条 74 7.7.6. 删除收条 74 7.7.7. 下载文件数据块hash 75 7.7.8. 下载文件数据块签名 (DAP验证) 75 8. 安全通讯 76 8.1. 安全通道 76 8.2. 显式/隐式的安全通道 76 8.2.1. 显式安全通道初始化 76 8.2.2. 隐式安全通道初始化 77 8.2.3. 安全通道结束 77 8.3. 直接/间接处理安全通道协议 77 8.4. 实体认证 77 8.5. 安全消息传输 77 8.6. 安全通道协议标识 78 9. APDU命令参考 80 9.1. 总的编码规则 81 9.1.1. 生命周期状态的编码 81 9.1.2. 应用的权限编码 82 9.1.3. 一般性的错误情形 83 9.1.4. CLASS字节编码 84 9.1.5. APDU命令和响应数据 84 9.1.6. 密钥类型编码 84 9.1.7. 在委托管理的响应消息中的收条信息(可选) 85 9.2. DELETE命令 86 9.2.1. 定义和范围 86 9.2.2. 命令消息 86 9.2.2.1. 引用控制参数P1 86 9.2.2.2. 引用控制参数P2 86 9.2.2.3. 命令消息中发送的数据字段 86 9.2.3. 响应消息 87 9.2.3.1. 在响应消息中返回的数据字段 87 9.2.3.2. 在响应消息中返回的处理状态 87 9.3. GET DATA命令 88 9.3.1. 定义和范围 88 9.3.2. 命令消息 88 9.3.2.1. CLA字节 88 9.3.2.2. 参数P1和P2 88 9.3.2.3. 在命令消息中发送的数据字段 89 9.3.3. 响应消息 89 9.3.3.1. 在响应消息中返回的数据字段 89 9.3.3.2. 在响应消息中返回的处理状态 90 9.4. GET STATUS命令 90 9.4.1. 定义和范围 90 9.4.2. 命令消息 90 9.4.2.1. 引用控制参数P1 91 9.4.2.2. 引用控制参数P2 91 9.4.2.3. 命令消息中发送的数据字段 92 9.4.3. 响应消息 92 9.4.3.1. 在响应消息中返回的数据字段 92 9.4.3.2. 在响应消息中返回的处理状态 93 9.5. INSTALL命令 94 9.5.1. 定义和范围 94 9.5.2. 命令消息 94 9.5.2.1. 引用控制参数P1 94 9.5.2.2. 引用控制参数P2 95 9.5.2.3. 命令消息中发送的数据字段 95 9.5.3. 响应消息 98 9.5.3.1. 在响应消息中返回的数据字段 98 9.5.3.2. 在响应消息中返回的处理状态 99 9.6. LOAD命令 99 9.6.1. 定义和范围 99 9.6.2. 命令消息 99 9.6.2.1. 引用控制参数P1 100 9.6.2.2. 引用控制参数P2-块号 100 9.6.2.3. 命令消息中发送的数据字段 100 9.6.3. 响应消息 101 9.6.3.1. 在响应消息中返回的数据字段 101 9.6.3.2. 在响应消息中返回的处理状态 101 9.7. MANAGE CHANNEL命令 102 9.7.1. 定义和范围 102 9.7.2. 命令消息 102 9.7.2.1. 引用控制参数P1 102 9.7.2.2. 引用控制参数P2 102 9.7.2.3. 命令消息中发送的数据字段 103 9.7.3. 响应消息 103 9.7.3.1. 在响应消息中返回的数据字段 103 9.7.3.2. 在响应消息中返回的处理状态 103 9.8. PUT KEY命令 103 9.8.1. 定义和范围 103 9.8.2. 命令消息 104 9.8.2.1. 引用控制参数P1 104 9.8.2.2. 引用控制参数P2 104 9.8.2.3. 命令消息中发送的数据字段 105 9.8.3. 响应消息 106 9.8.3.1. 在响应消息中返回的数据字段 106 9.8.3.2. 在响应消息中返回的处理状态 107 9.9. SELECT命令 107 9.9.1. 定义和范围 107 9.9.2. 命令消息 107 9.9.2.1. 引用控制参数P1 108 9.9.2.2. 引用控制参数P2 108 9.9.2.3. 命令消息中发送的数据字段 108 9.9.3. 响应消息 108 9.9.3.1. 在响应消息中返回的数据字段 108 9.9.3.2. 在响应消息中返回的处理状态 109 9.10. SET STATUS命令 109 9.10.1. 定义和范围 109 9.10.2. 命令消息 109 9.10.2.1. 引用控制参数P1-状态类型 110 9.10.2.2. 引用控制参数P2-状态控制 110 9.10.2.3. 命令消息中发送的数据字段 111 9.10.3. 响应消息 111 9.10.3.1. 在响应消息中返回的数据字段 111 9.10.3.2. 在响应消息中返回的处理状态 111 9.11. STORE DATA命令 111 9.11.1. 定义和范围 111 9.11.2. 命令消息 111 9.11.2.1. 引用控制参数P1 112 9.11.2.2. 引用控制参数P2 113 9.11.2.3. 命令消息中发送的数据字段 113 9.11.3. 响应消息 114 9.11.3.1. 在响应消息中返回的数据字段 114 9.11.3.2. 在响应消息中返回的处理状态 114 A. GP的API 116 A.1. 不赞成的Open Platform Java卡API 116 A.2. GP在JAVA卡上 116 A.2.1. GP特定的要求 116 A.2.1.1. GlobalPlatform包的AID 116 A.2.1.2. 安装 116 A.2.1.3. T=0传输协议 117 A.2.1.4. 原子操作 118 A.2.1.5. 逻辑通道 118 A.2.1.6. 加密算法 118 A.2.1.7. 信任级别 118 A.2.1.8. GlobalPlatform方法的调用 118 A.2.2. 类的层次 119 A.2.2.1. 接口org.globalplatform.Application 119 A.2.2.2. 接口org.globalplatform.SecureChannel 120 A.2.2.3. 类org.globalplatform.GPSystem 127 A.2.2.4. 接口org.globalplatform.CVM 131 A.3. GP在windows Powered智能卡 136 B. 算法(加密和HASH) 138 B.1. 数据加密标准(DES) 138 B.1.1. 加密/解密 138 B.1.1.1. CBC模式 138 B.1.1.2. ECB模式 138 B.1.2. MAC 138 B.1.2.1. 完整的TDES MAC 138 B.1.2.2. Single DES加上最终的TDES MAC 138 B.2. HASH算法 139 B.2.1. 安全HASH算法(SHA-1) 139 B.3. 公钥加密方案1(PKCS#1) 139 B.4. DES数据填充 139 C. 安全内容管理 141 C.1. 密钥 141 C.1.1. 发行者安全域密钥 141 C.1.1.1. 令牌密钥 141 C.1.1.2. 收条密钥 141 C.1.2. 安全域密钥 141 C.2. 下载文件数据块Hash 142 C.3. 令牌 142 C.3.1. 下载令牌 142 C.3.2. 安装令牌 143 C.3.3. Extradition Token 145 C.4. 收条 145 C.4.1. 下载收条 146 C.4.2. 安装收条 146 C.4.3. 删除收条 147 C.4.4. 移交收条 148 C.5. DAP验证 148 C.5.1. PKC方案 149 C.5.2. DES方案 149 D. 安全通道协议‘01’ 150 D.1. 安全通讯 150 D.1.1. SCP01安全通道 150 D.1.2. 相互认证 150 D.1.3. 消息的完整性 152 D.1.4. 消息数据的机密性 152 D.1.5. ICV的加密 152 D.1.6. 安全级别 152 D.2. 加密密钥 153 D.3. 加密用法 154 D.3.1. DES会话密钥 154 D.3.2. 鉴别密码(Authenticated Cryptogram) 156 D.3.2.1. 卡的鉴别密码(Card cryptogram) 156 D.3.2.2. 主机端鉴别密码(host cryptogram) 156 D.3.3. MAC生成和MAC校验的APDU指令 156 D.3.4. APDU命令的加密和解密 157 D.3.5. 关键敏感数据的加密和解密 158 D.4. 安全通道的APDU命令 159 D.4.1. INITIALIZE UPDATE命令 159 D.4.1.1. 定义和范围 159 D.4.1.2. 命令消息 160 D.4.1.3. 引用控制参数P1——密钥版本号 160 D.4.1.4. 引用控制参数P2——密钥标识 160 D.4.1.5. 命令消息中要传送的数据段 160 D.4.1.6. 响应消息 160 D.4.1.7. 在响应消息中返回的执行状态 161 D.4.2. EXTERNAL AUTHENTICATION命令 161 D.4.2.1. 定义和范围 161 D.4.2.2. 命令消息 161 D.4.2.3. 引用控制参数P1——安全级别 162 D.4.2.4. 引用控制参数P2 162 D.4.2.5. 命令消息中要传送的数据段 162 D.4.2.6. 响应消息返回的数据段 162 D.4.2.7. 在响应消息中返回的执行状态 162 E. 安全通道协议‘02’ 164 E.1. 安全通迅 164 E.1.1. SPC02安全通道 164 E.1.2. 实体鉴别 165 E.1.2.1. 显式安全通道的初始化 166 E.1.2.2. 隐式安全通道的初始化 167 E.1.3. 消息的完整性 167 E.1.4. 消息数据的机密性 168 E.1.5. 安全级别 168 E.2. 加密密钥 170 E.3. 加密算法 171 E.3.1. CBC 171 E.3.2. 消息的完整性ICV在显式安全通道初始化中的使用 171 E.3.3. 消息的完整性ICV在隐式安全通道初始化中的使用 172 E.3.4. ICV的加密 172 E.4. 加密用法 172 E.4.1. DES会话密钥 172 E.4.2. 在显式安全通道中的鉴别密码 173 E.4.2.1. 卡的鉴别密码(Card cryptogram) 173 E.4.2.2. 主机端的鉴别密码(host cryptogram) 173 E.4.3. 在隐式安全通道中的鉴别密码(Authenticate Cryptogram) 174 E.4.4. APDU命令C-MAC的生成和校验 174 E.4.5. APDU命令响应的R-MAC生成和校验 176 E.4.6. APDU命令数据段的加密和解密 177 E.4.7. 敏感数据的加密和解密 178 E.5. 安全通道的APDU指令 178 E.5.1. INITIALIZE UPDATE命令 179 E.5.1.1. 定义和范围 179 E.5.1.2. 命令消息 179 E.5.1.3. 引用控制参数P1——密钥版本号 180 E.5.1.4. 引用控制参数P2 180 E.5.1.5. 命令消息中要传送的数据段 180 E.5.1.6. 响应消息 180 E.5.1.7. 在响应消息中返回的执行状态 180 E.5.2. EXTERNAL AUTHENTICATION命令 181 E.5.2.1. 定义和范围 181 E.5.2.2. 命令消息 181 E.5.2.3. 引用控制参数P1——安全级别 181 E.5.2.4. 引用控制参数P2 182 E.5.2.5. 命令消息中要传送的数据段 182 E.5.2.6. 响应消息返回的数据段 182 E.5.2.7. 在响应消息中返回的执行状态 182 E.5.3. BEGIN R-MAC SESSION命令 182 E.5.3.1. 定义和范围 182 E.5.3.2. 命令消息 183 E.5.3.3. 引用控制参数P1 183 E.5.3.4. 引用控制参数P2 183 E.5.3.5. 命令消息中要传送的数据段 183 E.5.3.6. 响应消息返回的数据段 184 E.5.3.7. 在响应消息中返回的执行状态 184 E.5.4. END R-MAC SESSION命令 184 E.5.4.1. 定义和范围 184 E.5.4.2. 命令消息 184 E.5.4.3. 引用控制参数P1 185 E.5.4.4. 引用控制参数P2 185 E.5.4.5. 命令消息中要传送的数据段 185 E.5.4.6. 响应消息返回的数据段 185 E.5.4.7. 在响应消息中返回的执行状态 185 F. GP的数据及卡的识别数据 187 F.1. 数据值 187 F.2. 卡识别数据的结构 187 F.3. 安全域管理数据 188

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值