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