我调用第三方接口遇到的13大坑( 二 ) _接口

想法是不错，但是有问题。
你咋保证，你们系统的服务器时间，跟第三方平台的服务器时间一模一样？
我之前遇到过某大厂，提供了获取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接口查询第一页的数据，同时查出总页数。然后再根据总页数循环调用，查询其他页的数据。
我当时猜测，可能是他们接口返回的总页数有问题。
于是，可以将接口调用逻辑改成这样的：