前言

在實(shí)際工作中，我們經(jīng)常需要在項(xiàng)目中調(diào)用第三方API接口，獲取數(shù)據(jù)，或者上報(bào)數(shù)據(jù)，進(jìn)行數(shù)據(jù)交換和通信。

那么，調(diào)用第三方API接口會(huì)遇到哪些問題？如何解決這些問題呢？

這篇文章就跟大家一起聊聊第三方API接口的話題，希望對(duì)你會(huì)有所幫助。

1、域名訪問不到

一般我們?cè)诘谝淮螌?duì)接第三方平臺(tái)的API接口時(shí)，可能會(huì)先通過瀏覽器或者postman調(diào)用一下，該接口是否可以訪問。

有些人可能覺得多次一舉。

其實(shí)不然。

有可能你調(diào)用第三方平臺(tái)的API接口時(shí)，他們的接口真的掛了，他們還不知道。

還有一種最重要的情況，就是你的工作網(wǎng)絡(luò)，是否可以訪問這個(gè)外網(wǎng)的接口。

有些公司為了安全考慮，對(duì)內(nèi)網(wǎng)的開發(fā)環(huán)境，是設(shè)置了防火墻的，或者有一些其他的限制，有些ip白名單，只能訪問一些指定的外網(wǎng)接口。

如果你發(fā)現(xiàn)你訪問的域名，在開發(fā)環(huán)境訪問不通，就要到運(yùn)維同學(xué)給你添加ip白名單了。

2、簽名錯(cuò)誤

很多第三方API接口為了防止別人篡改數(shù)據(jù)，通常會(huì)增加數(shù)字簽名(sign)的驗(yàn)證。

sign = md5(多個(gè)參數(shù)拼接 + 密鑰)

在剛開始對(duì)接第三方平臺(tái)接口時(shí)，會(huì)遇到參數(shù)錯(cuò)誤，簽名錯(cuò)誤等問題。

其中參數(shù)錯(cuò)誤比較好解決，重點(diǎn)是簽名錯(cuò)誤這個(gè)問題。

簽名是由一些算法生成的。

比如：將參數(shù)名和參數(shù)值用冒號(hào)拼接，如果有多個(gè)參數(shù)，則按首字母排序，然后再將多個(gè)參數(shù)一起拼接。然后加鹽（即：密鑰），再通過md5，生成一個(gè)簽名。

如果有多個(gè)參數(shù)，你是按首字母倒序的，則最后生成的簽名會(huì)出問題。

如果你開發(fā)環(huán)境的密鑰，用的生產(chǎn)環(huán)境的，也可能會(huì)導(dǎo)致生產(chǎn)的簽名出現(xiàn)問題。

如果第三方平臺(tái)要求最后3次md5生成簽名，而你只用了1次，也可能會(huì)導(dǎo)致生產(chǎn)的簽名出現(xiàn)問題。

因此，接口簽名在接口聯(lián)調(diào)時(shí)是比較麻煩的事情。

如果第三方平臺(tái)有提供sdk生成簽名是最好的，如果沒有，就只能根據(jù)他們文檔手寫簽名算法了。

3、簽名過期

通過上面一步，我們將簽名調(diào)通了，可以正常訪問第三方平臺(tái)獲取數(shù)據(jù)了。

但你可能會(huì)發(fā)現(xiàn)，同一個(gè)請(qǐng)求，15分鐘之后，再獲取數(shù)據(jù)，卻返回失敗了。

第三方平臺(tái)在設(shè)計(jì)接口時(shí)，在簽名中增加了時(shí)間戳校驗(yàn)，同一個(gè)請(qǐng)求在15分鐘之內(nèi)，允許返回?cái)?shù)據(jù)。如果超過了15分鐘，則直接返回失敗。

這種設(shè)計(jì)是為了安全考慮。

防止有人利用工具進(jìn)行暴力破解，不停偽造簽名，不停調(diào)用接口校驗(yàn)，如果一直窮舉下去的話，總有一天可以校驗(yàn)通過的。

sign = md5(多個(gè)參數(shù)拼接 + 密鑰 + 時(shí)間戳)

因此，有必要增加時(shí)間戳的校驗(yàn)。

如果出現(xiàn)這種情況，不要慌，重新發(fā)起一次新的請(qǐng)求即可。

4、接口突然沒返回?cái)?shù)據(jù)

如果你調(diào)用第三方平臺(tái)的某個(gè)API接口查詢數(shù)據(jù)，剛開始一直都有數(shù)據(jù)返回。

但突然某一天沒返回?cái)?shù)據(jù)了。

但是該API接口能夠正常響應(yīng)。

不要感到意外，有可能是第三方平臺(tái)將數(shù)據(jù)刪除了。

我對(duì)接完第三方平臺(tái)的API接口后，部署到了測(cè)試環(huán)境，發(fā)現(xiàn)他們接口竟然沒有返回?cái)?shù)據(jù)，原因是他們有一天將測(cè)試環(huán)境的數(shù)據(jù)刪完了。

因此，在部署測(cè)試環(huán)境之前，要先跟對(duì)方溝通，要用哪些數(shù)據(jù)測(cè)試，不能刪除。

5、token失效

有些平臺(tái)的API接口在請(qǐng)求之前，先要調(diào)用另外一個(gè)API接口獲取token，然后再header中攜帶該token信息才能訪問其他的業(yè)務(wù)API接口。

在獲取token的API接口中，我們需要傳入賬號(hào)、密碼和密鑰等信息。每個(gè)接口對(duì)接方，這些信息都不一樣。

我們?cè)谡?qǐng)求其他的API接口之前，每次都實(shí)時(shí)調(diào)用一次獲取token的接口獲取token？還是請(qǐng)求一次token，將其緩存到redis中，后面直接從redis獲取數(shù)據(jù)呢？

很顯然我們更傾向于后者，因?yàn)槿绻看握?qǐng)求其他的API接口之前，都實(shí)時(shí)調(diào)用一次獲取token的接口獲取token，這樣每次都會(huì)請(qǐng)求兩次接口，性能上會(huì)有一些影響。

如果將請(qǐng)求的token，保存到redis，又會(huì)出現(xiàn)另外一個(gè)問題：token失效的問題。

我們調(diào)用第三方平臺(tái)獲取token的接口獲取到的token，一般都有個(gè)有效期，比如：1天，1個(gè)月等。

在有效期內(nèi)，該API接口能夠正常訪問。如果超過了token的有效期，則該API接口不允許訪問。

好辦，我們把redis的失效時(shí)間設(shè)置成跟token的有效期一樣不就OK了？

想法是不錯(cuò)，但是有問題。

你咋保證，你們系統(tǒng)的服務(wù)器時(shí)間，跟第三方平臺(tái)的服務(wù)器時(shí)間一模一樣？

我之前遇到過某大廠，提供了獲取token接口，在30天內(nèi)發(fā)起請(qǐng)求，每次都返回相同的token值。如果超過了30天，則返回一個(gè)新的。

有可能出現(xiàn)這種情況，你們系統(tǒng)的服務(wù)器時(shí)間要快一些，第三方平臺(tái)的時(shí)間要慢一些。結(jié)果到了30天，你們系統(tǒng)調(diào)用第三方平臺(tái)的獲取token接口獲取到了token還是老的token，更新到redis中了。

過一段時(shí)間，token失效了，你們系統(tǒng)還是用老的token訪問第三方平臺(tái)的其他API接口，一直都返回失敗。但獲取新的token卻要等30天，這個(gè)時(shí)間太漫長(zhǎng)了。

為了解決這個(gè)問題，需要捕獲token失效的異常。如果在調(diào)用其他的API接口是發(fā)現(xiàn)token失效了，馬上請(qǐng)求一次獲取token接口，將新的token立刻更新到redis中。

這樣基本可以解決token失效問題，也能盡可能保證訪問其他接口的穩(wěn)定性和性能。

6、接口超時(shí)

系統(tǒng)上線之后，調(diào)用第三方API接口，最容易出現(xiàn)的問題，應(yīng)該是??接口超時(shí)??問題了。

系統(tǒng)到外部系統(tǒng)之間，有一條很復(fù)雜的鏈路，中間有很多環(huán)節(jié)出現(xiàn)問題，都可能影響API接口的相應(yīng)時(shí)間。

作為API接口的調(diào)用方，面對(duì)第三方API接口超時(shí)問題，除了給他們反饋問題，優(yōu)化接口性能之外，我們更有效的方式，可能是增加接口調(diào)用的失敗重試機(jī)制。

例如：

int retryCount=0;
do {
   try {
      doPost();
      break;
   } catch(Exception e) {
     log.warn("接口調(diào)用失敗")
     retryCount++;
   }
} where (retryCount <= 3)

如果接口調(diào)用失敗，則程序會(huì)立刻自動(dòng)重試3次。

如果重試之后成功了，則該API接口調(diào)用成功。

如果重試3次之后還是失敗，則該API接口調(diào)用失敗。

7、接口返回500

調(diào)用第三方API接口，偶爾因?yàn)閰?shù)的不同，可能會(huì)出現(xiàn)500的問題。

比如：有些API接口對(duì)于參數(shù)校驗(yàn)不到位，少部分必填字段，沒有校驗(yàn)不能為空。

剛好系統(tǒng)的有些請(qǐng)求，通過某個(gè)參數(shù)去調(diào)用該API接口時(shí)，沒有傳入那個(gè)參數(shù)，對(duì)方可能會(huì)出現(xiàn)NPE問題。而該接口的返回code，很可能是500。

還有一種情況，就是該API接口的內(nèi)部bug，傳入不同的參數(shù)，走了不同的條件分支邏輯，在走某個(gè)分支時(shí)，接口邏輯出現(xiàn)異常，可能會(huì)導(dǎo)致接口返回500。

這種情況做接口重試也沒用，只能聯(lián)系第三方API接口提供者，反饋相關(guān)問題，讓他們排查具體原因。

他們可能會(huì)通過修復(fù)bug，或者修復(fù)數(shù)據(jù)，來解決這個(gè)問題。

8、接口返回404

如果你在系統(tǒng)日志中發(fā)現(xiàn)調(diào)用的第三方API接口返回了404，這就非常坑了。

如果第三方的API接口沒有上線，很可能是他們把接口名改了，沒有及時(shí)通知你。

這種情況，可以錘他們了。

還有一種情況是，如果第三方的API接口已經(jīng)上線了，剛開始接口是能正常調(diào)用的。

第三方也沒有改過接口地址。

后來，突然有一天發(fā)現(xiàn)調(diào)用第三方的API接口還是出現(xiàn)了404問題。

這種情況很可能是他們網(wǎng)關(guān)出問題了，最新的配置沒有生效，或者改了網(wǎng)關(guān)配置導(dǎo)致的問題。

總之一個(gè)字：坑。

9、接口返回少數(shù)據(jù)了

之前我調(diào)過一個(gè)第三方的API接口分頁查詢數(shù)據(jù)，接入非常順利，但后來上線之后，發(fā)現(xiàn)他們的接口少數(shù)據(jù)了。

一查原因發(fā)現(xiàn)是該分頁查詢接口，返回的總頁數(shù)不對(duì)，比實(shí)際情況少了。

有些小伙伴可能會(huì)好奇，這么詭異的問題我是怎么發(fā)現(xiàn)？

之前調(diào)用第三方API接口分頁查詢分類數(shù)據(jù)，保存到我們的第三方分類表中。

突然有一天，產(chǎn)品反饋說，第三方有個(gè)分類在分類樹中找不到。

我確認(rèn)之后，發(fā)現(xiàn)竟然是真的沒有。

從調(diào)用第三方API接口的響應(yīng)日志中，也沒有查到該分類的數(shù)據(jù)。

這個(gè)API接口是分頁查詢接口，目前已經(jīng)分了十幾頁查詢數(shù)據(jù)，但還是沒有查到我們想要的分類。

之前的做法是先調(diào)用一次API接口查詢第一頁的數(shù)據(jù)，同時(shí)查出總頁數(shù)。然后再根據(jù)總頁數(shù)循環(huán)調(diào)用，查詢其他頁的數(shù)據(jù)。

我當(dāng)時(shí)猜測(cè)，可能是他們接口返回的總頁數(shù)有問題。

于是，可以將接口調(diào)用邏輯改成這樣的：

• 從第一頁開始，后面每調(diào)用一次API接口查數(shù)據(jù)，頁數(shù)就加1。然后判斷接口返回的數(shù)據(jù)是否小于pageSize，
• 如果不小于，則進(jìn)行下一次調(diào)用。
• 如果小于，則說明已經(jīng)是最后一頁了，可以停止后續(xù)調(diào)用了。

驗(yàn)證之后發(fā)現(xiàn)這樣果然可以獲取那個(gè)分類的數(shù)據(jù)，只能說明第三方的分頁查詢接口返回的總頁數(shù)比實(shí)際情況小了。

10、偷偷改參數(shù)了

我之前調(diào)用過某平臺(tái)的API接口獲取指標(biāo)的狀態(tài)，之前根據(jù)雙方約定的狀態(tài)有：正常和禁用 兩種。

然后將狀態(tài)更新到我們的指標(biāo)表中。

后來，雙方系統(tǒng)上線運(yùn)行了好幾個(gè)月。

突然有一天，用戶反饋說某一條數(shù)據(jù)明明刪除了，為什么在頁面上還是可以查到。

此時(shí)，我查我們這邊的指標(biāo)表，發(fā)現(xiàn)狀態(tài)是正常的。

然后查看調(diào)用該平臺(tái)的API接口日志，發(fā)現(xiàn)返回的該指標(biāo)的狀態(tài)是：下架。

what？

這是什么狀態(tài)？

跟該平臺(tái)的開發(fā)人員溝通后，發(fā)現(xiàn)他們改了狀態(tài)的枚舉，增加了：上架、下架等多個(gè)值，而且沒有通知我們。

這就坑了。

我們這邊的代碼中判斷，如果狀態(tài)非禁用狀態(tài)，都認(rèn)為是正常狀態(tài)。

而下架狀態(tài)，自動(dòng)被判斷為正常狀態(tài)。

經(jīng)過跟對(duì)方溝通后，他們確認(rèn)下架狀態(tài)，是非正常狀態(tài)，不應(yīng)該顯示指標(biāo)。他們改了數(shù)據(jù)，臨時(shí)解決了該指標(biāo)的問題。

后來，他們按接口文檔又改回了之前的狀態(tài)枚舉值。

11、接口時(shí)好時(shí)壞

不知道你在調(diào)用第三方接口時(shí)，有沒有遇到過接口時(shí)好時(shí)壞的情況。

5分鐘前，該接口還能正常返回?cái)?shù)據(jù)。

5分鐘后，該接口返回503不可用。

又過了幾分鐘，該接口又能正常返回?cái)?shù)據(jù)了。

這種情況大概率是第三方平臺(tái)在重啟服務(wù)，在重啟的過程中，可能會(huì)出現(xiàn)服務(wù)暫時(shí)不可用的情況。

還有另外一種情況：第三方接口部署了多個(gè)服務(wù)節(jié)點(diǎn)，有一部分服務(wù)節(jié)點(diǎn)掛了。也會(huì)導(dǎo)致請(qǐng)求第三方接口時(shí)，返回值時(shí)好時(shí)壞的情況。

此外還有一種情況：網(wǎng)關(guān)的配置沒有及時(shí)更新，沒有把已經(jīng)下線的服務(wù)剔除掉。

這樣用戶請(qǐng)求經(jīng)過網(wǎng)關(guān)時(shí)，網(wǎng)關(guān)轉(zhuǎn)發(fā)到了已經(jīng)下線的服務(wù)，導(dǎo)致服務(wù)不可用。網(wǎng)關(guān)轉(zhuǎn)發(fā)請(qǐng)求到正常的服務(wù)，該服務(wù)能夠正常返回。

如果遇到該問題，要盡快將問題反饋給第三方平臺(tái)，然后增加接口失敗重試機(jī)制。

12、文檔和接口邏輯不一致

之前還遇到一個(gè)第三方平臺(tái)提供的API查詢接口，接口文檔中明確寫明了有個(gè)??dr??字段表示??刪除狀態(tài)??。

有了這個(gè)字段，我們?cè)谕降谌狡脚_(tái)的分類數(shù)據(jù)時(shí)，就能夠知道有哪些數(shù)據(jù)是被刪除的，后面可以及時(shí)調(diào)整我們這邊的數(shù)據(jù)，將相關(guān)的數(shù)據(jù)也做刪除處理。

后來發(fā)現(xiàn)有些分類，他們那邊已經(jīng)刪除了，但是我們這邊卻沒刪除。

這是啥情況呢？

代碼邏輯很簡(jiǎn)單，我review了一下代碼，也沒有bug，為什么會(huì)出現(xiàn)這種情況呢？

追查日志之后發(fā)現(xiàn)，調(diào)用第三方平臺(tái)獲取分類接口時(shí)，對(duì)方并沒有把已刪除的分類數(shù)據(jù)返回給我們。

也就是說接口文檔中的那個(gè)dr字段沒有什么用，接口文檔和接口邏輯不一致。

這個(gè)問題估計(jì)好多小伙伴都遇到過。

如果要解決這個(gè)問題，主要的方案有兩種：

1. 第三方平臺(tái)按文檔修改接口邏輯，返回刪除狀態(tài)。
2. 我們系統(tǒng)在調(diào)用分類查詢接口之后，根據(jù)分類code判斷，如果數(shù)據(jù)庫(kù)中有些分類的code不在接口返回值中，則刪除這些分類。

13、欠費(fèi)了

我們調(diào)用過百度的票據(jù)識(shí)別接口，可以自動(dòng)識(shí)別發(fā)票信息，獲取發(fā)票編號(hào)和金額等信息。

之前是另外一個(gè)同事對(duì)接的接口，后來他離職了。

發(fā)票識(shí)別功能上線，使用了很長(zhǎng)一段時(shí)間，一直都沒有出問題。

后來，某一天，生產(chǎn)環(huán)境用戶反饋發(fā)票識(shí)別不了了。

我查詢了相關(guān)服務(wù)的日志，沒有發(fā)現(xiàn)異常，這就奇怪了。

打開代碼仔細(xì)看了一下，發(fā)現(xiàn)那位同事的代碼中調(diào)用第三方的API接口，接收響應(yīng)數(shù)據(jù)時(shí)，直接轉(zhuǎn)換成了對(duì)象，沒有打印當(dāng)時(shí)返回的字符串。

莫非，接口返回值有問題？

后來，我增加了日志，打印出了該接口真正的返回內(nèi)容值。

原因一下查到了，原來是欠費(fèi)了。

如果出現(xiàn)該了異常，百度的API接口返回的數(shù)據(jù)結(jié)構(gòu)，用之前那位同事的實(shí)體有些參數(shù)沒法獲取到。

這是一個(gè)不小的坑。

我們?cè)诮邮盏谌紸PI接口返回?cái)?shù)據(jù)時(shí)，盡可能先用字符串接收返回值，然后將字符串轉(zhuǎn)換成相應(yīng)實(shí)體類，一定要將該返回值在日志中打印出來，方便后面定位問題。

不要直接用實(shí)體對(duì)象接收返回值，有些API接口，如果出現(xiàn)不同的異常，返回的數(shù)據(jù)結(jié)構(gòu)差異比較大。

有些異常結(jié)果可能是他們網(wǎng)關(guān)系統(tǒng)直接返回的，有些異常是他們業(yè)務(wù)系統(tǒng)返回的。

其實(shí)，我們之前還遇到過其他坑，比如：調(diào)用分類樹查詢接口，但第三方返回的數(shù)據(jù)有重復(fù)的id，我們這邊該如何處理這種異常數(shù)據(jù)呢？

我們?cè)趈ob中循環(huán)調(diào)用第三方API接口獲取數(shù)據(jù)，如果其中某一次調(diào)用失敗了，是try/catch捕獲異常呢？繼續(xù)執(zhí)行后面的調(diào)用，還是直接終止當(dāng)前的程序？如果try/catch如何保證數(shù)據(jù)一致性？終止當(dāng)前程序，該如何處理后續(xù)的流程？