前言

在实际工作中，我们经常需要在项目中调用第三方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接口超时问题，除了给他们反馈问题，优化接口性能之外，我们更有效的方式，可能是增加接口调用的 失败重试机制 .

例如:

                        
                          int retryCount=0;
                          

                          do {
                          

                             try {
                          

                                doPost();
                          

                                break;
                          

                             } catch(Exception e) {
                          

                               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字段没有什么用，接口文档和接口逻辑不一致.

这个问题估计好多小伙伴都遇到过.

如果要解决这个问题，主要的方案有两种:

1. 第三方平台按文档修改接口逻辑，返回删除状态。
2. 我们系统在调用分类查询接口之后，根据分类code判断，如果数据库中有些分类的code不在接口返回值中，则删除这些分类。

13 欠费了

我们调用过百度的票据识别接口，可以自动识别发票信息，获取发票编号和金额等信息.

之前是另外一个同事对接的接口，后来他离职了.

发票识别功能上线，使用了很长一段时间，一直都没有出问题.

后来，某一天，生产环境用户反馈发票识别不了了.

我查询了相关服务的日志，没有发现异常，这就奇怪了.

打开代码仔细看了一下，发现那位同事的代码中调用第三方的API接口，接收响应数据时，直接转换成了对象，没有打印当时返回的字符串.

莫非，接口返回值有问题?

后来，我增加了日志，打印出了该接口真正的返回内容值.

原因一下查到了，原来是欠费了.

如果出现该了异常，百度的API接口返回的数据结构，用之前那位同事的实体有些参数没法获取到.

这是一个不小的坑.

我们在接收第三方API接口返回数据时，尽可能先用字符串接收返回值，然后将字符串转换成相应实体类，一定要将该返回值在日志中打印出来，方便后面定位问题.

不要直接用实体对象接收返回值，有些API接口，如果出现不同的异常，返回的数据结构差异比较大.

有些异常结果可能是他们网关系统直接返回的，有些异常是他们业务系统返回的.

其实，我们之前还遇到过其他坑，比如：调用分类树查询接口，但第三方返回的数据有重复的id，我们这边该如何处理这种异常数据呢?

我们在job中循环调用第三方API接口获取数据，如果其中某一次调用失败了，是try/catch捕获异常呢？继续执行后面的调用，还是直接终止当前的程序？如果try/catch如何保证数据一致性？终止当前程序，该如何处理后续的流程?

  。

最后此篇关于我调用第三方接口遇到的13大坑的文章就讲到这里了,如果你想了解更多关于我调用第三方接口遇到的13大坑的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。