API Academy
🌐 繁體中文
  • 🌐 English
  • 🌐 繁體中文
HomePetstore APIExplore more APIs
HomePetstore APIExplore more APIs
🌐 繁體中文
  • 🌐 English
  • 🌐 繁體中文
🌐 繁體中文
  • 🌐 English
  • 🌐 繁體中文
  1. Designing APIs
  • 歡迎
  • 目錄
  • 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. Designing APIs

設計資料模型

在上一章中,您確定了您的 API 需要什麼資料。現在是時候設計資料模型並在 Apidog 中將其作為 schemas 實作了。
資料模型定義了您 API 資料的結構——存在什麼欄位、它們的類型、驗證規則以及如何使用它們。Schemas 是這些模型在 Apidog 中使用 JSON Schema 的技術實作。
在本章中,我們將學習如何設計資料模型並立即將它們作為 Apidog 中的 schemas 實作。我們將使用 Pet Store User 模組作為範例,逐步建立 schemas。

1. 什麼是資料模型和 Schemas?#

資料模型是資料結構的概念設計。Schema 是實作該模型的技術規格。
可以這樣想:
資料模型 = 藍圖(您設計的)
Schema = Apidog/OpenAPI 中的實際規格(您實作的)
在 Apidog 中,schemas 基於 JSON Schema 並定義:
欄位名稱和類型
必需 vs 可選欄位
驗證規則(格式、長度、模式)
巢狀物件和陣列
預設值

2. 設計流程#

在設計資料模型時,請遵循此方法:
1.
從需求開始 — 您需要什麼資料?(來自上一章)
2.
設計模型 — 什麼欄位、類型和規則?
3.
作為 schema 實作 — 在 Apidog 中建立它
4.
測試和完善 — 驗證設計
讓我們將其應用於 User 模組。

3. 設計 User 模型#

基於我們的需求分析,User 需要:
必需欄位:
id — 唯一識別碼(由系統生成)
email — 用於登入和通訊
firstName — 使用者的名字
lastName — 使用者的姓氏
createdAt — 帳戶建立時間戳記
可選欄位:
phone — 電話號碼
preferences — 使用者偏好(巢狀物件)
身分驗證:
password — 用於登入(絕不返回在回應中)

User 模型結構#

User 模型看起來像這樣:
{
  "id": "usr_3Oy2JIS7TMJgEXfM",
  "email": "jane.smith@example.com",
  "firstName": "Jane",
  "lastName": "Smith",
  "phone": "+14155551234",
  "preferences": {
    "newsletter": true,
    "notifications": false
  },
  "createdAt": "2024-01-15T10:30:00Z"
}

4. 在 Apidog 中建立 Schemas#

現在讓我們在 Apidog 中將此模型作為 schema 實作。Apidog 推薦的方法是直接貼上 JSON,它將自動識別並生成 schema 結構。

步驟 1:建立 User Schema#

1.
在您的 Apidog 專案中,前往 Schemas 部分
2.
點擊 ➕ 圖示並選擇 New Schema
3.
將其命名為 "User" 並新增描述:"User account information"

步驟 2:從 JSON 生成 Schema#

Apidog 允許您貼上 JSON 並自動生成 schema,而不是手動逐一新增屬性:
1.
點擊 Schema 編輯器中的 「Generate from JSON etc.」 按鈕
2.
貼上以下 JSON:
{
  "id": "usr_3Oy2JIS7TMJgEXfM",
  "email": "jane.smith@example.com",
  "firstName": "Jane",
  "lastName": "Smith",
  "phone": "+14155551234",
  "preferences": {
    "newsletter": true,
    "notifications": false
  },
  "createdAt": "2024-01-15T10:30:00Z"
}
3.
Apidog 將自動:
識別所有屬性及其類型
設定適當的資料類型 (string, boolean, object, date-time)
建立巢狀的 preferences 物件結構
注意: 預設情況下,JSON 中的所有屬性都將標記為 required。您需要手動調整可選欄位。

步驟 3:完善生成的 Schema#

從 JSON 生成後,完善 schema:
1.
將可選欄位標記為非必需:
取消勾選 phone 和 preferences 的 "Required"
2.
新增驗證規則:
id:新增模式 ^usr_[A-Za-z0-9]{16}$ 並標記為唯讀 (read-only)
email:設定格式為 email,新增最大長度 255
firstName 和 lastName:新增最大長度 50
phone:新增模式 ^\+?[1-9]\d{1,14}$ (E.164 格式)
createdAt:設定格式為 date-time 並標記為唯讀
3.
新增描述到每個欄位以獲得更好的文件說明
提示: Apidog 的 JSON 智慧識別會根據 JSON 值生成資料結構,但不會保存實際值。您可以隨後新增描述並調整驗證規則。

5. 建立巢狀 Schemas:UserPreferences#

preferences 欄位是一個巢狀物件。讓我們為它建立一個單獨的 schema,以便我們可以重複使用它。

步驟 1:建立 UserPreferences Schema#

1.
建立一個名為 "UserPreferences" 的新 schema
2.
新增描述:"User communication preferences"

步驟 2:從 JSON 生成#

1.
點擊 「Generate from JSON etc.」
2.
貼上此 JSON:
{
  "newsletter": true,
  "notifications": false
}
3.
Apidog 將自動識別兩個 boolean 欄位

步驟 3:完善 Schema#

1.
將兩個欄位標記為可選(取消勾選 "Required")
2.
設定預設值:
newsletter:預設 false
notifications:預設 true
3.
新增描述到每個欄位

步驟 4:在 User Schema 中引用#

現在回到 User schema 並:
1.
選擇 preferences 屬性
2.
將其類型更改為 Reference
3.
從清單中選擇 UserPreferences
這建立了一個引用,允許您重複使用 UserPreferences schema。如果您稍後更新 UserPreferences,所有引用都會自動反映這些更改。

6. Schema 最佳實踐#

在設計 schemas 時,請記住這些原則:

保持簡單 (Keep It Simple)#

避免過度設計: 不要新增「以防萬一」的欄位
儘可能使用簡單類型: 適當時優先選擇 string 而不是複雜物件
將相關欄位分組: 使用巢狀物件進行邏輯分組(如 preferences)

避免過度巢狀 (Avoid Over-Nesting)#

盡量將巢狀保持在最多 2-3 層。深度巢狀使 schemas 難以理解和使用。

使用 Schema 引用#

當您有可重複使用的結構(如 UserPreferences)時,建立單獨的 schemas 並引用它們。這:
減少重複
使更新更容易
提高一致性

安全考量#

絕不在回應 schemas 中包含密碼
使用唯寫 (write-only) 用於敏感輸入欄位 (password)
使用唯讀 (read-only) 用於系統生成的欄位 (id, createdAt)
根據您的規則驗證所有輸入

為可擴展性規劃#

使用可選欄位用於新功能
避免移除欄位(改為標記為棄用)
使用 API 版本控制用於重大變更

7. 關鍵收穫#

設計和實作資料模型是關鍵步驟:
1.
資料模型定義您的 API 使用什麼資料
2.
Schemas 是 Apidog 中的技術實作
3.
使用「Generate from JSON」 以從 JSON 資料快速建立 schemas
4.
使用 schema 引用用於可重複使用的結構(如 UserPreferences)
5.
首先建立核心 schemas — 請求/回應變體可以在端點層級處理
6.
安全很重要: 使用唯寫用於敏感欄位,唯讀用於系統生成欄位
7.
保持簡單: 避免過度巢狀和過度設計

既然您已經設計並實作了核心 schemas,您準備好開始建構端點了。在下一章中,我們將學習如何在 Apidog 中設計端點,使用我們建立的 schemas 和我們之前規劃的端點結構。
讓我們繼續 設計端點。
Modified at 2025-12-29 09:35:19
Previous
分析需求並規劃您的 API
Next
設計端點
Built with