java-http-json接口认证与防篡改机制非侵入式实现

一个好的代码，就是一次开发到处可用，开发者不用关注其细节，专心核心实现。奔着这个目标，有没有什么实现思路？那接下来，我不管你怎么想的，都听我的。

在本场 Chat 中，会讲到如下内容：

1. 接口开发的固化与痛点
2. 怎么解决接口提供方痛点
3. 怎么解决接口调用方痛点
4. java-http-json 接口 sdk 使用指南

涉及技术：接口开发、装饰者模式 、自定义注解、反射、md5 加密、过滤器

我们的目标

接口提供方仅通过配置、写实现具体的签名规则方法和获取 appKey 的方法，即可实现。

接口调用方仅通过注解、使用工具类、写签名规则方法和签名的参数拼接方法，即可实现。

是不是感觉大大简化了接口的开发和接入。不懂可以参考笔者的默认实现，但不建议直接使用。

代码在 github 上，最后会 post 上地址，请大家多多支持和 star。

接口开发套路

当产品跟你说要开发接口提供给其他系统使用或者说你要通过接口方式接入某些系统时，肯定先会问需要怎么签名？数据要加密？需要什么方式传输？

接口提供方

一般写个工具类进行签名认证或者解密，验证通过后这些便进行实际的业务逻辑。签名验证等的非业务逻辑的参数看着“碍眼”，因为“用完即走”嘛。那还能怎么办？难道接口开发还能不要验证的接口参数？嗯....下文会填坑。

接口调用方

要对接新接口，如果是开发言语一致还好，就询问对方要接口验证的工具类，然后自己再加工下写个新的工具类实现调用咯。开发言语不一致？嗯...还真没有其他办法，只能按着签名逻辑，自己写工具类。无论如何，接口调用方最麻烦的就是按照接口约定的参数进行拼接签名，不同接口不一样，都要写一遍把需要参数传入。那好像没啥办法。不要担心，还有点办法。

接口开发的重复

接口提供方的接口方法可能还需要其他地方使用，但是又加上了一些接口验证的参数。老手当然业务代码抽出来作为新的方法同时给接口和其他地方使用。此时一位萌新使用了 ctrl+c 和 ctrl+v，并膜拜了下大神的代码。接口调用方对接同一系统的新接口，又要 get、set 的搬砖模式。

“用完即走”的契机

接口的开发流程基本固定，在那些环节可以“用完即走”？

我们先梳理下接口交互的全过程：接口调用>>>接口服务>>>认证通过>>