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

概念澄清：

【下单】是个广义上的叫法，并不仅限于支付订单的订单。因为整个过程都围绕一个【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是双方都知道的.但是实现方式较轻量，也很普遍。

 

 签名方式：推荐对报文json字符串做base64,然后对base64字符串进行签名。这样避免约定字段顺序，还有字段增删时对签名的影响。

• 数据安全保护

通信层https只能保证数据在网络或者公网中是密文传输的。

但是一旦数据过了nginx这关，即解除https证书验证之后，报文数据在内网中就是明文在传输。对应敏感数据不能明文显示。

复杂安全点的模式可以使用数字信封模式：

即提供两个字段：

partnerData:敏感数据的加密值，使用对称加密的，例如：AES算法。

dekey：随机对称密钥的加密值，使用非对称加密的，例如：RSA算法

partnerData=AES(敏感数据,随机对称密钥)  

dekey=RSA(随机对称密钥,接收方的公钥)

解密的过程就是加密的逆过程，先用自己的私钥解出对称密钥，再使用对称密钥解开敏感数据。

因为基于公私钥，所以只有私钥持有者才能解开这个数字信封。安全性非常好。但是效率偏低，

因为有对称和非对称的计算。对称秘钥建议添加校验数据，在解开时用于业务级别的校验。

 

原则上敏感数据不准走前端传递，传递也必须加密或脱敏。某些复杂业务需要很多服务交互的后端系统也遵循该原则。

一般做法是借鉴Oauth，前端或者系统间传递的是一个令牌token, 最终使用数据的系统，通过token向数据提供方获取数据。

这个token既可以作为整个业务流程的日志串联标志，同时也可以保护敏感数据。

 

条件允许的情况下，尽量使用等效数据替代真实数据，避免安全合规的问题。

例如：

利用使用用户手机号hash代替用户手机号；

对外提供的用户标识为系统映射过的用户openId而非真实用户标识。

作为中间系统传递的数据，约定由源头加密或编码，目标端负责解密或解码。中间系统不需要理解数据也不做任何处理。

 

 

　　　　　密钥的管理推荐使用KMS,对称密钥需要由密钥树逐级分散产生(例如3DES分散算法)，子密钥可以由上级母密钥加分散因子计算得出，

　　　　　但是子密钥无法推算出上级母密钥。使用时通过传入不同分散因子实现【一次一密】【一人一密】【一卡一密】等。

　　　　　如遇火灾等毁灭性打击，通过rootKey恢复所有子密钥。唯一管理成本即rootKey的管理保护,一般放在银行保险箱中，且多地备份。

 

• 业务授权校验:

通信层可以进来，验签能通过。但是业务授权也要鉴别，例如：同样可以调用派发优惠券接口，但是商户A只能发商户A商品的优惠券。

接口或者header中有类似于appkey/appCode/authCode等类似功能字段，该字段和验签绑定。通过该字段查询配置，确认该请求是否有该业务的权限。

 

• 防重发攻击:

https单向中多见，https双向中少见。主要预防攻击不要流到业务层。

1.防止错误的报文重复攻击，一般错误报文验签直接可以过滤。

2.防止正确的报文重复攻击

一般在接口或者header中有timestamp/nonce/messageId等字段,这些字段每次请求都会不一致。

推荐使用时戳，如果报文被截获,重放攻击,可能由于timestamp时间和服务器时间相差很远，或者相关nonce字段已经被缓存过，无法通过。

同时可以结合幂等措施，即被处理过的业务不会重复执行。

 

• 实现幂等:

接口中有seqNo字段,可以叫订单号/流水号。

一个seqNo就对应了一次业务下单，同样的流水号无论请求多少次，结果都是一样的，不会重复做。

防止请求在通信中丢失，主要防止timeout类型的异常，请求方无法判断该业务的实际状态，是【请求还未送达就丢了】或【对方处理完毕，处理结果在回程时丢失】

实现幂等后，请求方可以使用相同seqNo进行下单，服务端如果处理过该seqNo订单，就将之前的处理结果返回，如果没处理就收单继续处理。

 

• 提供查询

为什么提供了幂等还要提供查询？

查询和幂等的作用区别就在于，很多时候请求方请求出现异常，没有明确的答案，如果希望业务继续，则可以幂等请求。

例如该用户派发优惠券，如果发生异常则继续幂等派发即可。

如果需要根据实际业务状态决定如何操作，则需要先查询。

例如:很多有时效的业务，抢购业务，用户下单异常，最终没抢到货。

肯定是先查询，如果刚才订单实际成功，则给用户退款。如果刚才订单未成功,则直接关闭业务，这单子不用继续做下去了。

 一般业务查询我们至少提供【成功】【失败】【进行中】三个状态。用于对方处理发生异常时，进行查询使用。

• 异步通知:

下单接口如果是同步接口，肯定没有实现异步通知的必要。

很多下单接口是异步接口，真正的业务状态在同步中无法返回，同步仅仅返回【已收单】，后续查询订单显示【进行中】，直到异步工作完成，订单才会翻转为【成功or失败】。（订单或任务表中有字段记录异步结果及异常，供查询使用）

异步通知的作用：能增强业务的时效性，同时也能减少请求方轮询查询导致的压力。

如果收到明确通知，请求方当即可以触发下一步操作，如果没有通知或通知丢失，请求方只能挂单等待异常处理时主动查询确认状态。

 

• 是否需要对账

一般后端对接的业务接口，基本都需要对账。

对账最大的问题是【跨天】，例如：请求方请求时间为凌晨：23:59:59.但是接收方收到的时间为次日：00:00:04

假如按照T+1对账，那在T日临界点，总可能出现对不平的情况。请求方有该笔账，但是接收方没有。

我们不讨论【勾对】等其他实现方式。

如果可能，在定义接口的时候，可以讨论清楚对账方式及以哪方时间为准。避免后续对账开发困难。

例如：在下单接口中添加objectData字段，以请求方的该字段作为对账时间依据。

 

• 考虑升级

对接的任何一方都有在业务进行中要升级接口的可能。但是要避免需要停服、及互相依赖的局面，例如：大家约定一个时间，半夜你先升级，我在升级。

场景1：公私钥泄露需要更换。

可以在接口中添加keyIndex来标识密钥的版本或者signType字段来标识签名的算法。

这样请求方报文中使用什么版本的密钥，接收方就使用什么版本的密钥解密。互相不依赖。提前配置好即可。

场景2：接口字段升级

下单接口有新增字段，选择升级接口版本号，形成一个新接口。老接口仍保留。接收方先升级，请求方择机升级，互不影响。

查询同理。

 

接口业务策略上有区分的。 一种是完全掌握主动权，一种是将决定权让渡给请求方。

例如：

方式1：派发一个券的时候，有效期是请求方在接口中指定，按照请求方的有效期设定有效期。

方式2：接收方通过产品配置有效期生效策略。

区别在于有效期的生成方式可能是多种多样的，如果将这个能力让渡给请求方，业务变化时，就不用升级。由请求方修改。

 

• 考虑异常

业务异常基本分为3大类：

1.没有明确错误原因。例如对方返回unknow error / inner error 等错误。对方内部可能是异步的，保险起见需要挂单后续查询确认业务状态。

2.有明确错误原因。例如对方返回phoneNo invalid / cardNo error 。无需挂单，直接处理掉。

3.timeout 类型。访问超时是最常见的异常。需要挂单，后续时幂等还是查询在处理，根据业务情况制定。

 

考虑后续多服务及系统需要根据日志定位问题，建议报文中或header中添加类似于traceId 字段。用于后续追踪整条业务链。

 

其他异常：

网络异常、网络波动、今天我灾备、明天他机房维护等。这些单个事件都是小概率，但是这样的事件非常多。

网络异常也导致很多业务异常，我们要充分考虑的异常导致的挂单和中断的情况，做好异常处理和自愈功能。

例如：对账往ftp上投送对账文件。可能网络异常，今天的文件没放上去；或者今天的放上去了，但是出问题需要重新放；可能灾备停了两天，在进行对账等等

ps:不要忽略这些小概率事件，没有预案，只要发生一次，造成的异常业务笔数可能手动处理很久。

 

• 常量管理

 对于很多字典值，建议使用小写中划线模式，不要大小写混合或者驼峰。既然是字典值，来回传输的，如不涉密，建议见名知意，不要使用"魔法数字"，或晦涩难懂的代码。

例如：海尔设备品牌方：device-brand-haier; 

 

• 接口效率

考虑这个接口的负载是很关键的步骤。同步接口压力大点，异步接口可以使用MQ进行削峰填谷相对压力小点。

 

提升效率，控制并发是一个非常庞大的体系。常见的方式：
1.共享数值字段，我们只做累加

2.每个用户独立有一条记录，将并发化解。

4.用插入代替更新，分段锁库存等，使用<=0代替=0，防止极限情况击穿等。

5.分库分表，避免热点表和数据的阻塞。

6.注意风控,报警等情况。

...............

• 接口管理

　　　　最好不要使用文档维护，维护成本很高，推荐使用一个平台进行管理。例如：YApi

 

• 考虑使用和对接成本

如果你不是故意想故弄玄虚，一般接口需要描述使用场景、典型使用案例、可能的情况下使用图形辅助描述。

如有加解密签名或特殊算法等，需要提供示例、源码、或者SDK。减少联调成本。原则上谁定义加密或签名等算法，谁负责提供实现类。不存在口头约定，各自实现，联调在确认，不然联调光对齐这些算法可能要花非常多的时间。

如果有特殊异常或需要关注的点，最好明示及解决方案。

本质：你要站在使用者角度，来描述你的接口如何使用。相当于你已经帮对方做了一个最佳实践。

“防呆式”的开箱即用是好传统。

 

如果你的接口是物联网相关，例如控制设备、远程控制洗衣机、各种设备。建议做一个paas 平台，控制方通过paas与设备进行交互。

而非直接给设备发指令。如果直接和设备直接交互，每个控制方都要开发一套设备管理后台管理，诸如位置、状态、库存等功能，这无形增加了对接的难度和成本。

通过paas平台的后台对接模式，平台可以提供状态、库存、位置等功能，控制方开发更加方便，同时你还可以收取平台使用费，一举多得。

 

选取合适的在线方案文档维护工具，能展示修改记录和版本。

推荐对接的方案及接口使用在线文档或网站等方式，非特殊需要不要使用word，pdf等作为交流方式。 因为方案从制定-讨论-定版-联调-上线等过程中肯定需要频繁修改，

如果通过文档维护，一版一版的更新维护成本很高，而且可能涉及的相关方很多或者对方纵向传达层级很深(例如：总公司-分公司-事业部-小组-外包-最终实现者)。

导致文档同步效率很差，可能每个人手里版本都有差异。

 

 

• 示例：

{
"authCode": "123", 业务认证码
"appCode": "123", 请求方
"deKey":"frfferdfa" 对称密钥加密值
"partnerData": "22", 敏感数据加密值
"seqNo": "123",请求流水
"timestamp": "202107201653123", 时戳
"keyIndex": "1", 加密密钥版本
"sign": "123" 签名
}

 

后端一般都是业务接口，相对来说更加复杂，且参数组成和路径命名没有一个统一的模式，每家都不一样，尤其很多传统厂商。 

前端接口相对规范的多，基本都是RESTFUL风格。

 

前端接口定义示例：

1       获取用户订单详情

接口路径：http://ip:port/sapo/biz/1/0/users/{user-uuid}/orders

请求方法：GET

 

l  说明：查询用户订单详情

l  请求方：小程序

l  接收方：服务端

 

请求头：

Location	Name	Type	Description	Required	Example
Header	authorization	str	用户token	1
Header	Content-Type	str	application/json	1	application/json

 

请求路径参数：

Location	Name	Type	Description	Required	Example
Path	user-uuid	str	用户uuid	1

 

请求参数：

Name	Type	Description	Required	Example
createTime	str	创建时间 [格式:yyyyMMddHHmmss]	1
lastUpdateTime	str	最后更新时间 [格式:yyyyMMddHHmmss]	1/0
status	num	状态：0-无效，1-有效	1	1

 

返回参数：

Name	Type	Description	Required	Example
resCode	str	应答码	1	0000
resDesc	str	应答信息	1/0	success
resData	obj	应答数据	1/0

 

resData结构：

Name	Type	Description	Required	Example
total	num	总个数	1
orderInfoList	list	订单对象实体集合	1

 

orderInfo结构：

Name	Type	Description	Required	Example
createTime	str	创建时间 [格式:yyyyMMddHHmmss]	1
orderNo	str	订单号	1
serviceSpecInfo	obj	[服务规格]对象实体	1
status	num	状态:1-待支付,2-已支付,3-待执行,4-执行中,5-已完成，6-已取消，7-已下单	1	7
expireTime	str	失效时间,格式:yyyyMMddHHmmss	1/0
invoiceFlag	num	是否开过发票标识,0-未开发票,1-已开发票	1	0
totalFee	num	订单总价,单位:分	1
payFee	num	最终支付金额(单位:分)	1/0

 

serviceSpecInfo结构：

Name	Type	Description	Required	Example
code	str	规格类型代码	1
name	str	规格名(30分钟速洗\20分钟烘干)	1
detail	str	规格描述(30分钟速洗\20分钟烘干)	1/0

 

请求示例：

GET   192.168.1.11:9032/sapo/biz/1/0/users/123/orders

返回示例：

{

    "resCode": "0000",

    "resDesc": "success",

    "resData": {

        "total": 2,

        "orderInfoList": [

            {

                "createTime": "20220517194521",

                "deviceExeRemainTime": 23,

                "expireTime": null,

                "orderNo": "456",

                "payFee": 0,

                "serviceSpecInfo": {

                    "code": "washSpec1",

                    "detail": null,

                    "name": "washSpec1"

                },

                "status": 1,

                "totalFee": 0

            }

        ]

    }

}

 

 

本文来自博客园，作者：wanglifeng，转载请注明原文链接：https://www.cnblogs.com/wanglifeng717/p/16213202.html