什麼是API端點？

API和端點一直是前端開發者和後端開發者討論的熱門話題。為了開發有用的和可持續的應用程式和服務，API一直是強大的媒介和推動者。

API促進了各種軟體工件之間的資料傳輸，以解決客戶的問題。幾乎所有的現代基於網路的產品都提供自己的API，以便與之互動並將其服務直接整合到任何專案中。

為了跟上你的競爭對手併為你的使用者提供跨平臺的無縫體驗，你需要了解並掌握API的遊戲。

本指南將對這個術語進行分解，幫助你瞭解什麼是API端點，你如何消費一個公開可用的API，以及保護和監控你的API端點的各種方法。

1. 瞭解API端點
2. 如何保證API端點的安全？
3. 監測API端點

瞭解API端點

“API “是 “應用程式設計介面 “的簡稱。它本質上是一套規則，允許一個應用程式與其他應用程式分享其資料。簡單地說，一個API將使你能夠在你的應用程式和第三方應用程式之間 “分享東西”。

一個API端點是一個通過API暴露的數字位置，API從那裡接收請求併發出響應。每個端點都是一個URL（統一資源定位器），提供API伺服器上資源的位置。

要了解API的目的和用途，首先讓我們瞭解它們如何工作。

API是如何工作的

對於兩個軟體應用程式在網際網路上的通訊，一個應用程式（被稱為客戶端）向其他應用程式的API終端（被稱為伺服器）傳送請求。根據API的能力，客戶端可能從資料庫中請求一個資源，或要求伺服器在其環境中執行一些行動並返回結果。

在收到客戶端的結果後，API（或伺服器）會執行所請求的操作，並將操作結果以響應的形式發回給客戶端。這個響應也可以包括客戶要求的任何資源。

可以有各種型別的API，包括REST、SOAP和GraphQL。它們的工作方式各不相同，但其目的仍然是相同的：促進基於網路的實體之間的通訊。在本指南中，我們將主要討論REST APIs，因為它們是全球最流行的API。

API和端點之間有什麼區別？

這給我們帶來了下一個也是最常見的問題。API和端點之間的區別是什麼？

API是一套協議和工具，用於促進兩個應用程式之間的互動。端點是API上發生交換的一個地方。端點是API上的URI（統一資源索引），應用程式可以訪問。

所有的API都有端點。沒有端點，就不可能與API互動。

端點如何與API一起工作？

為了加深你對API和端點的理解，讓我們舉一個小例子。

考慮一下Cat Facts API。這個API提供隨機的貓的事實。然而，它列出了各種端點，你可以使用這些端點來請求分類的資訊。有三個可用的端點：

• /fact: 返回一個單一的、隨機的貓的事實。
• /facts: 返回一個隨機的貓的事實列表。
• /breeds: 返回一個貓咪品種的列表。

要向這個API發出請求並檢索貓的事實，你需要在API的基本URL（即https://catfact.ninja/）上附加正確的端點（即 /fact）。這將給你以下的端點URL：https://catfact.ninja/fact

如果你向上述URL傳送一個 GET 請求，你會收到一個類似的結果：

{
"fact": "Spanish-Jewish folklore recounts that Adam\u2019s first wife, Lilith, became a black vampire cat, sucking the blood from sleeping babies. This may be the root of the superstition that a cat will smother a sleeping baby or suck out the child\u2019s breath.",
"length": 245
}

現在，如果你訪問另一個端點，如 /breeds，你就無法獲得這些資料。這就是端點如何幫助與API提供的資源進行互動和組織–每個端點都是針對資料的特定部分。

為什麼API端點很重要？

資料傳輸和資源共享是網際網路的一些基本基礎。每一天，越來越多的程序和應用程式被新增到全球網路中，通過分享東西為網路增加價值。

如果沒有API，這一切都不可能實現。API為基於網路的應用程式之間的溝通和互動提供了一個強大的媒介。

而API端點則有助於確定API中資源的確切位置。它們幫助API開發者組織可用的資源，也控制消費者的訪問。因此，消費API的應用程式的效能和生產力直接取決於API端點的設計和效能。

利用現有的API端點工作

在大多數情況下，你會被要求使用預先建立的API。為了有效地做到這一點，你需要了解如何定位端點，並在行業內使用的各種版本規則中找到自己的方式。本節將引導你瞭解這些。

定位一個API端點

如果你能看到API文件，找到一個API端點是一項簡單的工作。有時，文件可能會簡單地列出端點，並在每個端點旁邊有簡短的描述。在其他情況下（比如Swagger），文件可能更復雜、更強大，你可能可以直接從文件頁面測試端點。

在任何情況下，在開始使用每個端點之前，花時間去了解它的目的，是最符合你的利益的。這可以幫助你避免大多數錯誤，提高你的效率。

API端點的版本管理

像大多數其他軟體工件一樣，API也是有版本的。版本化有助於在開發過程中觀察和分析API的成長。如果能夠訪問舊版本，還可以幫助你在有問題的更新中回滾到以前的穩定版本。下面是一些常見的API端點的版本劃分方式。

URI路徑

最流行的API端點版本控制方式之一是在URI路徑中包含一個版本號。它可能看起來是這樣的：

http://example.com/api/1/resourcename

你可以把這種方法看作是對API端點進行全域性版本管理的一種方式。如果你為你的API使用一個子域，例如：

http://api.example.com/resourcename

……你也可以在你的子域裡放一個版本指標，像這樣：

http://api-v2.example.com/resourcename

正如你所看到的，這種方法修改了API的URI路線，所以每個版本本身就表現為一個獨立的資源。這意味著你可以根據需要同時訪問兩個版本的API，甚至可以獨立地對它們進行快取，以加快訪問速度。

當在URI路徑中包括一個版本號時（而不是在子域中），這裡有一個整潔的格式，你可以按照它來包括更多的資訊：

MAJOR.MINOR.PATCH

例如，我們上面的例子中的內部API將是這樣的版本：

http://example.com/api/1.2.3/resourcename

現在，讓我們來分析一下這些新的版本術語和每個術語的作用：

• MAJOR: 當你進行不相容或破壞性的API修改時。
• MINOR: 用於新增向後相容的功能
• PATCH: 用於向後相容的錯誤修復

這裡的MAJOR版本是公共API中使用的版本。這個數字通常在API發生重大或突破性變化時被更新。在內部，這種變化表明一個新的API例項或資源已經被完全建立。

MINOR和PATCH版本在內部用於向後相容的更新。當新的功能被引入時，或者當對同一API資源做了微小的改變時，它們通常會被更新。PATCH號是專門為錯誤修復或問題解決的更新而更新的。

• 優點:
  • 可以同時訪問多個版本。
    URL命名遵循一個簡單、標準的慣例，因此API端點的可訪問性很高。
• 侷限性:
  • 在發生破壞性變化的情況下，這種方法會導致開發一個新的API資源。這可能會給你的程式碼庫增加很大的重量。

查詢引數

另一種對REST API進行版本管理的方法是把版本號放在其URL的查詢引數中。它使伺服器環境能夠像其他查詢引數一樣訪問所需的版本號，並使用它來重定向應用程式中的控制流。你不需要完全建立一個新的API資源，因為你現有的API資源可以讀取版本號並根據需要進行操作。

這就是前一個例子中的URL在使用查詢引數進行版本管理時的樣子：

http://example.com/api/resourcename?version=1

• 優點:
  • 非常容易在程式碼中實現。
    你可以迅速預設為最新的版本。
• 侷限性:
  • 與URI路徑版本控制相比，使用引數將請求路由到正確的版本可能更具挑戰性。

自定義標頭

你也可以通過提供以版本號為屬性的自定義標頭檔案來為REST API提供版本。這種方法與前面提到的兩種方法最顯著的區別是，這種方法不會在端點的URL上亂寫版本資訊。

這就是之前的例子在使用這種方法進行版本管理時的樣子：

curl -H "Accepts-version: 2.0"
http://example.com/api/resourcename

• 優點:
  • URL不會因為版本資訊而變得雜亂無章。
    客戶端可以硬編碼API端點的URL，並在快速傳送請求的同時通過標頭資訊選擇版本。
• 侷限性:
  • 每當提出任何請求時，你都需要手動設定自定義標頭資訊。

內容協商

內容協商允許API開發者對資源的單一表示而不是整個API進行版本管理。這讓他們對版本控制有了更細化的控制。就像之前的方法一樣，這種方法也能消除API URL的混亂。

這就是我們之前的例子在通過內容協商進行版本管理時的樣子：

curl -H "Accept: application/vnd.kb.api+json; version=2"
http://example.com/api/resourcename

然而，使用這種方法的端點版本比使用URI方法的端點更難訪問。更重要的是，使用帶有媒體型別的HTTP頭使得在瀏覽器中測試API變得很困難。而且，如果內容標頭是可選的，就會造成客戶預設接收哪個版本的混亂。

假設你釋出了API的v2版本，並廢除了舊版本的v1。如果客戶端沒有在其請求中指定版本，它將收到v2版本的資源，這可能會由於未考慮的相容性問題而破壞其功能。這就是為什麼通常不推薦將內容協商作為API版本控制的手段。

• 優點:
  • 如果需要，你可以對單一資源進行版本管理。
    它創造了一個更小的程式碼足跡。
    它不需要你修改路由規則（URLs）。
• 侷限性:
  • 帶有媒體型別的HTTP標頭使我們很難在瀏覽器中測試和探索端點。
    也請記住，缺少內容標頭可能會破壞客戶端的功能。

API端點的例子

為了更好地理解API和端點，我們將使用Twitter API來說明一個例子。這個API公開了社交媒體平臺上關於推文、直接資訊、使用者等的資料。它提供各種端點來對其資料進行各種操作。

例如，你可以使用推特查詢端點 (https://api.twitter.com/2/tweets/{id}) ，通過使用其獨特的識別符號來檢索特定推特的內容。你還可以使用Twitter API將公開的推文實時流轉到你的網路應用中，使你的使用者瞭解某個感興趣的話題。

Twitter API為此提供了一個過濾的流端點 (https://api.twitter.com/2/tweets/search/stream)。他們還建立了一個你可以使用的其他端點的擴充套件索引。

如何保證API端點的安全？

現在你已經瞭解了API端點的外觀和工作原理，關鍵是要知道如何保護它。如果沒有足夠的安全措施，API端點可能是你的應用程式的一個主要缺陷，可能會導致資料和資源洩露。

這裡有一些基本建議，以確保對你的API端點的訪問。

單向密碼雜湊

在構建網路資源時，你會經常遇到密碼作為認證實體的一種方式。雖然密碼有助於保護使用者的應用資料，但你也需要保護密碼的儲存，使其成為真正有效的認證媒介。

一般來說，你不應該把密碼儲存為純文字。在發生安全漏洞的情況下，如果一個壞的行為者得到了他們的使用者名稱和密碼字串對錶，所有的使用者賬戶都會被破壞。

阻止這種情況的方法之一是在儲存之前對它們進行加密。有兩種加密方法 – 對稱和非對稱。

在對稱加密中，你可以使用相同的加密金鑰來鎖定和解鎖內容。然而，這並不建議用於密碼，因為頑固而複雜的黑客可以輕易破解這些密碼。

建議使用單向或 “非對稱 “加密的方式來儲存密碼。不採用單一的加密金鑰，而是採用數學函式來擾亂資料。

加密後的版本被儲存在資料庫中，這樣就沒有人，包括你的伺服器管理員，可以破譯密碼並檢視它們。對於驗證使用者，輸入的密碼通過同樣的數學函式執行，並比較結果以檢查輸入的密碼是否正確。

HTTPS

假設你的API端點是為了讓消費者與你的服務對話。在這種情況下，如果你不實施HTTPS（或其他類似的安全協議），就會使他們面臨巨大的風險。

API連線通常會交換敏感資料，如密碼、密匙和支付資訊。這些資料很容易被中間機器攻擊或通過資料包嗅探的方法竊取。

這就是為什麼你應該讓它成為一個點，只要有機會就選擇HTTPS。如果你的應用程式目前正在使用HTTP協議，你應該強烈考慮遷移到HTTPS。不管連線是多麼微不足道，它總是會導致洩漏。

你還應該考慮使用TLS或SSL證書，以進一步提高你的API的安全性。

速率限制

在大多數情況下，對你的API在一分鐘內的使用次數設定一個限制是一個好主意。它可以幫助你控制任何資源的濫用，並帶來基於消費者流量的管理定價模式。

然而，實施速率限制的一個主要原因是為了避免自動化的資源過度使用，這通常是由於機器人每秒可以同時傳送數百或數千個請求。速率限制還可以幫助你阻止這些機器人發起的任何DDoS攻擊。

大多數網路開發框架都提供了開箱即用的速率限制中介軟體，很容易設定。即使你的框架沒有中介軟體，你也可以通過第三方庫獲得一箇中介軟體，並相當快地設定好它。

除了關注機器人，將允許的請求或資料檢索數量限制在一個合理的數量也是一個好的做法。這樣做有助於防止無意中過度使用資源，這些資源可能通過手動錯誤（如無限迴圈）被觸發。它還有助於為你的使用者提供統一的可用性–一個使用者的使用量激增不會影響其他使用者的體驗。

API認證措施

每當你建立一個面向公眾的API時，你需要實施認證措施以防止誤用和濫用你的服務。一個好的選擇是OAuth2系統。

OAuth2系統將你的賬戶劃分為資源，並允許你向認證令牌持有者提供受控的訪問。你可以設定這些令牌在給定的期限內過期–比如說24小時–之後它們會被重新整理。這確保了即使你的令牌被洩露，有限的使用視窗將減少洩露的影響。

API安全的一個重要部分是使用API金鑰來驗證請求。你可以設定API金鑰來限制對你的API的呼叫率，減少DoS攻擊的機會。如果你提供付費的API服務，你可以使用API金鑰，根據每個使用者購買的計劃提供訪問。

你還應該考慮為你的內部員工端點配備多因素認證、防病毒軟體和自動應用程式更新。這些簡單的措施將在很大程度上確保你所提供的服務質量不受影響。

輸入驗證

雖然這聽起來像是在構建任何軟體應用時要做的一件顯而易見的事情，但令人驚訝的是，很多API都沒有正確地實現這一點。輸入驗證不僅是指檢查輸入的資料是否有正確的格式，而且也要注意是否有意外。

最簡單但最常見的例子之一是SQL隱碼攻擊。如果執行了錯誤的查詢，不對其進行覆蓋，會使你的整個資料庫消失。一定要驗證輸入資料的正確格式，並刪除可能顯示惡意的字元。

另一件需要注意的事情是請求的大小。在POST請求的情況下，試圖接受和解析一個非常大的輸入，只會讓你的API崩潰。你應該始終專注於首先驗證POST請求的大小，並在適當的時候向客戶返回一個適當的錯誤程式碼和資訊。

IP地址過濾

如果你提供B2B服務，並且你的客戶在全球各地使用你的API，你應該考慮為你的系統增加一個額外的安全層，根據他們的位置，限制訪問你的API的IP地址。

對於新的地點和客戶，你需要將他們的資料新增到你的 “允許地點 “列表中。雖然這可能會給你的客戶的入職過程增加額外的摩擦，但它將大大有助於提高安全性，反過來也會提高他們的體驗質量。

為了進一步減少安全風險，你還應該考慮將客戶的許可權和訪問限制在標準操作所需的最低限度。同樣地，限制你的HTTP訪問，以確保配置錯誤的客戶只收到API規格和訪問程式碼。確保你的API以405響應程式碼拒絕這些請求。

值得注意的是，世界上很大一部分網路攻擊都來自於有限的幾個國家。另一個好的做法是，如果你在這些地方沒有客戶，就完全阻止從這些地方訪問你的資源。

此外，如果你發現有攻擊，首先要阻止來自攻擊者所在地區的GET/POST請求。根據客戶所在地限制HTTP請求的能力是對付正在進行的網路攻擊的最快方法之一。

XDR（擴充套件檢測和響應）

大多陣列織部署了傳統的安全工具，如防火牆和入侵保護/檢測技術。雖然這些是任何安全系統的基礎，但它們不是為API明確設計的。

一種名為XDR的新技術為整個IT環境（包括API端點）提供了更好、更全面的保護方法。XDR為安全團隊提供了關於惡意行為的實時警報，這使他們能夠迅速調查攻擊。

以下是XDT保護API端點的一些方法：

• HTTPS監控： XDR可以管理你的端點的安全證書，也可以檢查HTTP通訊。當它發現異常情況時，它可以迅速終止連線或採取其他自動行動。
• API呼叫監控：XDR可以跟蹤你的客戶進行的API呼叫的數量，並在發現可疑的趨勢時通知你的安全團隊，即使在設定的速率限制內。
• JSON網路令牌（JWT）：JWT是一種標準方法，用於在通過網路進行通訊時安全地表示使用者的身份。XDR可以幫助在你的網路上通過JWT識別使用者，而不必傳輸憑證。這使您能夠在您的API流量中識別使用者賬戶，並分析他們的行為是否有異常情況。
• IP地址過濾：XDR與威脅情報資料庫整合得很好，並檢查傳入請求的合法IP地址或來源。
• 輸入驗證：即使您在服務中沒有實施適當的輸入消毒措施，XDR解決方案也能自動分析SQL或其他資料庫敏感查詢，以檢測注入攻擊，在其軌道上阻止它們，並通知安全團隊。

維護程式

有一些一般的維護程式，你可以設定這些程式來提高你的API的安全質量。下面是其中的一些：

• 清理資料： 從你的服務中刪除多餘的使用者和僱員資料。常規的資料清理不僅是一種良好的做法，而且還有助於減少意外資料丟失或損壞的機會。
• 進行定期更新：記住要定期更新你的技術棧和服務認證。你應該為你的端點服務實施常規補丁，你的所有許可應該反映最新的監管和合規標準。
• 審查安全措施：保持你的安全和恢復計劃是最新的。它們應儘可能頻繁地反映你的網路基礎設施的最新變化或增加的內容。如果你定期增加新的移動、物聯網或其他內部資源，這種做法就更加關鍵。

監測API端點

現在你已經瞭解瞭如何構建、消費和保護API端點，接下來要知道的是如何監控它們。 監控是一個關鍵的概念，它適用於整個軟體工程的動態，以分析和加強技術產品的增長。

提示、技巧和最佳實踐

就API端點而言，監控可以幫助你保護和優化你的端點，以提高效能和可靠性。接下來的部分將引導你瞭解在對API端點進行檢測和監控時需要遵循的一些最佳實踐。

1. 驗證功能正常執行時間

一般來說，團隊傾向於監測API可用性或正常執行時間，並將其作為衡量API服務質量的標準。然而，對於通過API發生的各種型別的資料交換交易，僅僅測量API的整體可用性是不夠的。你需要單獨監控所有動詞（建立、讀取、更新、刪除等）的可用性和效能，以確保它們都在執行。

要做到這一點，你可以用多步驟的API監控器實施合成監控工具。它將幫助你同時提高API和資料的可用性。同時，你應該記住，合成監控使用一組有限的、預定義的API呼叫進行測試。所以實際的真實世界的流量可能與合成監控中的輸入集不同。

2. 記住監控API的依賴性

不是每個API都是獨立構建的。更多的時候，你需要在構建自己的API時消耗第三方的API。雖然你可以對你的程式碼進行最深層次的檢測，但你很容易忘記跟蹤這些第三方API的行為。

因此，你也必須跟蹤來自第三方API的響應。根據我們的經驗，每當我們沒有獨立分析這些依賴關係時，有問題的依賴關係就會引起很多騷動。

3. 在API監控中實施自動測試

如果你有一個定義明確的CI/CD管道，你可能已經知道自動化的重要性。因此，如果你能在監控的同時為你的API端點設定自動測試，那是最好的。你應該考慮在你的CI/CD管道中增加一個額外的步驟，在釋出前對你的端點執行自動化測試。雖然這在當前已經成為一種常態，但你應該檢查你是否已經實施了它。

4. 選擇一個具有強大警報功能的工具

由於目前市場上有各種各樣的工具，要找到適合你使用情況的工具可能會變得很棘手。為了使你的搜尋更容易，這裡有一個快速的規則需要記住。始終尋找強大的警報能力。如果你所選擇的工具不能正確地提醒你關於傳入的問題，你將不得不浪費時間持續干預以檢查是否有任何事件發生。這個領域的自動化在提高你的團隊的生產力方面有很大的作用。

5. 優先考慮可直接整合到CI/CD管道中的工具

你應該考慮在你的CI/CD管道的每個階段整合監控，以分析你的DevOps流程的效率。為此，你需要仔細選擇能提供這種功能的工具。

要檢查你所選擇的工具是否有這個功能，請尋找所提供的第三方整合的列表。如果你的CI伺服器，如Jenkins或GitHub，被該工具所支援，你就可以開始了

6. 決不妥協於API的隱私

一些API監控工具利用第三方SaaS平臺，要求客戶在他們的防火牆上開啟某些埠，以監控本來無法到達的內部API。然而，這些構成了一個重大的安全風險。任何瞭解這些埠的人都可以利用它們來獲得對你的系統的未經授權的訪問。

這就是為什麼必須選擇一個好的API監控解決方案，將你的API的設計考慮在內，並允許你安全地監控每個端點，無論是內部還是外部。為此，最好的工具是能夠私下訪問你的內部API，而不給入侵者留下空間。

7. 24小時全天候監控

如果不一直監控你的API，就會讓你損失巨大。 任何服務都可能在任何隨機的時間點發生故障。如果你的監控服務在那個時候被關閉了，你就必須等到服務恢復時才知道發生了停機。在這個視窗期，你可能會失去寶貴的業務。

因此，我們建議你設定高頻率的監控，每小時至少執行五次，用於功能測試，每小時一次，用於安全和OAuth監控。

8. 傾向於外部監測而不是內部監測

很多時候，問題不會在內部和外部統一發生。你的使用者可能會面臨一個你在系統的防火牆內無法重現的問題。在這種情況下，你的內部指標是否執行正確並不重要；使用者不能訪問你的產品，所以每一個操作指標都沒有什麼用。

為了避免這種情況，總是傾向於使用外部監控設定而不是內部監控。為了解決使用者所面臨的問題，你需要從使用者的角度來看待你的API。

9. 監控所有資源

在構建API背後的服務或應用的過程中，你可能會設計一些基本或複雜的元件。雖然跳過對基本元件的監控是很誘人的，但這並不是所有情況下的好做法。很多時候，一個不重要的、簡單的元件中一個看似微不足道的錯誤可能會破壞一個廣泛的應用程式。

如果你不是到處都有眼睛，你將被迫浪費幾個小時試圖找到導致問題的元件，結果發現你認為太無辜的一個小部件的錯誤實際上是罪魁禍首。

10. 分析所有的響應引數

只檢查狀態程式碼是否返回200是不夠的。大多數開發人員使用基本的HTTP狀態程式碼，如200表示成功，500表示伺服器錯誤，以表示通用響應。然而，成功或錯誤可以有各種形式，跟蹤每一個例項對於確定你的API的表現是至關重要的。

你還應該考慮尋找由API返回的內容的大小變化。如果通常的響應大小為500kb，但你只收到100kb或更少，你可能遇到了某種型別的失敗。

API監控工具

為了實施上述的最佳實踐，你需要從API監控解決方案開始。雖然像WordPress這樣的框架中有現成的外掛用於API監控，但如果是純編碼的應用程式，你需要尋找一個更全面的解決方案。

在下一節中，我們將討論一系列趨勢性的API監控工具，以幫助你以最小的成本和精力開始工作。

Uptrends

Uptrends賬戶概覽儀表盤

Uptrends提供對網路應用程式、API、伺服器等的監控。它擁有超過25000個小型和大型組織的龐大客戶群，包括一些著名的名字，如微軟、Vimeo和大眾汽車。

該供應商提供的一個引人注目的功能是基於瀏覽器的測試。它使用實際的、獨特的瀏覽器來執行你的應用程式和網站，並捕獲關於其效能的詳細指標。

然而，響應時間和指標並不是該服務的唯一功能。有了Uptrends，你還可以得到每一個資源的詳細效能報告，以便你瞭解系統中所有可能的瓶頸型別。對於每個錯誤，Uptrends都會進行截圖併傳送給你，這樣你就可以體驗到錯誤發生時的情況。

Dotcom-Monitor

Dotcom-Monitor的效能報告儀表盤

Dotcom-Monitor為使使用者能夠使用HTTP或HTTPS作業配置一個多工監控裝置而感到自豪。這使得你可以監控網路API的可用性，正確的響應和效能。

Dotcom-Monitor代理複製一個或多個客戶端請求，以驗證資料是否能在API和客戶端之間進行充分的交換。當其中一個代理檢測到一個錯誤時，它會根據預設的過濾器列表檢查該錯誤。如果錯誤沒有被設定為過濾掉，代理就會觸發一個警報。

該工具允許你設定自定義警報時間表和升級方案。你可以以各種格式匯出錯誤報告，包括CSV、PDF、TXT等。Dotcom-Monitor的錯誤報告顯示了不同的有價值的指標，如停機時間、響應時間和各地區的平均效能。

Dotcom-Monitor是最實惠的API監控解決方案之一，其計劃從每月1.99美元開始。如果你是一個預算有限的成長型組織，Dotcom-Monitor可能正是適合你的API監控解決方案。

Graphite

Graphite API監控儀表盤

Graphite是一個開源的API監控系統，通過讓服務將資料推送到Graphites Carbon元件，使你能夠從API中捕獲指標。然後，Graphite將這些資料儲存到一個資料庫中，以便從中獲得洞察力。

Graphite在使用者中很受歡迎，因為它的安裝過程很簡單，其中包括其堆疊的自動安裝和配置指令碼，稱為Synthesize。

Graphite提供的另一個引人注目的功能是能夠儲存任意的事件。這些事件一般與時間序列指標有關。你還可以在Graphite內新增和跟蹤應用程式或基礎設施的部署，使你的開發團隊能夠更快地找到問題和瓶頸的來源，並獲得更多關於導致意外行為的事件和異常的背景。

Sematext

Sematext Synthetics儀表盤

Sematext是DevOps團隊中流行的解決方案，因為它提供了一套監控工具。API監控是其合成監控服務的一部分，這被稱為Sematext Synthetics。

Sematext提供了一個複雜的API監控和警報系統，你可以根據各種錯誤和指標來定製工作。你可以設定這個工具，在傳送警報前進行雙重或三重檢查。它可以幫助你消除警報中的誤報，提供更準確和相關的資訊。

除了Sematext提供的強大的HTTP監控，你還可以得到一個全面的瀏覽器監控功能。它使你能夠根據預先編寫的使用者與你的Web應用程式的互動來收集Web效能指標。這意味著你可以超越通常的測試標準，跟蹤頁面載入時間，內容繪製時間等，並深入研究詳細的模擬使用者互動，如應用內認證流程，搜尋查詢執行，或從購物車中新增或刪除專案。Sematext提供各種這樣的使用者互動，開箱即用。

BlazeMeter

BlazeMeter API監控儀表盤

Blazemeter是現代應用程式的首要端到端測試和監控解決方案。該工具讓你可以完全自由地選擇開源測試框架，並使用簡單的儀表盤對其進行分析。它還提供與Apache JMeter的無縫整合，後者是複雜網路應用的最佳效能測量工具之一。

與大多數API監控解決方案一樣，BlazeMeter也提供了功能測試（被稱為 “場景”）等基本功能，您可以使用互動式圖形使用者介面進行設定。BlazeMeter通過其專用測試工具Taurus暴露了一個DSL（特定領域語言），使開發人員能夠編寫通用測試。然後您可以針對JMeter和其他流行的開源工具執行這些測試。

鑑於其重量級的設計，BlazeMeter的價格偏高。如果你的應用程式有超過5000個併發使用者，你應該準備好每月掏出600美元以上。不過，你可以根據你的使用情況選擇固定費用計劃。

如果您的產品與輝瑞、Adobe、NFL、Atlassian等公司的產品一樣，BlazeMeter就是您的完美API監控解決方案。

雖然這是一個相當簡潔的API監控工具的集合，但還有許多更棒的選擇在那裡。在做出選擇之前，請確保檢視Geekflare提供的API監控工具的詳細集合，以及Sematext提供的API監控工具的全面購買指南。

小結

API是現代計算機器的骨幹。軟體市場上的大多數產品都有一個API，以提供與第三方實體的無縫整合。為了提供流暢的使用者體驗並留住你的客戶，你需要考慮在你的軟體產品中建立並提供一個API……這意味著你需要了解API的內涵。

本指南旨在幫助你進入這個領域，向你介紹該技術的基礎知識，包括說明基本概念、最佳做法和市場上有用的API監控工具。希望你現在對網路資源如何相互通訊有了更好的理解。

然而，儘管我們討論了這麼多，但對於API和API端點所能完成的一切，我們還僅僅是觸及了表面。繼續閱讀、測試，並與開發社羣聯絡，以擴大你對API端點的瞭解和技能。