關注留言點贊，帶你了解最流行的軟體開發知識與最新科技行業趨勢。

了解 API 內建并想了解更多？這是一個 API 內建示例，顯示了從 API 到 API 的所有内容以及介于兩者之間的所有部分。

API 內建是一種代碼，它允許一個系統在使用 API（應用程式程式設計接口）安全通路系統的同時将資料傳輸到另一個系統或從另一個系統傳輸資料。一些 API 內建可能隻在內建的一側有一個 API，而其他 API 可能使用兩個或更多 API。

開發人員出于不同的原因建構 API 內建，但這些內建通常屬于以下兩類之一：

它們要麼旨在在公司内部運作以自動化内部業務工作流程。
它們旨在連接配接來自不同公司的系統以進行外部資料共享。

由于我們與需要建立将其産品連接配接到客戶使用的其他系統的本地內建的軟體公司合作，是以我們的示例将涵蓋外部資料共享場景——但這些概念也适用于内部內建。

我們将按如下方式布置此示例：

內建業務需求（原因）。
內建技術要求（the what）。
執行的內建細節（方法）。

整合業務需求

對于此 API 內建示例，您的公司提供了用于監控建築物安全的 SaaS 産品。除其他事項外，您的應用程式會定期記錄安裝在每個客戶建築物關鍵點的傳感器的溫度和濕度水準。您的客戶需要一個內建來每天将這些溫度和濕度值從您的産品導出到其建築維護應用程式 (StructManager)。然後，客戶将确定溫度和濕度水準與計劃外維護票之間是否存在相關性。

內建技術要求

建構內建時，您需要從技術要求開始。這些是您在開始之前需要回答的基本問題：

将傳輸哪些資料？（資料）
這是一種單向內建還是雙向內建？（方向）
內建将多久運作一次？（頻率）
将使用哪些 API？(應用程式接口)
将使用什麼傳輸協定？（協定）
将使用哪些傳輸語言？（語言）
auth 将如何處理？(認證)

讓我們為我們的 API 內建示例填寫所有這些：

資料：前一天（24 小時）每個建築物的濕度和溫度記錄。
方向：從您的産品單向導出到 StructManager。
頻率：當地時間早上 7 點每天一次。
API：您的産品使用 SOAP API。StructManager 使用 REST API。
協定：兩個 API 都支援 HTTP。
語言：您的産品輸出 SOAP XML。StructManager 接受 JSON 作為輸入。
Auth：SOAP API 和 REST API 使用 OAuth。

此外，雖然濕度資料以相對濕度的百分比形式提供（并且在兩個應用程式中相同），但來自您産品的溫度資料使用攝氏度，而 StructManager 設定為使用華氏度。最後，您的産品每分鐘收集一次溫度和濕度資料，但 StructManager 隻需要每 15 分鐘了解一次這些值。

是以，對于這個 API 內建示例，我們有兩個 API、兩種資料格式、兩種溫度值标度以及比所需更多的資料。聽起來我們需要做的不僅僅是從一個 API 擷取資料并将其交給另一個 API。

執行的內建詳細資訊

在當地時間上午 7 點，內建觸發器會導緻內建向産品的 SOAP API 發送查詢，請求過去 24 小時内每個建築物的指定客戶的記錄。值得慶幸的是，您的 SOAP API 支援内置在連接配接字元串中的 OAuth。一旦 SOAP API 收到請求，它就會通過 HTTP 發回 XML 以及所有比對的記錄。

從您的 SaaS 産品發送的單個記錄如下所示：

內建首先執行資料格式轉換，将所有内容從 XML 轉換為 JSON，為我們提供以下單個記錄模式：

{"environmental": { "customer_id": "AA8312", "building_id": "H265", "sensor_id": 1323, "sensor_loc": "5W2NAB", "timestamp": "10:30", "temperature": 27.3, "humidity": 55 }}

對于在一棟建築物中分布了 30 個傳感器的示例客戶，每天從您的 SOAP API 導出的記錄将包括 43,200 條記錄，但內建隻需将其中的 2,880 條發送到 StructManager。是以，我們需要內建來過濾 43,200 條記錄，并剔除不具有與以下模式比對的時間戳值的每條記錄：hh:00、hh:15、hh:30和hh:45。是的，我們可以想出一種方法來首先從 SOAP API 請求這些記錄，但在這種情況下，擷取資料的超集并從那裡開始更清晰。

一旦簡化後的資料集隻包含我們想要保留的記錄，內建将需要再次循環資料以使用一些簡單的數學将溫度值從攝氏度轉換為華氏度。我們的示例資料現在符合 StructManager 需要導入的格式：

{"environmental": { "customer_id": "AA8312", "building_id": "H265", "sensor_id": 1323, "sensor_loc": "5W2NAB", "timestamp": "10:30", "temperature": 81.1, "humidity": 55 }}

此時，以 JSON 編碼的所有 2,880 條記錄都包含在對 StructManager REST API 的 HTTP 請求中。在送出資料之前，內建再次使用 OAuth 連接配接 API。

我們的 API 內建示例已成功運作，下一次運作将等到明天早上 7 點。

其他 API 內建資源

當然，一個例子很難說明像 API 內建這樣複雜的主題。考慮到這一點，這裡有一些資源可以幫助您進一步了解 API 內建概念：

按技術分類的 API（REST、XML-RPC、SOAP 和 GraphQL）。
按通路類型（私有、合作夥伴、公共和開放）劃分的 API。
內建傳輸協定和傳輸語言。
內建媒體類型（以前稱為 MIME 類型）。
內建過程中發生的事情。

一切都與工具有關

API 對于建構 SaaS 産品之間的資料內建非常有幫助。但是擁有正确的工具來處理這些 API 是至關重要的。作為一家提供應用程式内內建的軟體公司，這些工具可能是實施滿足客戶需求的最低限度內建與實施作為 SaaS 産品一部分但客戶無法分辨的內建之間的差別您的産品停止和內建開始的地方。其中一個工具是嵌入式內建平台。

什麼是 API 內建示例？