作者 | Matt Hawk
譯者 | 蘇本如，責(zé)編 | 郭芮
頭圖 | CSDN 下載自東方IC
出品 | CSDN（ID：CSDNnews）
以下為譯文：
想知道API的使用在當(dāng)今的軟件開發(fā)過程中有多普遍？那就去問問工程師們?cè)谒麄兊捻?xiàng)目中集成了多少API吧。大多數(shù)開發(fā)團(tuán)隊(duì)可能不知道確切的答案。然而我們知道，從分析工具到地圖應(yīng)用和云托管，現(xiàn)代應(yīng)用程序都使用了大量的內(nèi)部和外部API。開發(fā)人員們都在使用這些工具來快速組裝應(yīng)用程序，以減少構(gòu)建這些應(yīng)用程序所需要花費(fèi)的時(shí)間和精力。然而，這其中有一個(gè)被遺忘的成本，通常在項(xiàng)目的早期并沒有被考慮到。
當(dāng)你將另一個(gè)API添加到你的軟件中時(shí)，它的影響在最初集成之后的很長一段時(shí)間都能感受到。開發(fā)人員需要維護(hù)和這些外部API的連接，包括在它出現(xiàn)問題時(shí)定位和解決問題。通常情況下，這些問題不會(huì)浮出水面，直到接到用戶的錯(cuò)誤報(bào)告，這對(duì)于大多數(shù)公司來說，已經(jīng)為時(shí)已晚。然而通過應(yīng)用程序構(gòu)建過程只能發(fā)現(xiàn)那些最常出現(xiàn)的中斷性功能錯(cuò)誤。
在本文中，我們將討論API出現(xiàn)錯(cuò)誤時(shí)的用戶體驗(yàn)以及它們的常見程度。同時(shí)，我們還將討論一下我們需要做什么來減少這些API問題。
客戶對(duì)API集成中斷的體驗(yàn)
現(xiàn)代應(yīng)用程序依賴大量的API來為用戶提供高質(zhì)量的功能。無論一個(gè)產(chǎn)品是Web應(yīng)用、桌面應(yīng)用還是移動(dòng)應(yīng)用，無論是在前端還是在后端，開發(fā)人員都會(huì)嚴(yán)重依賴第三方API提供的功能。當(dāng)這些API出現(xiàn)錯(cuò)誤時(shí)，客戶無法區(qū)分哪些錯(cuò)誤屬于開發(fā)人員，哪些錯(cuò)誤屬于第三方。他們看到的只是一個(gè)“壞”掉的應(yīng)用程序。一個(gè)壞的API會(huì)導(dǎo)致糟糕的客戶體驗(yàn)，進(jìn)而導(dǎo)致收入的直接損失。
比如，假設(shè)你正在構(gòu)建一個(gè)新的自行車共享應(yīng)用程序。你需要編寫大量原始代碼，但也可以在現(xiàn)有工具的基礎(chǔ)上進(jìn)行構(gòu)建。事實(shí)上，大多數(shù)開發(fā)人員都不會(huì)嘗試重新創(chuàng)建那些可以通過現(xiàn)有API提供的最常用的基礎(chǔ)設(shè)施。
因此，你的應(yīng)用程序可能需要集成如下服務(wù)：
-
云托管服務(wù)
-
顯示自行車位置的地圖服務(wù)
-
位置換算的地理編碼API
-
支付服務(wù)
-
通信服務(wù)
如果你想共享自行車，顯然你需要知道它們?cè)谀睦铮⑦@些位置信息數(shù)據(jù)共享給用戶。因此，你需要在谷歌地圖上標(biāo)出自行車的位置。根據(jù)你的盈利模式，你甚至可能需要跟蹤用戶的取車地點(diǎn)和目的地之間的距離，以便按距離（英里）收費(fèi)。
在這種情況下，你的應(yīng)用程序也需要一個(gè)支付系統(tǒng)。你可能需要集成Stripe來支持信用卡付款，或者通過集成Plaid（一種金融服務(wù)API，最近被Mastercard收購）來支持銀行卡付款。
即使是最簡單的應(yīng)用程序，你也需要一些附加功能。你可能需要發(fā)送短信或電子郵件的功能。或者集成一個(gè)安全的聊天功能，就像你在Lyft或Craigslist上看到的那樣。同時(shí)，你可以集成SendGrid或MailChimp這樣的服務(wù)來實(shí)現(xiàn)郵件提醒的自動(dòng)化，以便讓你的客戶群保持活躍。
突然間，你發(fā)現(xiàn)自己已經(jīng)坐在一個(gè)龐大復(fù)雜的系統(tǒng)上，它不僅使錯(cuò)誤更難跟蹤和修正，而且意味著你的應(yīng)用程序的功能必須嚴(yán)重依賴無數(shù)的第三方服務(wù)來最小化和跟蹤他們自己的錯(cuò)誤。然而，從用戶的角度來看，應(yīng)用程序的任何一個(gè)組成部分的故障，都意味著整個(gè)應(yīng)用程序的故障。
開發(fā)人員會(huì)頻繁地監(jiān)控自己開發(fā)的系統(tǒng)的性能并及時(shí)解決發(fā)生的問題。這包括編寫單元測(cè)試、償還技術(shù)債務(wù)和經(jīng)常重新評(píng)估功能。另外，他們可能會(huì)引入質(zhì)量保證團(tuán)隊(duì)來發(fā)現(xiàn)用戶的體驗(yàn)問題。
然而，許多開發(fā)團(tuán)隊(duì)并沒有采取相應(yīng)的措施來對(duì)他們使用的外部API進(jìn)行同樣的監(jiān)控和分析。缺乏這些措施，他們很容易忽視外部API對(duì)用戶體驗(yàn)的影響。對(duì)于和外部API的集成，你應(yīng)該采取與代碼質(zhì)量控制相同的嚴(yán)格措施。這樣，當(dāng)應(yīng)用程序的響應(yīng)時(shí)間超過上限或者功能出現(xiàn)錯(cuò)誤時(shí)，你會(huì)立即收到提醒和通知。
公共API發(fā)生錯(cuò)誤的次數(shù)比你想象到的要多
隨著越來越多的應(yīng)用程序依賴于公共API，一個(gè)眾所周知的事實(shí)是，公共API并不可靠。每個(gè)API都有很多發(fā)生錯(cuò)誤的情形，而大多數(shù)應(yīng)用程序都包含有多個(gè)API。你需要對(duì)API可能發(fā)生的錯(cuò)誤有所預(yù)料，在理想情況下，你需要能夠盡量減少這些錯(cuò)誤。你絕對(duì)不能等待客戶自己報(bào)告問題。如果你的客戶已經(jīng)去了別的地方，這些錯(cuò)誤將不會(huì)自行修復(fù)。而客戶遇到這些問題時(shí)，他們很大可能不會(huì)去調(diào)查這些問題是由哪里引起的。
SmartBear在其發(fā)布的2019年API統(tǒng)計(jì)報(bào)告中指出：
“那些將API監(jiān)控視為首要任務(wù)的組織在解決性能問題方面的表現(xiàn)遠(yuǎn)遠(yuǎn)優(yōu)于那些沒有這樣做的組織”。
該報(bào)告將這一現(xiàn)象歸結(jié)于極高的客戶期望。他們的調(diào)查發(fā)現(xiàn)，57%的API用戶希望問題能在一天內(nèi)解決，40%的用戶希望問題能在12小時(shí)內(nèi)解決。
API返回請(qǐng)求失敗的原因有很多：
響應(yīng)時(shí)間：在人們期望值很高的今天，一個(gè)慢的應(yīng)用程序可能和一個(gè)壞的應(yīng)用程序一樣糟糕。響應(yīng)時(shí)間就像煤礦中的金絲雀，預(yù)示著更大的問題即將來臨。
錯(cuò)誤代碼不匹配：正確的狀態(tài)代碼有助于及時(shí)調(diào)整API錯(cuò)誤，但你不能總是指望API提供程序發(fā)送它。在某些情況下，你會(huì)收到一個(gè)200狀態(tài)碼 - 這意味著沒有發(fā)生錯(cuò)誤 - 但是接收到的API響應(yīng)里仍然包含有錯(cuò)誤的詳細(xì)信息。在這種情況下，一個(gè)調(diào)查數(shù)據(jù)的人可能會(huì)發(fā)現(xiàn)有問題，但軟件并不知道錯(cuò)誤已經(jīng)發(fā)生并向任何人報(bào)告。
授權(quán)憑證(Authorization Credential)：API對(duì)發(fā)出請(qǐng)求的人執(zhí)行權(quán)限認(rèn)證，以確定是否是正確的人在獲取信息。這有助于保持系統(tǒng)和數(shù)據(jù)的安全，但也增加了另一層風(fēng)險(xiǎn)，這種風(fēng)險(xiǎn)可能導(dǎo)致有效的請(qǐng)求也可以觸發(fā)錯(cuò)誤。權(quán)限認(rèn)證可能發(fā)生超時(shí)錯(cuò)誤或者授權(quán)憑證被吊銷。但是，這時(shí)候用戶只能看到錯(cuò)誤消息，沒有任何解釋。
速率限制（Rate Limit）：許多API通過對(duì)請(qǐng)求實(shí)現(xiàn)速率限制來控制流量（限流）。這些限制可能是基于一天的流量，或者是基于每秒的流量。建立處理速率限制的邏輯（比如429個(gè)錯(cuò)誤）是非常耗時(shí)的。另外，如果API出現(xiàn)問題，應(yīng)用程序因?yàn)橄蘖鞑荒軌蜃詣?dòng)重試，它就不能提供更好的用戶體驗(yàn)并減少數(shù)據(jù)丟失。
雖然許多開發(fā)人員都采用了某種形式的API監(jiān)控，但他們并不總是關(guān)注外部API。通常情況下，API監(jiān)控要求團(tuán)隊(duì)主動(dòng)而為而不是被動(dòng)為之。這意味著你需要在錯(cuò)誤發(fā)生之前確切地知道要查找哪些錯(cuò)誤。并且你需要知道那些你沒有預(yù)料到的錯(cuò)誤。團(tuán)隊(duì)必須具備這些洞察力，才能滿足用戶的期望。
消除API問題需要做什么？
現(xiàn)代應(yīng)用程序需要大量地連接到外部API才能正常地工作。就像任何一臺(tái)復(fù)雜的機(jī)器一樣，當(dāng)一個(gè)齒輪錯(cuò)位時(shí)，系統(tǒng)就會(huì)崩潰。要識(shí)別和修復(fù)API錯(cuò)誤，需要在你每次調(diào)用API時(shí)使用一些復(fù)雜的技術(shù)工具。僅僅依靠API監(jiān)控遠(yuǎn)遠(yuǎn)不夠，你需要使用重試邏輯和異常檢測(cè)。
積極主動(dòng)地進(jìn)行API維護(hù)意味著對(duì)API網(wǎng)絡(luò)有高度的了解。每次用戶發(fā)送請(qǐng)求時(shí)，你都需要知道它花費(fèi)了多長時(shí)間以及返回了哪些數(shù)據(jù)。洞悉這些有助于預(yù)測(cè)未來何時(shí)可能發(fā)生錯(cuò)誤。同時(shí)，如果API請(qǐng)求返回了錯(cuò)誤，你必須能夠查看請(qǐng)求的詳細(xì)信息并做出快速響應(yīng)。
這樣的話，API錯(cuò)誤的范圍就可以僅限于少數(shù)用戶。不幸的是，開發(fā)人員很少能夠使用這些復(fù)雜的工具。這些工具內(nèi)部構(gòu)建困難，并且需要耗費(fèi)大量時(shí)間和資源。
Hoss公司正在關(guān)注這個(gè)問題。我們用于跟蹤和管理公司使用的API的平臺(tái)可以幫助開發(fā)人員減少這些麻煩，并避免API性能差帶來的破壞性影響。該服務(wù)提供了一個(gè)完整的、易于理解的API分析儀表盤，因此開發(fā)人員可以制作更好的API驅(qū)動(dòng)的產(chǎn)品和提供無縫的用戶體驗(yàn)。API的激增帶來了巨大的好處，但同時(shí)也帶來了巨大的成本，而懂得采取行動(dòng)降低這些成本的開發(fā)人員必將在即將到來API的繁榮中占據(jù)有利地位。
原文：
https://hackernoon.com/what-is-the-true-cost-of-using-public-apis-lz7x3wn7
本文為 CSDN 翻譯，轉(zhuǎn)載請(qǐng)注明來源出處。
