简易版api设计思路

   项目做大，难免少不了有服务及接口开放。如何保障请求合法？防止参数篡改呢？
若是开放给第三方厂商则可以考虑ip限制接口调用，并将请求参数加密传输校验。
可以仿照微信公众平台设计
给第三方厂商分配 appkey appsecret
appKey    全局唯一类似用户名不可变更
appSecret 类似密码可重置修改
调用流程
第三方发送请求参数(appkey sign timestamp 及其他请求参数)
appkey 平台分配
sign 签名 
使用md5 或sha1 将请求参数字典排序后加密
例如 md5(appKey+其他请求参数串+appSecret)
服务端
校验ip是否在白名单请求内，若不是则终止请求
校验签名是否正确
判断时间戳是否与当前时间相差10分钟内，若过期则终止请求。（阻止过时消息）
思路大致如此，实现可借助mysql redis openresty
mysql 配置三方厂商及白名单信息
redis 将mysql 配置载入缓存，提升性能
openresty 借助lua 连接redis 统一拦截ip 及签名参数校验
若鉴权要求更高还可以根据appKey+appSecret 生成access_token 进行调用,access_token设置调用时长为2小时，2小时候后自动失效。失效需重新请求，更细粒度可以关联appKey分配到每个方法级别访问权限，用拦截器统一校验即可
-- 错误码设计也是一门学问，可以参考一下阿里规范
1. 【强制】错误码的制定原则：快速溯源、简单易记、沟通标准化。
说明： 错误码想得过于完美和复杂，就像康熙字典中的生僻字一样，用词似乎精准，但是字典不容易随身
携带并且简单易懂。
正例：错误码回答的问题是谁的错？错在哪？1）错误码必须能够快速知晓错误来源，可快速判断是谁的问
题。2）错误码易于记忆和比对（代码中容易 equals）。3）错误码能够脱离文档和系统平台达到线下轻量
化地自由沟通的目的。
2. 【强制】错误码不体现版本号和错误等级信息。
说明：错误码以不断追加的方式进行兼容。错误等级由日志和错误码本身的释义来决定。
3. 【强制】全部正常，但不得不填充错误码时返回五个零：00000。
4. 【强制】错误码为字符串类型，共 5 位，分成两个部分：错误产生来源+四位数字编号。
说明：错误产生来源分为 A/B/C，A 表示错误来源于用户，比如参数错误，用户安装版本过低，用户支付
超时等问题；B 表示错误来源于当前系统，往往是业务逻辑出错，或程序健壮性差等问题；C 表示错误来源
于第三方服务，比如 CDN 服务出错，消息投递超时等问题；四位数字编号从 0001 到 9999，大类之间的
步长间距预留 100，参考文末附表 3。
5. 【强制】编号不与公司业务架构，更不与组织架构挂钩，一切与平台先到先申请的原则进行，
审批生效，编号即被永久固定。
6. 【强制】错误码使用者避免随意定义新的错误码。
说明：尽可能在原有错误码附表中找到语义相同或者相近的错误码在代码中使用即可。
7. 【强制】错误码不能直接输出给用户作为提示信息使用。
说明：堆栈（stack_trace）、错误信息(error_message)、错误码（error_code）、提示信息（user_tip）
是一个有效关联并互相转义的和谐整体，但是请勿互相越俎代庖。
8. 【推荐】错误码之外的业务独特信息由 error_message 来承载，而不是让错误码本身涵盖过
多具体业务属性。
9. 【推荐】在获取第三方服务错误码时，向上抛出允许本系统转义，由 C 转为 B，并且在错误信
息上带上原有的第三方错误码。
10.【参考】错误码分为一级宏观错误码、二级宏观错误码、三级宏观错误码。
说明：在无法更加具体确定的错误场景中，可以直接使用一级宏观错误码，分别是：A0001（用户端错误）、
Java 开发手册
 28/57
B0001（系统执行出错）、C0001（调用第三方服务出错）。
正例：调用第三方服务出错是一级，中间件错误是二级，消息服务出错是三级。
11.【参考】错误码的后三位编号与 HTTP 状态码没有任何关系。
12.【参考】错误码尽量有利于不同文化背景的开发者进行交流与代码协作。
说明：英文单词形式的错误码不利于非英语母语国家（如阿拉伯语、希伯来语、俄罗斯语等）之间的开发
者互相协作。
13.【参考】错误码即人性，感性认知+口口相传，使用纯数字来进行错误码编排不利于感性记忆
和分类。
说明：数字是一个整体，每位数字的地位和含义是相同的。
反例：一个五位数字 12345，第 1 位是错误等级，第 2 位是错误来源，345 是编号，人的大脑不会主动地
分辨每位数字的不同含义。