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