關于API令牌你需要知道的一切
你可能也喜歡這些API文章!
REQUEST B
GET coinbroker.io/quote
{
“Account_token”:”4b86cd3f-ccaf-445b-b099”,
"Amount_usd":" 6",
"coin_type":" BTC"
}REQUEST C
POST coinbroker.io/order
{
“Account_token”:”4b86cd3f-ccaf-445b-b099”,
“Quote_token”:”552cd9da-2ff4-4dfe-b2eb”,這里顯示了多少個應用程序接口？ 很多人會回答 “三個”，這些人可能是對的。 但是，答案 “1 “和 “2 “也可能是正確的。 每個請求都是自己的 API 嗎？ 每個請求都有自己的端點，但它們共享類似的數據，那么是否由路徑決定？
服務的其他部分呢？ 這是一個微服務集合嗎？ 在這種情況下，是每個微服務都有自己的應用程序接口，還是整個服務構成一個單一的應用程序接口？
這就是迪金森試圖展示的根本問題。 這些邏輯都沒有明確、完美的答案，但它們從根本上都是正確的–那么，我們究竟該如何計算 API 呢？
解決這個問題的方法有很多，其中很多都很合理。 我們可以計算完全合格的域名（FQDN），這樣就能知道特定應用程序接口的數量。 但路由呢？ 好吧，也許我們可以把 FQDN 和路由結合起來，得到別的東西。
但內部 API 和外部 API 之間的區別又是什么呢？ 已廢棄的 API 仍可作為選項使用，但其功能存在于不同的核心 API 中，又該如何處理？ 這些問題帶來的問題比解決方案更多。 答案可能很簡單：通過規范來計算。 在這種方法中，規范決定了應用程序接口的數量，而定義則不那么重要。
這種方法雖然有效，但也帶來了一個新問題。 我們如何按生命周期狀態計算 API？ 流氓或未托管的應用程序接口仍然是應用程序接口，即使它們未在規范中指定，也應該計算在內。 Dickinson 的解決方案是從類別的角度來考慮這些問題：
這就引入了一個更符合實際情況的計數。 現在，我們有了一個與其生命周期中的狀態相關的數字，而不僅僅是一個純粹的數字，這樣我們就可以逐步建立一個可以長期跟蹤的 API 清單。 這樣，再加上通過自省進行的自我描述，就能讓應用程序接口規范確定其定義并浮現出可用數據。
為了提高數據的可用性，我們還應該分配風險。 了解這些現有的應用程序接口類別很有幫助，但了解具體的風險度量標準則是我們首次討論的這一流程的巨大優勢。
有了規范，我們就需要開始研究哪些指標可能有用。 用戶活動、特定上下文、網絡流量，甚至 API 最近的更改都應被跟蹤，這樣我們就能根據上下文確定 API 最近的更改，從而確定 API 的攻擊面。
現在，我們談論的不僅僅是規范，還包括開發人員的意圖和實際使用。 威脅既有內部的也有外部的，意圖與實際使用同樣重要，因此運行時監控和日志記錄對這一過程至關重要。
雖然目前還沒有標準的風險度量，但跟蹤這些數據可以開始描繪出一幅圖畫，用于在內部分配這些分數，并具有一定的有效性。 Rob 特別指出，Graylog 將這一過程視為基于請求和響應數據的計算，并指出響應往往是數據泄漏和不希望發生的行為發生的地方。
由此，我們最終可以建立一個 API 發現模型，滿足我們的所有需求：
步行： 創建 API 清單。 使用 API 規范來定義 API 集合，并確定哪些在內部被視為 API。 記錄和跟蹤這些 API，并指定運行時跟蹤，以便在內部生成數據，用于安全態勢評估。
運行：跟蹤 API 清單的變化。 通過對這些 API 進行分類，添加更多的上下文。 通過對生命周期和最終用戶目的的考慮，跟蹤它們隨著時間的推移而發生的變化，從而豐富數據并為 API 收集提供實質性的背景信息。
火箭飛船： 跟蹤 API 庫存風險指標的變化。 最后，隨著 API 的發展和在現實世界中的使用，跟蹤風險指標的變化。 這樣就可以計算相對風險，并采用基于度量的安全態勢方法，這種方法是以現實為依據的，而不是憑空想象的。
對許多人來說，這似乎是顯而易見的–尤其是對于 API 規范的倡導者來說–但對其他人來說，這卻是一個啟示。 明確定義并不重要，重要的是共享定義的模式，這對了解您的安全態勢至關重要。 安全是基于度量的：您需要對您的安全態勢的成功和安全程度進行一定的度量，而這種方法能夠為最廣泛的業務、應用程序接口設計和范例提供度量。
本文翻譯源自：https://nordicapis.com/api-discovery-how-do-you-count-apis/
