查看原文
其他

我调用第三方接口遇到的13大坑

脚本之家 2023-09-03

The following article is from 苏三说技术 Author 苏三呀

 关注脚本之家”,与百万开发者在一起
来源 | 苏三说技术 (ID:susanSayJava)
已获得原公众号的授权转载

前言

在实际工作中,我们经常需要在项目中调用第三方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如何保证数据一致性?终止当前程序,该如何处理后续的流程?
<END>

程序员专属T恤

商品直购链接 👇


  推荐阅读:
这是一件程序员才懂的T恤
聊聊接口性能优化的11个小技巧
这么写接口,同事都爱跟你合作!
编译器大佬Chris Lattner全新编程语言「Mojo」:兼容Python核心功能,提速35000倍
30年老代码被干掉!微软用18万行 Rust 改写 Windows 系统内核
Office 2019/2021专业增强版,正版终身授权!

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存