API Academy
🌐 繁體中文
  • 🌐 English
  • 🌐 繁體中文
HomePetstore APIExplore more APIs
HomePetstore APIExplore more APIs
🌐 繁體中文
  • 🌐 English
  • 🌐 繁體中文
🌐 繁體中文
  • 🌐 English
  • 🌐 繁體中文
  1. API Fundamentals
  • 歡迎
  • 目錄
  • API 學院
    • Get Started
      • 什麼是 API?
      • API 如何運作?
      • 如何呼叫 API?
      • 如何閱讀 API 文件?
      • 章節總結
    • API Fundamentals
      • API 基礎知識:概覽
      • 方法與路徑
      • 參數
      • 請求 Body
      • 回應
      • API 規格與 OAS
      • 章節總結
    • Working with APIs
      • 使用 API:概覽
      • 根據規格發送請求
      • 環境與變數
      • 串聯多個端點
      • 處理 Auth
      • 處理 API 簽名
      • 腳本介紹
      • 章節總結
    • Mocking APIs
      • Mocking API:概覽
      • Smart Mock
      • Mock 預期結果
      • Cloud Mock
      • Mock 腳本
      • 章節總結
    • Designing APIs
      • 設計 API:概覽
      • API 設計介紹
      • 建立您的第一個 API 專案
      • 分析需求並規劃您的 API
      • 設計資料模型
      • 設計端點
      • 使用組件與可重用性
      • 設定與 Auth
      • API 設計指南
      • 章節總結
    • Developing APIs
      • 開發 API:概覽
      • 設定:安裝您的 AI 程式碼助手
      • 快速入門:30 分鐘內從規格到運行的 API
      • 了解生成的程式碼
      • 使用 Apidog 測試您的 API
      • 部署:將您的 API 上線
      • 章節總結
    • Testing APIs
      • 測試 API:概覽
      • 快速入門:您的第一個測試場景
      • 整合測試與資料傳遞
      • 動態值
      • 斷言與驗證
      • 流程控制:If, For, ForEach
      • 資料驅動測試
      • 性能測試
      • 測試報告與分析
      • CI/CD 整合
      • 排程任務與自動化
      • 進階測試策略
      • 章節總結
    • API Documentations
      • API 文件:概覽
      • 發布您的第一個 API 文件
      • 自訂文件外觀
      • 給消費者的互動功能
      • 進階發布設定
      • 管理 API 版本
      • 章節總結
    • Advanced API Technologies
      • 進階 API 技術:概覽
      • GraphQL
      • gRPC
      • WebSocket
      • Socket.IO
      • Server-Sent Events
      • SOAP
      • 章節總結
    • API Lifecycle
      • API 生命周期:概覽
      • API 生命周期的階段
      • API 治理
      • API 安全最佳實踐
      • 監控與分析
      • API 版本策略
      • API 的未來
      • 章節總結
    • API Security
      • API 安全性:概覽
      • API 安全性基礎知識
      • 身份驗證 vs. 授權
      • 了解 OAuth 2.0 和 OpenID Connect
      • JSON Web Tokens (JWT)
      • OWASP API 安全 Top 10
      • 加密與 HTTPS
      • 章節總結
    • API Tools
      • API 工具:概覽
      • API 工具的演變
      • API Clients
      • 命令列工具 (cURL, HTTPie)
      • API 設計和文件工具
      • API Mocking 工具
      • API 測試工具
      • 一體化 API 平台
      • 章節總結
    • API Gateway
      • API Gateway:概覽
      • 什麼是 API Gateway?
      • API Gateway 的關鍵功能
      • API Gateway vs 負載平衡器 vs 服務網格
      • 流行 API Gateway 解決方案
      • BFF (Backend for Frontend) 模式
      • 章節總結
HomePetstore APIExplore more APIs
HomePetstore APIExplore more APIs
🌐 繁體中文
  • 🌐 English
  • 🌐 繁體中文
🌐 繁體中文
  • 🌐 English
  • 🌐 繁體中文
  1. API Fundamentals

請求 Body

在許多 API 中——特別是那些建立或更新資料的 API——請求中最重要的部分是請求 Body。與查詢或路徑參數(位於 URL 中)不同,請求 Body 是您發送結構化資料的地方,通常為 JSON 格式。
在這篇文章中,我們將解釋什麼是請求 Body、何時使用它,以及如何閱讀 API 文件中的 Body 規格。我們將使用 Pet Store API 進行演示。

1. 什麼是請求 Body?#

請求 Body 是您在 HTTP 請求內部發送的資料,通常用於:
POST (建立新資源)
PUT (取代資源)
PATCH (更新部分資源)
大多數 GET 請求不包含 Body。
請求 Body 通常格式化為 JSON,但有些 API 也支援:
XML
Form data (multipart/form-data 用於檔案)
URL-encoded form fields
但 JSON 是現代標準。
與查詢參數或 Header 不同,Body 可以容納複雜的結構化資料,例如巢狀物件、陣列、檔案或二進位內容。

1. 資料結構 (Schema):您應該發送什麼形狀的資料?#

在編寫請求 Body 之前,您必須了解描述預期結構的 資料結構 (Schema)。
讓我們使用 建立寵物 端點:
POST /pets
文件顯示了 Pet 物件的資料結構:

資料結構告訴您:
存在哪些欄位 (id, name, category 等)
類型 (數字 (number), 字串 (string), 陣列 (array), 物件 (object))
巢狀結構 (category 和 tags 是物件/物件陣列)
允許值 (例如 status 可能是 "available" | "pending" | "sold")
您發送的每個請求 Body 必須遵循此形狀。

2. JSON Body — 最常見的格式#

大多數現代 REST API 期望 JSON。
使用上述資料結構,這是一個用於 POST /pets 的有效 JSON 請求 Body:
{
  "name": "Lucky",
  "species": "DOG",
  "breed": "Golden Retriever",
  "ageMonths": 24,
  "size": "LARGE",
  "color": "Golden",
  "gender": "MALE",
  "goodWithKids": true,
  "goodWithPets": true,
  "adoptionFee": 150.00,
  "description": "Friendly golden retriever looking for an active family",
  "status": "AVAILABLE"
}
在 Apidog 中,當您需要根據 Body 資料結構建立請求 Body 時,您可以使用 Apidog 的 Auto-generate 功能來生成符合資料結構的 Body。
image.png

何時使用 JSON?#

建立或更新物件
發送結構化資料 (物件, 陣列)
大多數 API 用戶端和伺服器自動支援它
當發送 JSON 作為 Body 時,Content-Type Header 應設定為 application/json;但是,大多數工具會自動處理此問題,因此您通常無需擔心。

3. XML Body — 較不常見但仍在某些 API 中使用#

一些較舊的 API(或企業 API)支援 XML。
使用相同的資料結構,Body 也可以寫成 XML:
<Pet>
  <id>123</id>
  <name>Lucky</name>
  <category>
    <id>1</id>
    <name>Dog</name>
  </category>
  <photoUrls>
    <photoUrl>https://example.com/dog.jpg</photoUrl>
  </photoUrls>
  <tags>
    <tag>
      <id>10</id>
      <name>friendly</name>
    </tag>
  </tags>
  <status>available</status>
</Pet>
如果您發送 XML,您需要設定 Content-Type: application/xml Header。

4. multipart/form-data — 用於檔案上傳或混合欄位#

某些端點接受檔案,例如圖片。
在這些情況下,JSON 是不夠的 — 您必須使用 multipart/form-data。
讓我們使用 上傳寵物圖片 端點作為範例:
POST /pets/{id}/images
文件告訴您 Body 包含:
欄位類型描述
filebinary (二進位)要上傳的圖片
additionalMetadatastring (字串)(可選) 額外資訊
您可以點擊 file 欄位中的 "Upload" 來上傳二進位檔案。
image.png

何時使用 multipart/form-data?#

上傳圖片、PDF、影片
混合內容:文字 + 檔案
基於瀏覽器的表單提交

5. 重點摘要#

這裡有關於請求 Body 您應該記住的事情:
資料結構 (Schema) 告訴您 Body 必須遵循什麼形狀和欄位
JSON 是最常見的請求 Body 格式
XML 在某些 API 中仍然受支援
multipart/form-data 用於檔案上傳是必需的
始終匹配正確的 Content-Type
這告訴伺服器如何解釋您的 Body。

現在您了解了什麼是請求 Body、資料結構如何定義其結構,以及如何使用 JSON、XML 和 multipart/form-data 等不同格式,您準備好邁出下一步:學習如何閱讀和解釋伺服器發送回來的 回應。
Modified at 2025-12-29 09:35:19
Previous
參數
Next
回應
Built with