前言

当我年少无知的时候,也曾四处奔波面试。有次去Pwc面试,面试官问我,给你一个场景,让你设计个API接口,你会从哪几个方面考量?我:enmm……然后回家等通知了

后来跟随很多大佬,在小本本里超认真的记下了大佬们口口相传的牛逼经验。再后来,我也成为了面试官,也问了应聘者同样的问题,哈哈哈,人生就是这么一个轮回~苍天饶过谁~

面试官想听什么?

作为面试官,其实是想通过这个开放性的问题, 看看你思考问题的角度。就算给了你一个特定的场景,你照样可以发散思维,不要局限在场景里,这是面试的技巧。

可以回答哪些方面呢?

现在都是面向服务架构,水平分层架构,再变为微服务架构,服务网格,服务与服务间的交互越来越复杂,如何优雅的设计一个接口,需要考虑哪些方面?特别是对公服务(比如BFF)需要对外提供公网域名的接口,安全性怎么保证?

一、实现REST式的API设计

关于这方面,我总结的几点

  • 用好HTTP方法(GET, POST, PATCH, PUT, DELETE)
  • 用好HTTP状态码(2xx、3xx、4xx、5xx……)
  • 用好URI:面向资源(每个资源都有唯一的URI)
  • 用好HTTP报头(location等)
  • 用好数据载体(一般为json格式)
  • 可以考虑异步设计(比如响应202Accepted,其后的操作异步处理,需要考虑后续的数据二次传输设计)

二、数据有效性校验

这点是任何开发人员都必须知道的!!! 不知道的出门右转

合法性校验包括:常规性校验以及业务校验;常规性校验:包括必填字段校验,长度校验,类型校验,格式校验等;业务校验:根据实际业务而定,比如订单金额不能小于0等;

三、幂等性设计

所谓幂等,简单地说,就是对接口的多次调用所产生的结果和调用一次是一致的。数据发生改变才需要做幂等,有些接口是天然保证幂等性的。比如查询接口。

有些对数据的修改是一个常量,并且无其他记录和操作,那也可以说是具有幂等性的。

其他情况下,所有涉及对数据的修改、状态的变更就都有必要防止重复性操作的发生。比如扣减库存,总不能扣减到负数吧,比如付款,总不能扣完了一次,还会再扣一次吧。

在这种情况下,主要考虑的方向是,怎么执行的先后顺序。在分布式环境下,可以考虑通过业务中出现的唯一标识作为数据库唯一索引来做更新,或者采用分布式锁的方案(Redis或者Zookeeper等)

四、安全性设计

1、数据加密

我们知道数据在传输过程中是很容易被抓包的,如果直接传输比如http协议传输,那么数据在传输的过程中可能被任何人获取。

所以,要加密!加密无非就两种,一种对称加密,一种非对称加密。

https的实现就是这两种方式的结合。

什么,你不知道?听我的,用它就对了

2、数据签名

  • 摘要【key】

将需要提交的数据通过某种计算方式组合成一个字符串,然后通过md5生成一段加密字符串,这段字符串就是数据包的签名。后续校验,可以采用同样的计算方式+加密字符串生成摘要比对。(比如存储密码的场景,不存明文)

  • 签名【证书】

客户端对明文进行MD5/SHA计算计算后的值再通过私钥加密得到密文,客户端将明文密文都发送给服务端。

服务端对密文使用公钥解密,得到值A,再对明文通过MD5/SHA计算得到值B,对比A和B的值,相同则验证通过。

这种方式也是明文传输的,不能保障数据的私密性

  • 签名+加密【证书】

客户端生成一个随机字符串,作为password,然后将password通过B公钥加密生成密文C,将A明文通过password加密生成密文B,同时将A明文做MD5/SHA计算后的值通过A私钥加密得到签名D,然后将密文B,密文C,签名D发给服务端。

服务端通过私钥解密密文C得到password,通过password解密密文B得到A明文,同时签名可以用来验证发送者是不是A,以及A发送的数据有没被第三方修改过。因为恶意方没有A的私钥,这个签名无法冒充,会被服务端识别出来。

3、时间戳机制

数据经过了加密处理,黑客抓取到了数据也看不到真实数据;但是有不法者不关心真实数据,拿到数据后直接进行恶意请求,这个时候简单的做法可以考虑时间戳机制,在每次请求中加入当前时间,服务端会将报文中的时间与系统当前时间做比对,看是否在一个固定的时间范围内比如5分钟,恶意伪造的数据是没法更改报文中时间的,超过5分钟就可以当作非法请求了。

4、AppId机制

大部分网站需要用户名和密码才能登陆,这其实是一种安全机制;对应的服务也可以使用这一机制,不是谁都可以调用,调用服务前必须先申请开通一个唯一的appid,提供相关的密钥,在调用接口时需要提供appid+密钥信息,服务端会进行验证。

appid使用字母,数字,特殊符号等随机生成,生成的唯一appid看系统实际要求是否需要全局唯一

5、黑名单机制

如果此appid进行过很多非法操作,或者说专门有一个中黑系统,经过分析之后直接将此appid列入黑名单,所有请求直接返回错误码;

我们可以给每个appid设置一个状态比如包括:初始化状态,正常状态,中黑状态,关闭状态等等;或者我们直接通过分布式配置中心,直接保存黑名单列表,每次检查是否在列表中即可;

五、限流机制

几种常见的限流算法

1、令牌桶限流

原理:系统以一定的速率向桶中放入令牌,填满了就丢弃令牌;请求来时会先从桶中取出令牌,如果能取到令牌,则可以继续完成请求,否则等待或者拒绝服务;令牌桶允许一定程度的突发流量,只要有令牌就可以处理,支持一次拿多个令牌

2、漏桶限流

原理:按照固定常量速率流出请求,流入请求速率任意,当请求数超过桶的容量时,新的请求等待或者拒绝服务。漏桶算法可以强制限制数据的传输速度

3、计数器限流

这个主要用来限制总的并发数,比如设置数据库连接池,线程池,接口的并发数等

面试结束……

面试官:骚年,回答的不错,什么时候过来上班。xxx:额,enmm,我再考虑一下