API 101 - API的基本簡介

API代表應用程式寫程式介面。 它只代表它所說的 — 程式之間有介面,這些介面允許這些程式通信。 當程式設計師開發軟體應用程式時,他們往往需要自己的軟體來與其他軟體或硬體通信。 API定義這些通信和交互的內容、方式、時間、地點和原因。

API是用軟體解決業務難題的一種方法。 在大多數企業中,這是一種合作。 通過對關鍵術語、概念和步驟的共同理解,協作總是更容易。

如果您想要在網頁中按一下連結,則當您按一下該連結時,瀏覽器會使用很多API。 瀏覽器識別該按一下,對要訪問的頁面發出請求,在Internet上檢索該頁面,然後在螢幕上顯示該頁面。 中間有許多較小的步驟,但您的瀏覽器是與各種API進行通信和交互的軟體,只是為了向您顯示網頁。 在本文中,我們將重點介紹在使用或討論API時重要的術語、概念和步驟。

在本文的末尾,您應清楚地瞭解這些基本術語、概念和步驟。 API文檔內容可能很廣泛,而有關使用API解決特定使用情形的討論可以非常詳細。 瀏覽文檔和討論API更簡單、更高效,並有清晰的基礎知識和共同的理解。

注意

雖然有許多API,但此處的重點將放在Web和瀏覽器API上:基本上,當一個軟體應用程式通過網際網路與另一個軟體應用程式交互時。

API術語和概念

一個詞或短語是什麼意思,我怎麼能簡單地去想它呢? 在API中,「應用」部分指軟體應用程式或程式。 「寫程式介面」部分是指應用程式如何與另一應用程式進行特定目的的交互以及在何處進行交互。 在我們的網頁示例中,當您按一下某個連結時,瀏覽器會向伺服器發送有關該網頁的請求。

具有目標URL的超連結影像

在此螢幕截圖中,滑鼠游標懸停在Adobe Experience Platform連結上。 底部是Web瀏覽器狀態欄,該欄顯示瀏覽器將獲取的頁面的「地址」。 換句話說,按一下「Adobe Experience Platform」連結會告訴瀏覽器「為我獲取該頁面,以便我可以在我的螢幕上看到它」。

按一下連結時,瀏覽器向伺服器請求獲取頁面。 這是 GET 請求,是Web API常用的請求方法之一。 瀏覽器需要滿足的一件事是頁面「地址」 — 它在Web上的位置?

URL的部分

帶URL的瀏覽器地址欄

大多數瀏覽器都有一個「地址欄」,顯示某個網頁的部分或全部「地址」。 當瀏覽器「獲取」我們按一下的連結的頁面時,它將在此地址欄中顯示該頁面的「地址」。 那麼,網頁的「地址」是什麼?

那個 https://business.adobe.com/products/experience-platform/adobe-experience-platform.html 上面是Web上某頁的地址,它稱為URL或統一資源定位器。 URL可以引用此頁面或影像檔案、視頻或其他檔案類型。

URL的部分

此地址(URL)具有與Web和瀏覽器API非常相關的特定部分。

方案

scheme 上面也稱為 protocol 使用Web API,通常 httphttps。 HTTP或HyperText傳輸協定是將網頁等資源從Web伺服器傳輸到Web瀏覽器的方式。 HTTPS是安全版本,在該版本中,傳輸通過Internet進行,使用旨在防止對傳輸的資源進行干擾的安全性。 瀏覽器地址欄中通過HTTPS查看頁面時通常會看到一個小的鎖定表徵圖。

對於Web API,這些資源的傳輸是通過HTTP請求進行的,換句話說,就是通過HTTP請求。

主機和域

business.adobe.com 是所請求資源的主機。 按一下示例連結時,瀏覽器將使用URL的此部分查找承載頁面的伺服器。 它並不總是與Web伺服器完全相同,但在基本級別上,我們可以將其視為瀏覽器將獲取我們請求的頁面的伺服器。

域名是域名系統的一部分,更稱為DNS。 大多數人想 adobe.comexample.com 「域名」,但有與API相關的部件。 www.adobe.combusiness.adobe.com 可以稱為域名,但 www.business. 部件稱為子域。 API通常與包含子域(如 api.example.comsub.www.example.com

很常見的是 主機 引用完整域名,包括任何子域(如 business.adobe.com。 也常見的是 域名 引用沒有子域的主機時,如 adobe.com。 記住每個部分的具體術語和一個宿主的變化在這裡並不重要。 但是,瞭解這些條款是常用的非常重要,因此您可以就業務和討論澄清任何相關細節。

Origin

Origin是另一個需要注意的術語,它與URL的各部分密切相關。 在基本層面,原點大致為 scheme 加上 host 加上 domain 喜歡 https://business.adobe.com。 不同的價值通常代表不同的起源,例如 https://business.adobe.comhttp://business.adobe.com 不是同一源,因為它們有不同的方案。 https://www.adobe.comhttps://business.adobe.com 由於子域不同,因此在許多使用中也不相同。

路徑

上面URL示例中的最後一個位是 path 到資源 — 我們示例中的頁面。 的 /products/experience-platform/ part通常表示web伺服器上的資料夾或目錄。 就像我們在電腦上有資料夾或目錄來存放文檔和照片一樣,我們也在Web伺服器上有資料夾來組織內容。 最後, /adobe-experience-platform.html part是檔案的名稱 — 網頁。

URL的其他更詳細部分將在此系列的下一部分突出顯示。

第三方API

Web API有時被稱為第三方API。 就像交易所涉及的各方一樣。 在連結示例中,您(或更確切地說,是瀏覽器)是頁面請求的第一方。 Web伺服器是第二方。 那麼第三個呢?

網頁通常包含來自其他主機或源的內容或資源。 在這些情況下,當瀏覽器開始顯示頁面時,它會向承載這些資源的其他主機(即「第三方」)發出另一組請求。 這非常常見,尤其是對於視頻或影像等媒體內容,對於在查看或使用時需要更新的資料也是如此。 獲取當天的當前時間、當前天氣或特定人員的個性化歡迎資訊都是第三方API可以在適當時間提供適當資源的示例。 這些請求來自這些第三方API是很常見的。

Web API的常用用途

除了一天中的時間、天氣或個性化內容,Web API還有許多用途。 twitter、TikTok、Facebook、LinkedIn、Snapchat、Pinterest等社交媒體平台有各種各樣的API,程式設計師可以在應用程式中使用。 當然,Adobe也 各種各樣的API 程式設計師使用這些軟體,以便他們能與Adobe的產品和服務交互。 軟體產品和服務通過這些API訪問其他軟體產品和服務。

示例API

瀏覽器API允許程式設計師直接與瀏覽器的功能交互。 電池API允許軟體檢查設備的電池狀態,以便在需要時提醒您。 剪貼簿API允許軟體複製或貼上到設備的剪貼簿中。 全屏API允許軟體提供將視圖擴展到設備全屏的選項,如YouTube。

Adobe Experience Platform資料存取API是一個Web API,程式設計師可以訪問和下載來自Adobe Experience Platform的資料集檔案,這樣他們就可以在自己的程式中使用客戶配置檔案資料。 像這樣的API是軟體自動化過程的一部分是很常見的,在軟體自動化過程中,軟體被寫程式以使用多個API組合執行一系列步驟。 與手動執行這些相同步驟相比,這通常可以顯著節省成本。

API終結點

當程式設計師在程式中「使用」瀏覽器或Web API時,他們通常會請求發送或接收資源,例如我們的示例瀏覽器請求網頁。 API文檔通常列出這些請求的「端點」,例如: https://platform.adobe.io/data/foundation/export/files/{dataSetFileId}。 這是程式設計師將用於獲取資料集檔案的平台資料存取API的特定模式或「端點」。

{dataSetFileId} 由這些大括弧環繞表示程式設計師需要在請求中發送的值。 所以實際API請求中的URL看起來就像 https://platform.adobe.io/data/foundation/export/files/xyz123brbxyz123brb 需要是程式設計師要接收的資料集檔案的有效ID。

換句話說,就像瀏覽器在特定URL上獲取頁面一樣,API請求從特定終結點獲取資源或將資源發送到特定終結點(如此資料集示例)。

HTTP請求方法

此時,應該清楚的是,Web API會請求網頁或資料集等資源。 與大多數軟體概念一樣,這些HTTP請求遵循可重複的模式。 從軟體應用程式向評估該請求的另一個軟體應用程式發送請求,然後響應:瀏覽器從web伺服器請求頁面並用頁面內容進行響應。

從請求到響應的整個過程涉及許多較小且非常詳細的步驟,但請求方法是簡單明瞭的。 請求方法定義要請求的操作。

GET

GET 請求提供資源的響應時使用request方法,如我們的web頁和資料集示例。 當我們按一下瀏覽器中的連結或點擊移動設備上的連結時,我們將建立 GET 在幕後請求。

POST

POST 方法發送帶有請求的資料。 「請求」發送資料聽起來可能有些奇怪,但其思想是,發出API請求是要求端點(即接收軟體)接受該請求,在 POST,也接受要發送的資料。 發送的資料通常寫入資料庫或檔案等資料儲存,以便保存。

PUT

PUT 請求方法與 POST 因為它發送了資料,但如果要發送的資料已存在於端點,則 PUT 將通過替換現有資料來更新現有資料。 A POST 不更新,它只發送,因此多 POST 請求可以建立發送的資料的多個記錄,而不是更新任何現有記錄。

PATCH

PATCH request方法用於發送更新部分現有記錄的資料,例如,當我們通過更新帳戶配置檔案來更改地址時。 使用 POST 請求可以建立附加配置檔案,並且 PUT,可替換現有配置檔案,但 PATCH 方法我們只需更新現有記錄的相關部分,如地址。

DELETE

DELETE request方法將刪除請求中指定的資源,例如,如果按一下連結可以完全刪除我們的帳戶配置檔案。

還有幾種其他方法,但這是使用API時最常用方法的清單。

請求示例

現在,您已掌握了與API相關的基本術語、概念和步驟,我們可以在實踐中查看一個API請求示例。

瀏覽器示例中的頁面的URL為 https://business.adobe.com/products/experience-platform/adobe-experience-platform.html。 按一下Adobe Experience Platform連結時,瀏覽器將 GET 請求此頁面。 由於我們有瀏覽器來為我們做工作,因此我們只需按一下即可,但是如果程式設計師希望在軟體應用程式中執行該請求,則他們必須提供API請求成功完成所需的所有詳細資訊。

以下是代碼中的可能情況:

fetch(
  "https://business.adobe.com/products/experience-platform/adobe-experience-platform.html",
  {
    headers: {
      accept:
        "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9",
      "accept-language": "en-US,en;q=0.9",
      "sec-ch-ua":
        '" Not A;Brand";v="99", "Chromium";v="101", "Microsoft Edge";v="101"',
      "sec-fetch-dest": "document",
      "sec-fetch-mode": "navigate",
      "sec-fetch-site": "none",
      "sec-fetch-user": "?1",
      "upgrade-insecure-requests": "1",
    },
    referrerPolicy: "strict-origin-when-cross-origin",
    body: null,
    method: "GET",
    mode: "cors",
    credentials: "include",
  }
);

在上面的代碼中,您可以看到 URL 瀏覽器正在請求,下面是 method: "GET" 請求方法。 其他代碼行也是請求的一部分,但超出本條的範圍。

本頁內容