安全性
1、创建appid,appkey和appsecret
2、Token：令牌（过期失效）
3、Post请求
4、客户端IP白名单 （可选）
5、单个接口针对IP限流（令牌桶限流，漏桶限流，计数器限流）
6、记录接口请求日志
7、采用Https
8、数据合法性校验
9、密码查询(加缓存，key使用客户号)
10、接口调用失败告警
11、高可用：服务器集群部署（2-3）
12、变更轨迹，保存上次密码？
13、查询密码和交易密码是否分两条？
幂等性
数据规范
版本控制
响应状态码规范
统一响应数据格式
appid：应用的唯一标识
appkey：公钥=账号
appsecret：私钥=密码
1、设计一个认证系统，专用于创建第三方接入应用的账号信息，用于生成appid,appkey和appsecret，然后发appkey和appsecret给第三方接入应用，用于做认证
ps：appkey和appsecret成对出现的机制，目的在于首次验证（类似登录场景），用来申请一个token，之后请求数据请求，就直接带token请求服务端认证即可。
2、第三方接入应用自行注册，需要校验企业信息合法性（暂不考虑）
1、第三方接入应用获取第一步中的appkey和appsecret
2、请求认证系统获取nonce随机数，服务端在缓存中存放下nonce
3、客户端拿到这个随机数后将其与appsecret拼接生appsecretStr，然后调用生成签名方法，传入appsecretStr，appkey，nonce，url（备注：可转大写，转小写，追加特殊字符，然后加密）进行非可逆加密（MD5/SHA1等），生成签名A。接着构造请求把签名放到请求头signature，post请求体中放入参数：appkey，nonce，timestamp，url根据request.getRequestURI()获取，调用认证接口
4、认证系统获取请求后，查询根据appkey查询缓存中的nonce，判断是否存在，不存在则提示不合法请求；判断是否相等，不等则为恶意请求。
判断timestamp的时效性，防止恶意请求：数据包中的客户端时间戳字段，然后用服务器当前时间去减客户端时间，看结果是否在一个区间内。
先根据appkey查询数据库，判断是否存在，如不存在则提示不合法用户；反之，查出appsecret，按照客户端的签名加密方式，进行加密，生成签名B，比较A和B，如果一样则生成token，失效缓存中的nonce，返回token。
限流是为了更好的维护系统稳定性。使用redis进行接口调用次数统计，ip+接口地址作为key，访问次数作为value，每次请求value+1，设置过期时长来限制接口的调用频率
使用aop全局记录请求日志，快速定位异常请求位置，排查问题原因。
1、服务端配置SSL证书
2、客户端调用https工具类忽略服务端证书校验
1、密码更新时，更新redis;
2、缓存查不到，查数据库，同时更新缓存；
3、密码在缓存和数据库都需要加密，返回时才解密（或者是返回客户端时，客户端自行解密）
想成为架构师？这份《史上最全架构师知识图谱》分享给你。
客户端重试机制
幂等性是指任意多次请求的执行结果和一次请求的执行结果所产生的影响相同。说的直白一点就是查询操作无论查询多少次都不会影响数据本身，因此查询操作本身就是幂等的。但是新增操作，每执行一次数据库就会发生变化，所以它是非幂等的。
幂等问题的解决有很多思路，这里讲一种比较严谨的。提供一个生成随机数的接口，随机数全局唯一。调用接口的时候带入随机数。
第一次调用，业务处理成功后，将随机数作为key，操作结果作为value，存入redis，同时设置过期时长。
第二次调用，查询redis，如果key存在，则证明是重复提交，直接返回错误。
一套成熟的API文档，一旦发布是不允许随意修改接口的。这时候如果想新增或者修改接口，就需要加入版本控制，版本号可以是整数类型，也可以是浮点数类型。一般接口地址都会带上版本号，http://ip:port//v1/list。
为了方便给客户端响应，响应数据会包含三个属性，状态码（code）、信息描述（message）、响应数据（data）。客户端根据状态码及信息描述可快速知道接口，如果状态码返回成功，再开始处理数据。
响应结果定义及常用方法：
