API接口安全性设计 接口的安全性主要围绕Token、Timestamp和Sign三个机制展开设计，保证接口的数据不会被篡改和重复调用，下面具体来看：
Token授权机制：用户使用用户名密码登录后服务器给客户端返回一个Token（通常是UUID），并将Token-UserId以键值对的形式存放在缓存服务器中。服务端接收到请求后进行Token验证，如果Token不存在，说明请求无效。
关于token的说明：为不重复的字符串（一般为UUID），然后在Redis（任意缓存服务器）中维护Token—-Uid的用户信息关系，以便其他api对token的校验
时间戳超时机制：用户每次请求都带上当前时间的时间戳timestamp，服务端接收到timestamp后跟当前时间进行比对，如果时间差大于一定时间（比如5分钟），则认为该请求失效，这个时间要保证足够完成本次请求的同时尽量短，可以减少缓存服务器的压力（见签名机制）。
签名机制：将Token和时间戳加上其他请求参数就行MD5或SHA-1算法（可根据情况加点盐）加密，加密后的数据为本次请求的签名sign，并将该签名存放到缓存服务器中，超时时间设定为跟时间戳的超时时间一致（这就是为什么要尽量短，二者时间一致可以保证无论在timestamp规定时间内还是外本URL都只能访问一次）。服务端接收到请求后以同样的算法得到签名，并跟当前的签名进行比对，如果不一样，说明参数被更改过，直接返回错误标识。同一个签名只能使用一次，如果发现缓存服务器中已经存在了本次签名，则拒绝服务。
整个流程如下：
1、客户端通过用户名密码登录服务器并获取Token
2、客户端生成时间戳timestamp，并将timestamp作为其中一个参数
3、客户端将所有的参数，包括Token和timestamp按照自己的算法进行排序加密得到签名sign
4、将token、timestamp和sign作为请求时必须携带的参数加在每个请求的URL后边（http://url/request?token=123×tamp=123&sign=123123123）
5、服务端写一个过滤器对token、timestamp和sign进行验证，只有三个参数都正确且在规定时间内，本次请求才有效 在以上三中机制的保护下，
如果黑客劫持了请求，并对请求中的参数进行了修改，签名就无法通过；
如果黑客使用已经劫持的URL进行DOS攻击，服务器则会因为缓存服务器中已经存在签名而拒绝服务，所以DOS攻击也是不可能的；
如果黑客隔一段时间进行一次DOS攻击（假如这个时间大于签名在缓存服务器中的缓存时长），则会因为时间戳超时而无法完成请求，这就是为什么签名的缓存时长要跟时间戳的超时时长一样。
