写在前面的话
接口就是服务端提供给客户端(App)端的一种通信协议，业界主流采用RESTful API的方式来设计接口，基于HTTP/HTTPS协议，以JSON为数据承载体。
当然也可以换个角度另外解释下：
服务器：“天王盖地虎？”
App甲：“宝塔镇河妖。。。”
App乙：“小鸡炖蘑菇！”
服务器：“小乙啊，组织欢迎你~”
App甲：“ ？？？？”
拒绝HTTP裸奔
某些同学喜欢这么设计接口：
request: http://api.simple.com/fuckingday?time=today
response:{data:"yes,it is!"}
粗看，没毛病啊~
但是http有两大特性：
一、是传输基于明文，则说明任何第三者都可以轻轻松松截取App发送到服务器的http请求报文。
二、前后请求之间是无状态的，也就是说前后的接口请求，服务端并不能很好认为是具有相关性的。
所以血腥案例触发：
第三者截取请求http://api.simple.com/fuckingday?time=today报文，将参数time改为tomorrow或者yesterday后发送给服务器。
服务器只会照单全收并返回yes,it is! 因为宝宝也委屈啊，当初跟那个屁客户端就是这么密谋协议暗号的；现在别问我为啥天天过得那么操蛋？我想静静。
接口参数签名
既然报文容易被截取并且伪造，那只能从增加游戏难度入手。
我们需要知道世界上存在一种算法--MD5算法，也叫消息摘要算法，从名字我们大概也能知道他的什么底细：可以将不限制特定长度的字符串转换成特定长度的字符串信息，复杂吧？
上面是增加理解难度的玩法，建议略过，直接从一个例子入手：
假如MD5("time=today") = "a90b2504ef59c452" 也就是"time=today"经过md5算法生成的摘要是"a90b2504ef59c452"这串字符串。
App请求服务器：
request:http://api.simple.com/fuckingday?time=today&signture=a90b2504ef59c452
服务端收到request请求后，取参数time=today开始MD5算法，得出签名摘要是"a90b2504ef59c452"，然后对比下signture参数值，发现尼玛是亲兄弟啊，暗号对上！返回 yes,it is! 标示接口请求成功。
这时候，某个缺心眼的第三者截取了报文，把time=today改成time=tomorrow后将伪造报文发给服务器。
request:http://api.simple.com/fuckingday?time= tomorrow&signture=a90b2504ef59c452
服务器收到请求一运算MD5("time=tomorrow")="3fbf1419d674ce15"明显与signture参数值"a90b2504ef59c452"存在出入，服务器直接返回 {data:"丢雷楼谋，别诓我"}，直接请求拒绝，伪造失败。
PS:如果参数不止一个怎么搞？业界做法一般都是按照参数首字母字典序，从小到大排列好再进行MD5摘要算法生成签名，例如
MD5("akey=xxxxxxbkey=yyyyyyckey=zzzzzz") = "2ac028173a8b6b13"
TOKEN盐字段
甲：这接口的设计？
乙：行家吖！来看看我刚刚搞的接口加密。
甲：这算法，low到掉牙了。
乙：是你不懂吧大叔。
甲：我知道，MD5算法走一下。
摘要MD5算法是一个公开的算法，有经验的大叔一般都轻轻松松会找出MD5("time=today") = "a90b2504ef59c452" 这个规律设计，然后通过MD5("time=tomorrow")="3fbf1419d674ce15"生成新的伪造签名后，同时更改time和signture两个参数的值
request:http://api.simple.com/fuckingday?time=tomorrow&signture= 3fbf1419d674ce15
服务端也只能默默的：WQNMLGB
但是！
虽然我们不能防范老鸟的破解，但是我们可以把算法的水搞浑啊O(∩_∩)O~~
所以一种不可描述的字段，会被我们衔接在加密字段的前后，业界上把这种不可描述的字段叫做传说中的盐字段。
例如我们选择了“ WQNMLGB”这一富有生命表现力的字符串作为盐，那么我们可以这么设计signtrue生成的生成算法:
MD5("WQNMLGBtime=todayWQNMLGB") = "37b7227e3c3ee8c0"
但第三者拦截篡改报文伪造请求时，他几乎不可能仅仅通过http携带的信息中轻松找到对应的盐字段，所以可以一定程度达到了接口保密的需求，当然这点安全性远远还是不够的。
结语
短小精悍一直是博主最喜欢的风格，毕竟一次性码太多不带稿费的字也是很伤身的，所以第一篇就暂且写到这里。
后续会继续推出几篇关于App接口设计的博客。
