后端接口对接注意事项解析接口对接怎么做

后端接口对接的模式范本:

文章插图

概念澄清：
【下单】是个广义上的叫法，并不仅限于支付订单的订单。因为整个过程都围绕一个【seqNo】订单号或流水号这个唯一标识展开，因而统称【下单】。
【下单】可以是为派发一个优惠券、申请一个支付订单、申请一个发票等等。
【seqNo】也可以叫orderNo，有唯一性，每次请求都不一样，唯一标识一笔业务。
后端接口需要考虑的点：

通信层安全验证(可以通过nginx层做https的证书验证工作)
单向https.

即客户端验证服务端证书。例如：浏览器验证网站证书。
我们需要做的就是服务端的证书一定是要第三方授信CA签的证书。
这样浏览器拿到证书可以在本地找到该授信的第三方ca证书来验证网站证书的真伪。
如果网站的证书自己签名的证书，客户端需要在浏览器中配置该证书自签名使用的的CA证书。
https单向相比于双向实现方便，也是最基础的保障。不可能http直接在公网上跑，那样业务报文都是明文暴露状态，非常不安全。

双向https

一般后端交互https双向，基本都是使用自签名的证书。
客户端需要配置服务端的ca证书，用于解开服务端给我们的其自身的证书。
服务端同时也需要配置客户端的ca证书，用于解开客户端给服务端的其自身的证书。
如果是代码实现发送双向https请求,你会发现有两个证书配置,一个是请求方自身的证书，一个是服务端的ca证书。
https双向优点就是更加安全，通过证书能互相确认彼此身份。在后端交互中常见。单向https在浏览器/服务端中常见。

接口层校验:

接口或者header中有类似于sign的字段，用于验证签名。
签名的作用就两个:防篡改；防抵赖
sign = sha256WithRSA(报文,私钥)等方法的模式为【私钥签名、公钥验签】的方式，可以防篡改，防抵赖.但是实现相对较重，需要生成和管理公私钥。
使用appkey/secretKey模式,使用类似于sign=MD5(报文,secretkey)只能防篡改,因为这个secretKey是双方都知道的.但是实现方式较轻量，也很普遍。

数据安全保护

通信层https只能保证数据在网络或者公网中是密文传输的。
但是一旦数据过了nginx这关，即解除https证书验证之后，报文数据在内网中就是明文在传输。对应敏感数据不能明文显示。
复杂安全点的模式可以使用数字信封模式：
即提供两个字段：
partnerData:敏感数据的加密值，使用对称加密的，例如：AES算法。
dekey：随机对称密钥的加密值，使用非对称加密的，例如：RSA算法
partnerData=https://www.fajihao.com/i/AES(敏感数据,随机对称密钥)
dekey=RSA(随机对称密钥,接收方的公钥)
解密的过程就是加密的逆过程，先用自己的私钥解出对称密钥，再使用对称密钥解开敏感数据。
因为基于公私钥，所以只有私钥持有者才能解开这个数字信封。安全性非常好。

业务授权校验:

通信层可以进来，验签能通过。但是业务授权也要鉴别，例如：同样可以调用派发优惠券接口，但是商户A只能发商户A商品的优惠券。
接口或者header中有类似于appkey/appCode/authCode等类似功能字段，该字段和验签绑定。通过该字段查询配置，确认该请求是否有该业务的权限。

防重发攻击:

https单向中多见，https双向中少见。主要预防攻击不要流到业务层。
1.防止错误的报文重复攻击，一般错误报文验签直接可以过滤。
2.防止正确的报文重复攻击
一般在接口或者header中有timestamp/nonce/messageId等字段,这些字段每次请求都会不一致。
如果报文被截获,重放攻击,可能由于timestamp时间和服务器时间相差很远，或者相关nonce字段已经被缓存过，无法通过。
同时可以结合幂等措施，即被处理过的业务不会重复执行。

实现幂等:

接口中有seqNo字段,可以叫订单号/流水号。
一个seqNo就对应了一次业务下单，同样的流水号无论请求多少次，结果都是一样的，不会重复做。
防止请求在通信中丢失，请求方无法判断该业务的实际状态，是【还未送达】或【处理完了，回程时丢失】
实现幂等后，请求方可以使用相同seqNo进行下单，服务端如果处理过该seqNo订单，就将之前的处理结果返回，如果没处理就收单继续处理。

后端接口对接注意事项解析 接口对接怎么做

后端接口对接注意事项解析接口对接怎么做