前言
在實際工作中，我們經(jīng)常需要在項目中調(diào)用第三方API接口，獲取數(shù)據(jù)，或者上報數(shù)據(jù)，進(jìn)行數(shù)據(jù)交換和通信。
那么，調(diào)用第三方API接口會遇到哪些問題？如何解決這些問題呢？
這篇文章就跟大家一起聊聊第三方API接口的話題，希望對你會有所幫助。
1、域名訪問不到
一般我們在第一次對接第三方平臺的API接口時，可能會先通過瀏覽器或者postman調(diào)用一下，該接口是否可以訪問。
有些人可能覺得多次一舉。
其實不然。
有可能你調(diào)用第三方平臺的API接口時，他們的接口真的掛了，他們還不知道。
還有一種最重要的情況，就是你的工作網(wǎng)絡(luò)，是否可以訪問這個外網(wǎng)的接口。
有些公司為了安全考慮，對內(nèi)網(wǎng)的開發(fā)環(huán)境，是設(shè)置了防火墻的，或者有一些其他的限制，有些ip白名單，只能訪問一些指定的外網(wǎng)接口。
如果你發(fā)現(xiàn)你訪問的域名，在開發(fā)環(huán)境訪問不通，就要到運維同學(xué)給你添加ip白名單了。
2、簽名錯誤
很多第三方API接口為了防止別人篡改數(shù)據(jù)，通常會增加數(shù)字簽名(sign)的驗證。
sign = md5(多個參數(shù)拼接 + 密鑰)
在剛開始對接第三方平臺接口時，會遇到參數(shù)錯誤，簽名錯誤等問題。
其中參數(shù)錯誤比較好解決，重點是簽名錯誤這個問題。
簽名是由一些算法生成的。
比如：將參數(shù)名和參數(shù)值用冒號拼接，如果有多個參數(shù)，則按首字母排序，然后再將多個參數(shù)一起拼接。然后加鹽（即：密鑰），再通過md5，生成一個簽名。
如果有多個參數(shù)，你是按首字母倒序的，則最后生成的簽名會出問題。
如果你開發(fā)環(huán)境的密鑰，用的生產(chǎn)環(huán)境的，也可能會導(dǎo)致生產(chǎn)的簽名出現(xiàn)問題。
如果第三方平臺要求最后3次md5生成簽名，而你只用了1次，也可能會導(dǎo)致生產(chǎn)的簽名出現(xiàn)問題。
因此，接口簽名在接口聯(lián)調(diào)時是比較麻煩的事情。
如果第三方平臺有提供sdk生成簽名是最好的，如果沒有，就只能根據(jù)他們文檔手寫簽名算法了。
3、簽名過期
通過上面一步，我們將簽名調(diào)通了，可以正常訪問第三方平臺獲取數(shù)據(jù)了。
但你可能會發(fā)現(xiàn)，同一個請求，15分鐘之后，再獲取數(shù)據(jù)，卻返回失敗了。
第三方平臺在設(shè)計接口時，在簽名中增加了時間戳校驗，同一個請求在15分鐘之內(nèi)，允許返回數(shù)據(jù)。如果超過了15分鐘，則直接返回失敗。
這種設(shè)計是為了安全考慮。
防止有人利用工具進(jìn)行暴力破解，不停偽造簽名，不停調(diào)用接口校驗，如果一直窮舉下去的話，總有一天可以校驗通過的。
sign = md5(多個參數(shù)拼接 + 密鑰 + 時間戳)
因此，有必要增加時間戳的校驗。
如果出現(xiàn)這種情況，不要慌，重新發(fā)起一次新的請求即可。
4、接口突然沒返回數(shù)據(jù)
如果你調(diào)用第三方平臺的某個API接口查詢數(shù)據(jù)，剛開始一直都有數(shù)據(jù)返回。
但突然某一天沒返回數(shù)據(jù)了。
但是該API接口能夠正常響應(yīng)。
不要感到意外，有可能是第三方平臺將數(shù)據(jù)刪除了。
我對接完第三方平臺的API接口后，部署到了測試環(huán)境，發(fā)現(xiàn)他們接口竟然沒有返回數(shù)據(jù)，原因是他們有一天將測試環(huán)境的數(shù)據(jù)刪完了。
因此，在部署測試環(huán)境之前，要先跟對方溝通，要用哪些數(shù)據(jù)測試，不能刪除。
5、token失效
有些平臺的API接口在請求之前，先要調(diào)用另外一個API接口獲取token，然后再header中攜帶該token信息才能訪問其他的業(yè)務(wù)API接口。
在獲取token的API接口中，我們需要傳入賬號、密碼和密鑰等信息。每個接口對接方，這些信息都不一樣。
我們在請求其他的API接口之前，每次都實時調(diào)用一次獲取token的接口獲取token？還是請求一次token，將其緩存到redis中，后面直接從redis獲取數(shù)據(jù)呢？
很顯然我們更傾向于后者，因為如果每次請求其他的API接口之前，都實時調(diào)用一次獲取token的接口獲取token，這樣每次都會請求兩次接口，性能上會有一些影響。
如果將請求的token，保存到redis，又會出現(xiàn)另外一個問題：token失效的問題。
我們調(diào)用第三方平臺獲取token的接口獲取到的token，一般都有個有效期，比如：1天，1個月等。
在有效期內(nèi)，該API接口能夠正常訪問。如果超過了token的有效期，則該API接口不允許訪問。
好辦，我們把redis的失效時間設(shè)置成跟token的有效期一樣不就OK了？
想法是不錯，但是有問題。
你咋保證，你們系統(tǒng)的服務(wù)器時間，跟第三方平臺的服務(wù)器時間一模一樣？
我之前遇到過某大廠，提供了獲取token接口，在30天內(nèi)發(fā)起請求，每次都返回相同的token值。如果超過了30天，則返回一個新的。
有可能出現(xiàn)這種情況，你們系統(tǒng)的服務(wù)器時間要快一些，第三方平臺的時間要慢一些。結(jié)果到了30天，你們系統(tǒng)調(diào)用第三方平臺的獲取token接口獲取到了token還是老的token，更新到redis中了。
過一段時間，token失效了，你們系統(tǒng)還是用老的token訪問第三方平臺的其他API接口，一直都返回失敗。但獲取新的token卻要等30天，這個時間太漫長了。
為了解決這個問題，需要捕獲token失效的異常。如果在調(diào)用其他的API接口是發(fā)現(xiàn)token失效了，馬上請求一次獲取token接口，將新的token立刻更新到redis中。
這樣基本可以解決token失效問題，也能盡可能保證訪問其他接口的穩(wěn)定性和性能。
6、接口超時
系統(tǒng)上線之后，調(diào)用第三方API接口，最容易出現(xiàn)的問題，應(yīng)該是??接口超時??問題了。
系統(tǒng)到外部系統(tǒng)之間，有一條很復(fù)雜的鏈路，中間有很多環(huán)節(jié)出現(xiàn)問題，都可能影響API接口的相應(yīng)時間。
作為API接口的調(diào)用方，面對第三方API接口超時問題，除了給他們反饋問題，優(yōu)化接口性能之外，我們更有效的方式，可能是增加接口調(diào)用的失敗重試機(jī)制。
例如：
int retryCount=0;
do {
try {
doPost();
break;
} catch(Exception e) {
log.warn("接口調(diào)用失敗")
retryCount++;
}
} where (retryCount <= 3)
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
如果接口調(diào)用失敗，則程序會立刻自動重試3次。
如果重試之后成功了，則該API接口調(diào)用成功。
如果重試3次之后還是失敗，則該API接口調(diào)用失敗。
7、接口返回500
調(diào)用第三方API接口，偶爾因為參數(shù)的不同，可能會出現(xiàn)500的問題。
比如：有些API接口對于參數(shù)校驗不到位，少部分必填字段，沒有校驗不能為空。
剛好系統(tǒng)的有些請求，通過某個參數(shù)去調(diào)用該API接口時，沒有傳入那個參數(shù)，對方可能會出現(xiàn)NPE問題。而該接口的返回code，很可能是500。
還有一種情況，就是該API接口的內(nèi)部bug，傳入不同的參數(shù)，走了不同的條件分支邏輯，在走某個分支時，接口邏輯出現(xiàn)異常，可能會導(dǎo)致接口返回500。
這種情況做接口重試也沒用，只能聯(lián)系第三方API接口提供者，反饋相關(guān)問題，讓他們排查具體原因。
他們可能會通過修復(fù)bug，或者修復(fù)數(shù)據(jù)，來解決這個問題。
8、接口返回404
如果你在系統(tǒng)日志中發(fā)現(xiàn)調(diào)用的第三方API接口返回了404，這就非常坑了。
如果第三方的API接口沒有上線，很可能是他們把接口名改了，沒有及時通知你。
這種情況，可以錘他們了。
還有一種情況是，如果第三方的API接口已經(jīng)上線了，剛開始接口是能正常調(diào)用的。
第三方也沒有改過接口地址。
后來，突然有一天發(fā)現(xiàn)調(diào)用第三方的API接口還是出現(xiàn)了404問題。
這種情況很可能是他們網(wǎng)關(guān)出問題了，最新的配置沒有生效，或者改了網(wǎng)關(guān)配置導(dǎo)致的問題。
總之一個字：坑。
9、接口返回少數(shù)據(jù)了
之前我調(diào)過一個第三方的API接口分頁查詢數(shù)據(jù)，接入非常順利，但后來上線之后，發(fā)現(xiàn)他們的接口少數(shù)據(jù)了。
一查原因發(fā)現(xiàn)是該分頁查詢接口，返回的總頁數(shù)不對，比實際情況少了。
有些小伙伴可能會好奇，這么詭異的問題我是怎么發(fā)現(xiàn)？
之前調(diào)用第三方API接口分頁查詢分類數(shù)據(jù)，保存到我們的第三方分類表中。
突然有一天，產(chǎn)品反饋說，第三方有個分類在分類樹中找不到。
我確認(rèn)之后，發(fā)現(xiàn)竟然是真的沒有。
從調(diào)用第三方API接口的響應(yīng)日志中，也沒有查到該分類的數(shù)據(jù)。
這個API接口是分頁查詢接口，目前已經(jīng)分了十幾頁查詢數(shù)據(jù)，但還是沒有查到我們想要的分類。
之前的做法是先調(diào)用一次API接口查詢第一頁的數(shù)據(jù)，同時查出總頁數(shù)。然后再根據(jù)總頁數(shù)循環(huán)調(diào)用，查詢其他頁的數(shù)據(jù)。
我當(dāng)時猜測，可能是他們接口返回的總頁數(shù)有問題。
于是，可以將接口調(diào)用邏輯改成這樣的：
- 從第一頁開始，后面每調(diào)用一次API接口查數(shù)據(jù)，頁數(shù)就加1。然后判斷接口返回的數(shù)據(jù)是否小于pageSize，
- 如果不小于，則進(jìn)行下一次調(diào)用。
- 如果小于，則說明已經(jīng)是最后一頁了，可以停止后續(xù)調(diào)用了。
驗證之后發(fā)現(xiàn)這樣果然可以獲取那個分類的數(shù)據(jù)，只能說明第三方的分頁查詢接口返回的總頁數(shù)比實際情況小了。
10、偷偷改參數(shù)了
我之前調(diào)用過某平臺的API接口獲取指標(biāo)的狀態(tài)，之前根據(jù)雙方約定的狀態(tài)有：正常和禁用 兩種。
然后將狀態(tài)更新到我們的指標(biāo)表中。
后來，雙方系統(tǒng)上線運行了好幾個月。
突然有一天，用戶反饋說某一條數(shù)據(jù)明明刪除了，為什么在頁面上還是可以查到。
此時，我查我們這邊的指標(biāo)表，發(fā)現(xiàn)狀態(tài)是正常的。
然后查看調(diào)用該平臺的API接口日志，發(fā)現(xiàn)返回的該指標(biāo)的狀態(tài)是：下架。
what？
這是什么狀態(tài)？
跟該平臺的開發(fā)人員溝通后，發(fā)現(xiàn)他們改了狀態(tài)的枚舉，增加了：上架、下架等多個值，而且沒有通知我們。
這就坑了。
我們這邊的代碼中判斷，如果狀態(tài)非禁用狀態(tài)，都認(rèn)為是正常狀態(tài)。
而下架狀態(tài)，自動被判斷為正常狀態(tài)。
經(jīng)過跟對方溝通后，他們確認(rèn)下架狀態(tài)，是非正常狀態(tài)，不應(yīng)該顯示指標(biāo)。他們改了數(shù)據(jù)，臨時解決了該指標(biāo)的問題。
后來，他們按接口文檔又改回了之前的狀態(tài)枚舉值。
11、接口時好時壞
不知道你在調(diào)用第三方接口時，有沒有遇到過接口時好時壞的情況。
5分鐘前，該接口還能正常返回數(shù)據(jù)。
5分鐘后，該接口返回503不可用。
又過了幾分鐘，該接口又能正常返回數(shù)據(jù)了。
這種情況大概率是第三方平臺在重啟服務(wù)，在重啟的過程中，可能會出現(xiàn)服務(wù)暫時不可用的情況。
還有另外一種情況：第三方接口部署了多個服務(wù)節(jié)點，有一部分服務(wù)節(jié)點掛了。也會導(dǎo)致請求第三方接口時，返回值時好時壞的情況。
此外還有一種情況：網(wǎng)關(guān)的配置沒有及時更新，沒有把已經(jīng)下線的服務(wù)剔除掉。
這樣用戶請求經(jīng)過網(wǎng)關(guān)時，網(wǎng)關(guān)轉(zhuǎn)發(fā)到了已經(jīng)下線的服務(wù)，導(dǎo)致服務(wù)不可用。網(wǎng)關(guān)轉(zhuǎn)發(fā)請求到正常的服務(wù)，該服務(wù)能夠正常返回。
如果遇到該問題，要盡快將問題反饋給第三方平臺，然后增加接口失敗重試機(jī)制。
12、文檔和接口邏輯不一致
之前還遇到一個第三方平臺提供的API查詢接口，接口文檔中明確寫明了有個??dr??字段表示??刪除狀態(tài)??。
有了這個字段，我們在同步第三方平臺的分類數(shù)據(jù)時，就能夠知道有哪些數(shù)據(jù)是被刪除的，后面可以及時調(diào)整我們這邊的數(shù)據(jù)，將相關(guān)的數(shù)據(jù)也做刪除處理。
后來發(fā)現(xiàn)有些分類，他們那邊已經(jīng)刪除了，但是我們這邊卻沒刪除。
這是啥情況呢？
代碼邏輯很簡單，我review了一下代碼，也沒有bug，為什么會出現(xiàn)這種情況呢？
追查日志之后發(fā)現(xiàn)，調(diào)用第三方平臺獲取分類接口時，對方并沒有把已刪除的分類數(shù)據(jù)返回給我們。
也就是說接口文檔中的那個dr字段沒有什么用，接口文檔和接口邏輯不一致。
這個問題估計好多小伙伴都遇到過。
如果要解決這個問題，主要的方案有兩種：
- 第三方平臺按文檔修改接口邏輯，返回刪除狀態(tài)。
- 我們系統(tǒng)在調(diào)用分類查詢接口之后，根據(jù)分類code判斷，如果數(shù)據(jù)庫中有些分類的code不在接口返回值中，則刪除這些分類。
13、欠費了
我們調(diào)用過百度的票據(jù)識別接口，可以自動識別發(fā)票信息，獲取發(fā)票編號和金額等信息。
之前是另外一個同事對接的接口，后來他離職了。
發(fā)票識別功能上線，使用了很長一段時間，一直都沒有出問題。
后來，某一天，生產(chǎn)環(huán)境用戶反饋發(fā)票識別不了了。
我查詢了相關(guān)服務(wù)的日志，沒有發(fā)現(xiàn)異常，這就奇怪了。
打開代碼仔細(xì)看了一下，發(fā)現(xiàn)那位同事的代碼中調(diào)用第三方的API接口，接收響應(yīng)數(shù)據(jù)時，直接轉(zhuǎn)換成了對象，沒有打印當(dāng)時返回的字符串。
莫非，接口返回值有問題？
后來，我增加了日志，打印出了該接口真正的返回內(nèi)容值。
原因一下查到了，原來是欠費了。
如果出現(xiàn)該了異常，百度的API接口返回的數(shù)據(jù)結(jié)構(gòu)，用之前那位同事的實體有些參數(shù)沒法獲取到。
這是一個不小的坑。
我們在接收第三方API接口返回數(shù)據(jù)時，盡可能先用字符串接收返回值，然后將字符串轉(zhuǎn)換成相應(yīng)實體類，一定要將該返回值在日志中打印出來，方便后面定位問題。
不要直接用實體對象接收返回值，有些API接口，如果出現(xiàn)不同的異常，返回的數(shù)據(jù)結(jié)構(gòu)差異比較大。
有些異常結(jié)果可能是他們網(wǎng)關(guān)系統(tǒng)直接返回的，有些異常是他們業(yè)務(wù)系統(tǒng)返回的。
其實，我們之前還遇到過其他坑，比如：調(diào)用分類樹查詢接口，但第三方返回的數(shù)據(jù)有重復(fù)的id，我們這邊該如何處理這種異常數(shù)據(jù)呢？
我們在job中循環(huán)調(diào)用第三方API接口獲取數(shù)據(jù)，如果其中某一次調(diào)用失敗了，是try/catch捕獲異常呢？繼續(xù)執(zhí)行后面的調(diào)用，還是直接終止當(dāng)前的程序？如果try/catch如何保證數(shù)據(jù)一致性？終止當(dāng)前程序，該如何處理后續(xù)的流程？
