做接口须要思考的问题
什么是接口
接口无非就是客户端申请你的接口地址，并传入一堆该接口定义好的参数，通过接口本身的逻辑解决，返回接口约定好的数据以及相应的数据格式。
接口怎么开发
接口因为自身的性质，因为和合作方对接数据，所以有以下几点须要在开发的时候留神：
1、定义接口入参：写好接口文档
2、定义接口返回数据类型：个别都须要封装成肯定格局，确定返回 json 还是 xml 报文等
见如下返回数据定义格局：
Result
Response
3、确定拜访接口的形式，get or post 等等，能够依据 restful 接口定义规定 RESTful API：RESTful API
4、定义一套全局对立并通用的返回码，以帮忙排查问题；
reponse code
5、对立的异样解决：应该每个零碎都须要一套对立的异样解决
6、拦截器链设置：合作方拜访接口的时候，会依据你接口定义好的传参拜访你的接口服务器，然而会存在接口参数类型谬误或者格局不对，必传参数没传的问题，甚至一些歹意申请，都能够通过拦截器链进行后期拦挡，防止造成接口服务的压力。
还有很重要的一点，加签验签也能够在拦截器设置。继承 WebMvcConfigurerAdapter 实现 springboot 的拦截器链。实现 HandlerInterceptor 办法编写业务拦截器。
SignInterceptor
WebAppConfigurer
7、token 令牌和 sign 数字签名实现数据保密性。
创立令牌（Token）
为保障申请的合法性，咱们提供第三方创立令牌接口，某些接口须要通过 token 验证音讯的合法性，免得蒙受非法攻打。
token 过期工夫目前临时定为 1 天，因为思考到合作方往往是分布式环境，多台机器都有可能申请 token，为了升高合作方保障 token 一致性的难度，调用接口创立 token 胜利当前一分钟以内，再次申请 token 返回的数据是一样的。
获取私钥
获取用于数字签名的私钥，第三方获取的私钥需妥善保留，并定期更新，私钥只参加数字签名，不作为参数传输。
数字签名形式：
参数签名；签名形式：所有值不为 null 的参数（不包含本参数）均参加数字签名，依照“参数名 + 参数值 + 私钥”的格局失去一个字符串，再将这个字符串 MD5 一次就是这个参数的值。（示例：h15adc39y9ba59abbe56e057e60f883g），所以须要先获取私钥。
验签形式：
将用户的所有非 null 参数放入定义好排序规定的 TreeSet 中进行排序，再用 StringBuilder 依照依照“参数名 + 参数值 + 私钥”的格局失去一个字符串（私钥从 redis 拿），再将这个字符串 MD5 一次就是这个参数的值。将这个值与用户传来的 sign 签名比照，雷同则通过，否则不通过。
8、接口限流
有时候服务器压力真的太大，以防交易接口被挤死，就能够对一些其余不影响次要业务性能并且计算量大的接口做限流解决。RateLimit– 应用 guava 来做接口限流，当接口超过指定的流量时，就不解决该接口的申请。
9、协定加密，http 升级成 https；
为什么要降级呢，为了保证数据的安全性。当应用 https 拜访时，数据从客户端到服务断，服务端到客户端都加密，即便黑客抓包也看不到传输内容。当然还有其余益处，这里不多讲。但这也是开发接口我的项目须要留神的一个问题。
总结
上面对接口开发服务做一些总结：
1. 拉还是推：
当接口作为数据源时，还要思考数据是让合作方被动过去拉还是数据有变动就推送呢，当然是推的成果更好，然而如何无效的推数据，不推反复数据等都是须要依据理论业务思考的问题。
2. 多台分布式服务器上，怎么保障交易的幂等和订单的唯一性
当接口服务和合作方都处于分布式状况下，就很容易呈现一个订单号申请屡次交易申请，然而依据幂等性，一张彩票只能交易一次，并且每次不论何时申请，后果都应该一样不会扭转。
这种状况下，咱们怎么保障唯一性呢，咱们须要把该订单和订单状态存 redis，每次申请时去看是否订单已存在。但可能这次交易不胜利，下次这张票还能够持续交易，能够生成新的订单号啊。
redis 的 setNX 是一个很好的解决方案，意思是当存在该 key 时，返回 false，当没有时，该 key 和 value 插入胜利。用作查看订单是否正在提交，如果是，则阻塞本次申请，防止反复提交，能够设置过期工夫 3s。提交之前锁定订单，避免反复提交。
3. 解决工夫超过 10s，主动返回该订单交易失败
总之，在高并发场景下，导致服务解体的起因还是 redis 和数据库，可能是 redis 读写太慢，或者数据库的一些 sql 使用不当，或者没建索引导致读写很慢。
如果你感觉这篇文章对你有点用的话，麻烦请给咱们的开源我的项目点点 star: http://github.crmeb.net/u/defu 不胜感激！