安姐技术管理课：API设计原则：加密，签名，调用堆栈方案设计

程序构建

http://www.jianshu.com/p/9c2a8676b8d1

https://www.jianshu.com/p/e2f88335b455

https://github.com/oldratlee/translations/blob/master/api-design-principles-from-qt/README.md?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io

验证签名

用户证书，白名单机制

seesion cookie token

调用方申请App Key 和 App Secret

• 在生成请求时，使用所有字母顺序排序后拼接的字符串 + App Secret 拼接后进行MD5加密，然后将 App Key， 加密结果追加到请求上。

• 服务收到请求后，根据AppKey识别出调用方，然后从字典中查询到对应的App Secret，与请求参数拼接、加密，与请求中的签名进行对比，签名结果相同的为合法请求。

• 这种签名方式符合上一节提到的使用签名的目的：由于请求的参数会作为签名的一部分，所以请求参数变化后，签名结果一定会随之发生变化，否则将无法认证通过；通过App Key 可以快速识别出API 调用者的身份，而无需与实际业务逻辑掺杂起来，通用性更强。

联想到当前的api系统中，每一个用户单独生成app key,appsecret
这样子，在log过程中根据appkey,收集日志会比较清晰，好排查，二者，根据appkey获取一个请求的全过程，便于排查错误，

分布式系统中，把请求的日志过程传递给每一步骤，一旦出错，在当地排查就行，可以记录一个request tag的id，具体记录存在第三存储，如mogodb,redisd,等，
* 进去请求先先去堆栈拿一下调用的过程信息
* 或是出错的时候在打印也行，
* 或是不在本地打印，直接去堆栈库查看

restfull,幂等

• DAT, 一切可以CRUD
• 竟可能保持参数和返回结果的结构化

尽可能与客户端无关

wap,app client,wx 小程序，插件小程序，尽可能一致，

Api 框架

• 访问权限统一控制
• 自动测试支持
• 请求响应，序列化和反序列化支持
• 日志过滤支持
• 文档自动生成支持

• 对架构和性能的影响

• java

  • http://wdxtub.com/2017/03/09/hug-guide/
  • http://www.jdon.com/soa/6-restful.html
  • http://www.jdon.com/46082
  • http://colobu.com/2015/11/15/best-available-java-restful-micro-frameworks/

• https://github.com/search?o=desc&q=rest+api+framework&s=stars&type=Repositories&utf8=%E2%9C%93

  • https://github.com/encode/django-rest-framework
  • https://github.com/falconry/falcon

设计中的平衡

团体中要有一定的规则，无规则不成方圆，不限制的自由，相当于没有自由，随着规模的增大，还是需要指定响应的规则和约束，保证大家，工作和任务的框架一致性

现在设计还是未来设计？

结合当前业务，将来可能用到的考虑一步，再多就不现实了，你我都知道这系统变化的能力，某些方便讲不受主观意志的控制

可维护性与效率和进度

尽可能的多用抽象和封装，复用，代码性能，质量与工期进度，需要自己在现实场景用做权衡，一般工期进度会靠前，workaround的概念也与此息息相关

AOP

好处，切面编程，关注点分离，将特定领域的问题从代码逻辑业务中分离出来

• 程序只关心和核心的业务逻辑和功能单元，他们不再是线性依赖的关系，
• 将特定的业务逻辑封装维护，是系统更好管理，分散的系统，通过Aop 挂载在一起：日志，解析，监控，

缺点，各个流程被分离，起来，一个完整的流程，如果要分析，整理，调试，会增加时间。

• 新手不友好，代码剖析，调试困难，对于系统全面掌握才能理解和做出评估，并采取下一步的措施

• 业务之间关联，修改后不能直观的反应到流程，因为是分离的，虽然不会有大的影响，但是一旦有小问题影响出错，报警，异常，可能不会反馈到主流程，对于这个还需要进一步的拆分和处理，整个程序的复杂度还会进一步提升

aop 切面的粒度，还需要自己根据业务场景，复杂度，人员情况，工期进度，做出权衡

All about priority and tradeoff

api 签名，api 设计原则，api 框架，编程语言，人员情况，项目情况，进度情况，将来的扩展
... 尽可能的考虑更多的条件，在各个条件中做出权衡和取舍