前言
在实践工作中，咱们经常需要在项目中调用第三方API接口，获取数据，或许上报数据，进行数据交换和通信。
那么，调用第三方API接口会遇到哪些问题？怎样处理这些问题呢？
这篇文章就跟大家一同聊聊第三方API接口的话题，希望对你会有所协助。
1 域名拜访不到
一般咱们在第一次对接第三方渠道的API接口时，或许会先通过浏览器或许postman调用一下，该接口是否能够拜访。
有些人或许觉得屡次一举。
其实不然。
有或许你调用第三方渠道的API接口时，他们的接口真的挂了，他们还不知道。
还有一种最重要的状况，就是你的工作网络，是否能够拜访这个外网的接口。
有些公司为了安全考虑，对内网的开发环境，是设置了防火墙的，或许有一些其他的约束，有些ip白名单，只能拜访一些指定的外网接口。
假如你发现你拜访的域名，在开发环境拜访不通，就要到运维同学给你添加ip白名单了。
2 签名过错
很多第三方API接口为了防止别人篡改数据，通常会添加数字签名(sign)的验证。
sign = md5(多个参数拼接 + 密钥)
在刚开端对接第三方渠道接口时，会遇到参数过错，签名过错等问题。
其中参数过错比较好处理，重点是签名过错这个问题。
签名是由一些算法生成的。
比方：将参数名和参数值用冒号拼接，假如有多个参数，则按首字母排序，然后再将多个参数一同拼接。然后加盐（即：密钥），再通过md5，生成一个签名。
假如有多个参数，你是按首字母倒序的，则最终生成的签名会出问题。
假如你开发环境的密钥，用的出产环境的，也或许会导致出产的签名呈现问题。
假如第三方渠道要求最终3次md5生成签名，而你只用了1次，也或许会导致出产的签名呈现问题。
因而，接口签名在接口联调时是比较费事的事情。
假如第三方渠道有供给sdk生成签名是最好的，假如没有，就只能依据他们文档手写签名算法了。
3 签名过期
通过上面一步，咱们将签名调通了，能够正常拜访第三方渠道获取数据了。
但你或许会发现，同一个恳求，15分钟之后，再获取数据，却回来失利了。
第三方渠道在规划接口时，在签名中添加了时刻戳校验，同一个恳求在15分钟之内，答应回来数据。假如超过了15分钟，则直接回来失利。
这种规划是为了安全考虑。
防止有人使用工具进行暴力破解，不断伪造签名，不断调用接口校验，假如一向穷举下去的话，总有一天能够校验通过的。
sign = md5(多个参数拼接 + 密钥 + 时刻戳)
因而，有必要添加时刻戳的校验。
假如呈现这种状况，不要慌，从头建议一次新的恳求即可。
4 接口忽然没回来数据
假如你调用第三方渠道的某个API接口查询数据，刚开端一向都有数据回来。
但忽然某一天没回来数据了。
可是该API接口能够正常呼应。
不要感到意外，有或许是第三方渠道将数据删去了。
我对接完第三方渠道的API接口后，部署到了测验环境，发现他们接口竟然没有回来数据，原因是他们有一天将测验环境的数据删完了。
因而，在部署测验环境之前，要先跟对方沟通，要用哪些数据测验，不能删去。
5 token失效
有些渠道的API接口在恳求之前，先要调用别的一个API接口获取token，然后再header中带着该token信息才干拜访其他的事务API接口。
在获取token的API接口中，咱们需要传入账号、暗码和密钥等信息。每个接口对接方，这些信息都不相同。
咱们在恳求其他的API接口之前，每次都实时调用一次获取token的接口获取token？仍是恳求一次token，将其缓存到redis中，后边直接从redis获取数据呢？
很显然咱们更倾向于后者，由于假如每次恳求其他的API接口之前，都实时调用一次获取token的接口获取token，这样每次都会恳求两次接口，性能上会有一些影响。
假如将恳求的token，保存到redis，又会呈现别的一个问题：token失效的问题。
咱们调用第三方渠道获取token的接口获取到的token，一般都有个有效期，比方：1天，1个月等。
在有效期内，该API接口能够正常拜访。假如超过了token的有效期，则该API接口不答应拜访。
好办，咱们把redis的失效时刻设置成跟token的有效期相同不就OK了？
主意是不错，可是有问题。
你咋确保，你们体系的服务器时刻，跟第三方渠道的服务器时刻一模相同？
我之前遇到过某大厂，供给了获取token接口，在30天内建议恳求，每次都回来相同的token值。假如超过了30天，则回来一个新的。
有或许呈现这种状况，你们体系的服务器时刻要快一些，第三方渠道的时刻要慢一些。成果到了30天，你们体系调用第三方渠道的获取token接口获取到了token仍是老的token，更新到redis中了。
过一段时刻，token失效了，你们体系仍是用老的token拜访第三方渠道的其他API接口，一向都回来失利。但获取新的token却要等30天，这个时刻太漫长了。
为了处理这个问题，需要捕获token失效的反常。假如在调用其他的API接口是发现token失效了，马上恳求一次获取token接口，将新的token马上更新到redis中。
这样基本能够处理token失效问题，也能尽或许确保拜访其他接口的稳定性和性能。
6 接口超时
体系上线之后，调用第三方API接口，最容易呈现的问题，应该是接口超时问题了。
体系到外部体系之间，有一条很复杂的链路，中间有很多环节呈现问题，都或许影响API接口的相应时刻。
作为API接口的调用方，面临第三方API接口超时问题，除了给他们反应问题，优化接口性能之外，咱们更有效的方式，或许是添加接口调用的失利重试机制。
例如：
intretryCount=0;
do{
try{
doPost();
break;
}catch(Exceptione){
log.warn("接口调用失利")
retryCount++;
}
}where(retryCount<=3)
假如接口调用失利，则程序会马上主动重试3次。
假如重试之后成功了，则该API接口调用成功。
假如重试3次之后仍是失利，则该API接口调用失利。
7 接口回来500
调用第三方API接口，偶尔由于参数的不同，或许会呈现500的问题。
比方：有些API接口对于参数校验不到位，少部分必填字段，没有校验不能为空。
刚好体系的有些恳求，通过某个参数去调用该API接口时，没有传入那个参数，对方或许会呈现NPE问题。而该接口的回来code，很或许是500。
还有一种状况，就是该API接口的内部bug，传入不同的参数，走了不同的条件分支逻辑，在走某个分支时，接口逻辑呈现反常，或许会导致接口回来500。
这种状况做接口重试也没用，只能联络第三方API接口供给者，反应相关问题，让他们排查具体原因。
他们或许会通过修正bug，或许修正数据，来处理这个问题。
8 接口回来404
假如你在体系日志中发现调用的第三方API接口回来了404，这就十分坑了。
假如第三方的API接口没有上线，很或许是他们把接口名改了，没有及时通知你。
这种状况，能够锤他们了。
还有一种状况是，假如第三方的API接口现已上线了，刚开端接口是能正常调用的。
第三方也没有改正接口地址。
后来，忽然有一天发现调用第三方的API接口仍是呈现了404问题。
这种状况很或许是他们网关出问题了，最新的装备没有生效，或许改了网关装备导致的问题。
总归一个字：坑。
9 接口回来少数据了
之前我调过一个第三方的API接口分页查询数据，接入十分顺畅，但后来上线之后，发现他们的接口少数据了。
一查原因发现是该分页查询接口，回来的总页数不对，比实践状况少了。
有些小伙伴或许会好奇，这么诡异的问题我是怎样发现？
之前调用第三方API接口分页查询分类数据，保存到咱们的第三方分类表中。
忽然有一天，产品反应说，第三方有个分类在分类树中找不到。
我承认之后，发现竟然是真的没有。
从调用第三方API接口的呼应日志中，也没有查到该分类的数据。
这个API接口是分页查询接口，现在现已分了十几页查询数据，但仍是没有查到咱们想要的分类。
之前的做法是先调用一次API接口查询第一页的数据，同时查出总页数。然后再依据总页数循环调用，查询其他页的数据。
我当时猜想，或许是他们接口回来的总页数有问题。
所以，能够将接口调用逻辑改成这样的：
- 从第一页开端，后边每调用一次API接口查数据，页数就加1。然后判别接口回来的数据是否小于pageSize，
- 假如不小于，则进行下一次调用。
- 假如小于，则说明现已是最终一页了，能够中止后续调用了。
验证之后发现这样公然能够获取那个分类的数据，只能说明第三方的分页查询接口回来的总页数比实践状况小了。
10 偷偷改参数了
我之前调用过某渠道的API接口获取目标的状况，之前依据两边约定的状况有：正常和禁用两种。
然后将状况更新到咱们的目标表中。
后来，两边体系上线运行了好几个月。
忽然有一天，用户反应说某一条数据明明删去了，为什么在页面上仍是能够查到。
此时，我查咱们这边的目标表，发现状况是正常的。
然后查看调用该渠道的API接口日志，发现回来的该目标的状况是：下架。
what？
这是什么状况？
跟该渠道的开发人员沟通后，发现他们改了状况的枚举，添加了：上架、下架等多个值，并且没有通知咱们。
这就坑了。
咱们这边的代码中判别，假如状况非禁用状况，都认为是正常状况。
而下架状况，主动被判别为正常状况。
通过跟对方沟通后，他们承认下架状况，是非正常状况，不应该显示目标。他们改了数据，临时处理了该目标的问题。
后来，他们按接口文档又改回了之前的状况枚举值。
11 接口时好时坏
不知道你在调用第三方接口时，有没有遇到过接口时好时坏的状况。
5分钟前，该接口还能正常回来数据。
5分钟后，该接口回来503不可用。
又过了几分钟，该接口又能正常回来数据了。
这种状况大概率是第三方渠道在重启服务，在重启的过程中，或许会呈现服务暂时不可用的状况。
还有别的一种状况：第三方接口部署了多个服务节点，有一部分服务节点挂了。也会导致恳求第三方接口时，回来值时好时坏的状况。
此外还有一种状况：网关的装备没有及时更新，没有把现已下线的服务剔除去。
这样用户恳求通过网关时，网关转发到了现已下线的服务，导致服务不可用。网关转发恳求到正常的服务，该服务能够正常回来。
假如遇到该问题，要尽快将问题反应给第三方渠道，然后添加接口失利重试机制。
12 文档和接口逻辑不一致
之前还遇到一个第三方渠道供给的API查询接口，接口文档中清晰写明了有个dr字段表明删去状况。
有了这个字段，咱们在同步第三方渠道的分类数据时，就能够知道有哪些数据是被删去的，后边能够及时调整咱们这边的数据，将相关的数据也做删去处理。
后来发现有些分类，他们那儿现已删去了，可是咱们这边却没删去。
这是啥状况呢？
代码逻辑很简单，我review了一下代码，也没有bug，为什么会呈现这种状况呢？
追查日志之后发现，调用第三方渠道获取分类接口时，对方并没有把已删去的分类数据回来给咱们。
也就是说接口文档中的那个dr字段没有什么用，接口文档和接口逻辑不一致。
这个问题估量好多小伙伴都遇到过。
假如要处理这个问题，首要的方案有两种：
- 第三方渠道按文档修正接口逻辑，回来删去状况。
- 咱们体系在调用分类查询接口之后，依据分类code判别，假如数据库中有些分类的code不在接口回来值中，则删去这些分类。
13 欠费了
咱们调用过百度的收据辨认接口，能够主动辨认发票信息，获取发票编号和金额等信息。
之前是别的一个搭档对接的接口，后来他离职了。
发票辨认功用上线，使用了很长一段时刻，一向都没有出问题。
后来，某一天，出产环境用户反应发票辨认不了了。
我查询了相关服务的日志，没有发现反常，这就奇怪了。
翻开代码仔细看了一下，发现那位搭档的代码中调用第三方的API接口，接纳呼应数据时，直接转化成了目标，没有打印当时回来的字符串。
难道，接口回来值有问题？
后来，我添加了日志，打印出了该接口真正的回来内容值。
原因一下查到了，原来是欠费了。
假如呈现该了反常，百度的API接口回来的数据结构，用之前那位搭档的实体有些参数没法获取到。
这是一个不小的坑。
咱们在接纳第三方API接口回来数据时，尽或许先用字符串接纳回来值，然后将字符串转化成相应实体类，一定要将该回来值在日志中打印出来，便利后边定位问题。
不要直接用实体目标接纳回来值，有些API接口，假如呈现不同的反常，回来的数据结构差异比较大。
有些反常成果或许是他们网关体系直接回来的，有些反常是他们事务体系回来的。
其实，咱们之前还遇到过其他坑，比方：调用分类树查询接口，但第三方回来的数据有重复的id，咱们这边该怎样处理这种反常数据呢？
咱们在job中循环调用第三方API接口获取数据，假如其中某一次调用失利了，是try/catch捕获反常呢？持续履行后边的调用，仍是直接停止当时的程序？假如try/catch怎样确保数据一致性？停止当时程序，该怎样处理后续的流程？
最终说一句(求重视，别白嫖我)
假如这篇文章对您有所协助，或许有所启示的话，帮忙扫描下发二维码重视一下，您的支撑是我坚持写作最大的动力。
求一键三连：点赞、转发、在看。
重视大众号：【苏三说技能】，在大众号中回复：面试、代码神器、开发手册、时刻管理有超赞的粉丝福利，别的回复：加群，能够跟很多BAT大厂的长辈沟通和学习。
