當數據通過互聯網傳輸時,會產生兩部分信息:開銷和有效負載。開銷數據用于標識負載的源或目的地,僅在數據傳輸過程中使用,一旦到達目的地,開銷信息便從視圖中刪除。
例如,發送消息“Hello”并將其標記為“msg”(消息的縮寫)。在這種情況下,“Hello”是有效負載,而“msg”是開銷。到達目的地后,唯一可見的數據是“Hello”,而“msg”僅用于內部目的,以識別數據。
API的有效負載可以以多種格式發送或接收,例如JSON或XML。在查詢字符串中,負載通常用大括號“{}”來標識。
有效負載是從服務器發送或接收的數據塊中的基本信息。以下是API中JSON有效負載的示例:
概述: X (Twitter) API 允許開發人員訪問并與 X 的龐大數據集交互,使他們能夠構建可以讀取、寫入和管理 tweet、用戶帳戶和各種 X 功能的應用程序。
端點: API 為獲取用戶時間線、發布 tweet、搜索 tweet、檢索用戶信息等操作提供端點。
有效載荷示例 (POST 請求 tweet):
Endpoint: POST /statuses/update
Payload:
{
"status": "Hello, Twitter! This is a test tweet from my API client. #API #Twitter"
}
概述: Google Maps API 允許開發人員將 Google Maps 集成到他們的應用程序和網站中,提供顯示地圖、創建自定義標記、計算方向和地理編碼等功能。
端點: API 提供端點來與地圖數據、地點和方向等進行交互。
有效負載示例 (GET 請求地理編碼):
端點: GET /maps/api/geocode/json
Query Parameters:
{
"address": "1600 Amphitheatre Parkway, Mountain View, CA"
}
雖然格式略有不同,但有效負載和開銷數據保持不變。
我們將討論三種類型的有效負載格式:
一個負載 API 請求需要兩個參數和一個子元素:
interfaceType
標識這是一個 API 請求格式,必須設置為“手動”。methodName
定義要調用的 API 方法。parameters
包含被調用方法所需的參數。{
"name": "John Doe",
"email": "john.doe@example.com",
"age": 30,
"is_active": true,
"interests": ["programming", "reading", "hiking"]
}
一個成功的有效負載響應將包含一個參數和一個子元素:
responseType
必須設置為“OK”。data
可能包含被調用方法響應所需的零個或多個參數。{
"user_id": 12345,
"name": "John Doe",
"email": "john.doe@example.com",
"age": 30,
"is_active": true,
"interests": ["programming", "reading", "hiking"],
"created_at": "2023-07-21T12:34:56Z"
}
失敗的有效負載響應將包含一個參數和一個子元素:
responseType
必須設置為 FAILED
。messages
可能包含一個由零條或多條錯誤消息組成的數組。{
"error_code": 404,
"error_message": "User not found",
"error_details": {
"request_id": "123abc",
"timestamp": "2023-07-21T15:45:32Z"
}
}
API 請求有效負載格式取決于 API 的設計和特定操作所需的數據。然而,API 請求有效負載中使用的兩種常見數據交換格式是 JSON 和 XML。這兩種格式都得到了廣泛支持,并提供了一種結構化的方式來表示數據。
JSON 是一種輕量級的、人類可讀的數據交換格式,易于理解和處理。它廣泛應用于現代 web 開發和 API。JSON 有效負載由鍵值對組成,可以表示多種數據類型,如對象、數組、字符串、數字、布爾值和空值。
在假設的 API 中創建用戶的 JSON 有效負載示例:
{
"name": "John Doe",
"email": "john.doe@example.com",
"age": 30,
"is_active": true,
"interests": ["programming", "reading", "hiking"]
}
在計算機網絡中,通信包括發送和接收消息。發送方必須正確處理消息,而接收方則需要具備處理消息所需的所有資源。
在 API 中,有效負載是在消息上下文中使用的,以便將其與開銷數據區分開。正確解析請求需要參考開銷數據。掌握這些信息后,可以更好地理解如何在計算機網絡中通過 API 的有效負載傳輸消息。