Apidog Docs
🇨🇳 繁體中文
🇺🇸 English
🇯🇵 日本語
🇪🇸 Español
🇰🇷 한국인
🇨🇳 简体中文
🇵🇹 Português (Portugal)
🇮🇩 Bahasa Indonesia
🇧🇷 Português (Brasil)
🇻🇳 Tiếng Việt
🇨🇳 繁體中文
🇨🇳 繁體中文
🇺🇸 English
🇯🇵 日本語
🇪🇸 Español
🇰🇷 한국인
🇨🇳 简体中文
🇵🇹 Português (Portugal)
🇮🇩 Bahasa Indonesia
🇧🇷 Português (Brasil)
🇻🇳 Tiếng Việt
🇨🇳 繁體中文
🇨🇳 繁體中文
🇺🇸 English
🇯🇵 日本語
🇪🇸 Español
🇰🇷 한국인
🇨🇳 简体中文
🇵🇹 Português (Portugal)
🇮🇩 Bahasa Indonesia
🇧🇷 Português (Brasil)
🇻🇳 Tiếng Việt
🇨🇳 繁體中文
Learning Center
Home
Support Center
API References
Download
Changelog
Learning Center
Home
Support Center
API References
Download
Changelog
設計 API
Copy Page
Apidog 學習中心
開始使用
Apidog 簡介
Apidog 中的基本概念
導覽 Apidog
快速開始
概覽
建立端點
發送請求
新增斷言
建立測試情境
分享 API 文件
探索更多
遷移到 Apidog
概覽
手動匯入
排程匯入(綁定資料來源)
匯入選項
匯出資料
匯入自
從 Postman 匯入
匯入 OpenAPI 規格
匯入 cURL
匯入 Markdown
從 Insomnia 匯入
從 apiDoc 匯入
匯入 .har 檔案
匯入 WSDL
Mock API 資料
概述
Smart Mock
自訂模擬
模擬優先順序
模擬腳本
雲端模擬
自託管 Runner 模擬
模擬語言(Locales)
帳號與偏好設定
帳戶設定
產生 OpenAPI 存取權杖
通知
語言設定
快捷鍵
網路代理設定
備份資料
更新 Apidog
刪除帳戶
實驗性功能
傳送請求
概覽
SSE 偵錯
MCP Client
Socket.IO
WebSocket
Webhook
SOAP 或 WebService
GraphQL
gRPC
使用請求代理代理程式進行偵錯
建立請求
請求歷史記錄
請求基礎
參數與主體
請求標頭
請求設定
偵錯請求
將請求儲存為端點
HTTP/2
驗證與授權
概覽
CA 和用戶端憑證
授權類型
Digest Auth
OAuth 1.0
OAuth 2.0
Hawk 驗證
Kerberos
NTLM
Akamai EdgeGrid
回應和 Cookie
檢視 API 回應
管理 Cookie
概覽
開發和偵錯 API
概觀
產生請求
傳送請求
偵錯案例
測試案例
動態值
驗證回應
Design-First 與 Request-First
產生程式碼
環境與變數
概述
使用變數
環境管理
Vault 密鑰
概覽
HashiCorp Vault
Azure Key Vault
AWS Secrets Manager
動態值模組
Airline
動物
顏色
Commerce
Company
資料庫
Datatype
日期
Finance
Food
Git
Hacker
Helpers
圖片
Internet
位置
Lorem
音樂
Number
Person
Phone
科學
字串
System
Vehicle
Word
前置和後置處理器
概覽
斷言
擷取變數
Wait
安全性
資料庫操作
概述
MySQL
MongoDB
Redis
Oracle Client
使用腳本
概觀
前置處理器指令碼
後置處理器腳本
公開腳本
Postman Scripts Reference
呼叫其他程式語言
使用 JS Libraries
視覺化回應
腳本範例
斷言腳本
使用變數
修改請求
其他範例
API 偵錯
AI Agent Debugger
A2A Debugger
設計 API
概覽
建立新的 API 專案
端點基礎
APl 設計指南
模組
設定多個請求主體範例
元件
通用欄位
全域參數
端點變更歷史
留言
批次端點管理
自訂協定 API
Spec-first 模式 (Beta)
安全方案
概觀
建立安全性方案
使用 Security Scheme
線上文件中的安全性方案
進階功能
自訂端點欄位
關聯的測試場景
端點狀態
參數列表的外觀
端點唯一識別
Schemas
概述
建立新 Schema
建立 Schema
從 JSON 等產生 Schema
oneOf, allOf, anyOf
使用 Discriminator
API 測試
概述
測試情境
建立測試情境
在請求之間傳遞資料
流程控制條件
從端點和端點案例同步資料
從其他專案匯入端點和端點案例
匯出測試情境
測試報告
測試報告
執行測試情境
執行測試場景
批次執行測試場景
資料驅動測試
共享測試資料
排程任務
管理來自其他專案的 API 執行環境
測試套件
概述
建立測試套件
編排測試套件
在本機執行測試套件
透過 CLI 執行測試套件
排程任務
測試 API
整合測試
效能測試
端對端測試
迴歸測試
契約測試
Apidog CLI
概覽
安裝並執行 Apidog CLI
Apidog CLI 選項
CI/CD
概述
與 Github Actions 整合
Integrate with Gitlab
與 Jenkins 整合
透過 Git Commit 觸發測試
發布 API 文件
概述
支援的 API 技術
快速分享
檢視 API 文件
Markdown 文件
發佈文件網站
自訂登入頁面
自訂版面配置
自訂 CSS 、JavaScript、HTML
自訂網域
AI Features
SEO 設定
進階設定
文件搜尋
CORS Proxy
整合 Google Analytics
資料夾樹設定
可見性設定
在文件 URL 中嵌入值
API 版本
概述
建立 API 版本
發佈 API 版本
使用 API 版本分享端點
分支
概觀
建立 Sprint 分支
在分支中測試 API
在分支中設計 API
合併 Sprint 分支
管理 Sprint 分支
AI Branch (Beta)
AI 功能
概觀
啟用 AI 功能
產生測試案例
使用 AI 修改 Schema
端點合規性檢查
API 文件完整性檢查
AI 驅動的欄位命名
常見問題
Apidog MCP 伺服器
概覽
將 Apidog 專案連接至 AI
將已發布的文件連接至 AI
將 OpenAPI 檔案連接到 AI
Apidog Europe
Apidog Europe
最佳實務
處理 API 簽章
存取受 OAuth 2.0 保護的 API
協作工作流程
管理驗證狀態
離線空間
概述
管理
管理專案
管理專案
通知設定
管理專案成員
專案資源
資料庫連線
Git 連線
管理團隊
管理團隊
管理團隊成員
團隊活動
團隊角色與權限
團隊資源
General Runner
團隊變數
請求代理代理程式
即時協作
團隊協作
入門檢查清單
基本概念
入門指南
管理組織
管理組織
組織角色與權限
方案管理
組織中的帳單管理員
單一登入 (SSO)
SSO 概覽
設定 Microsoft Entra ID
設定 Okta
為組織設定 SSO
管理使用者帳戶
將群組對應到團隊
SCIM 佈建
SCIM 佈建簡介
Microsoft Entra ID
Okta
組織資源
自託管 Runner
帳單
概觀
點數
升級您的方案
替代付款方式
管理訂閱
將付費團隊移至組織
附加元件
API Hub
Apidog Intellij IDEA 外掛
瀏覽器擴充功能
Chrome
Microsoft Edge
請求代理
Web 中的請求代理
共用文件中的請求代理
用戶端中的請求代理
資料與安全
資料儲存與安全性
使用者資料隱私與安全
請求路由與資料安全
參考
API 設計優先方法
Apidog OpenAPI 規格擴充
JSONPath
XPath
正規表示式
JSON Schema
CSV 檔案格式
安裝 Java 環境
Runner 部署環境
Apidog Markdown 語法
Apidog Swagger 擴充
概述
x-apidog-folder
x-apidog-status
x-apidog-name
x-apidog-maintainer
Apidog JSON Schema 擴充
概述
x-apidog-mock
x-apidog-orders
x-apidog-enum
支援中心
設計 API
Copy Page
Spec-first 模式 (Beta)
Spec-first 模式
適用於希望將 API 規格檔案作為單一事實來源的團隊。在此模式中,你可以直接在 Apidog 中設計與維護 OpenAPI 或 Swagger 檔案,在編輯時預覽產生的 API 文件,並讓檔案與 Git 保持同步。
當你的團隊已經使用 YAML 或 JSON 規格檔案、透過 Git 審查 API 變更,或希望 API 設計自然融入程式碼儲存庫工作流程時,請使用 Spec-first 模式。
Spec-first 模式的運作方式
#
在一般的 Apidog 專案中,API 通常是透過視覺化表單建立與編輯。在 Spec-first 專案中,主要工作區是以檔案為基礎。
你會使用如下檔案:
openapi.yaml
openapi.json
Swagger 2.0 檔案
Markdown 檔案及其他支援專案檔案
Apidog 會解析規格檔案,並將其轉換為可瀏覽的 API 結構。你可以編輯原始檔案、使用支援 的視覺化表單、驗證規格、預覽產生的文件,並將變更推送回 Git。
建立 Spec-first 專案
#
1
點選
+ New Project
。
2
在專案類型選擇器中,選擇
Spec-first Mode
。
3
連接 Git 提供者,例如 GitHub、GitLab、Azure DevOps 或 Bitbucket。
4
選擇組織或工作區,然後選擇既有儲存庫,或在選項可用時建立新的儲存庫。
5
選擇 Apidog 應同步的主分支。
6
選擇是否安裝 webhook。
安裝 webhook 可讓 Git 儲存庫中的推送觸發自動同步。這通常需要該儲存庫的管理員權限。如果你沒有管理員權限,可以略過 webhook 安裝並手動同步。
7
輸入專案名稱、設定成員權限,然後點選
Create
。
建立後,Apidog 會執行第一次同步。如果儲存庫的預設分支不是
main
,Apidog 會使用儲存庫分支名稱作為專案主分支。
Spec-first 專案不包含範例專案資料。API 內容來自你的規格檔案。
Specs 工作區
#
Spec-first 專案在左側邊欄中包含
Specs
工作區。這是管理規格檔案與 Git 同步的主要位置。
工作區包含三個主要區域:
檔案總管
:瀏覽並管理來自同步儲存庫的檔案與資料夾。
API 結構樹
:瀏覽已解析的 OpenAPI 內容,例如概觀、端點、結構描述與定義。
編輯器
:以程式碼檢視編輯檔案;或針對支援的 OpenAPI 節點,以表單檢視編輯。
當你在結構樹中選擇端點、結構描述或其他支援的節點時,Apidog 會開啟來源檔案中的相關部分。這讓你可以在檔案層級檢視與 API 層級檢視之間切換,而不必離開 Specs 工作區。
編輯規格檔案
#
編輯器支援不同的檔案類型與編輯模式。
程式碼檢視
#
使用
Code
檢視直接編輯 YAML、JSON、Markdown 及其他文字檔案。這是在 Spec-first 模式中工作的預設方式。
表單檢視
#
針對支援的 OpenAPI 節點,Apidog 也提供
Form
檢視。這可讓你透過結構化控制項編輯常見 API 欄位,同時仍將底層規格檔案作為單一事實來源。
表單檢視適用於支援的節點,例如:
API 概觀
端點
結構描述
定義
如果選取的檔案或節點無法在表單檢視中編輯,Apidog 會讓你維持在程式碼檢視。
編輯時驗證與預覽
#
Spec-first 模式在編輯器標頭中包含驗證與預覽工具。
驗證
#
Validation
面板會顯示目前規格中偵測到的問題,包括警告與錯誤。驗證徽章會顯示偵測到的問題總數。
使用此面板在提交變更前找出語法問題、缺少必要欄位以及規則違反。
預覽
#
Preview
面板會顯示所選規格節點在產生的 API 文件中會如何呈現。
預覽適用於:
API 概觀
端點
結構描述
定義
對於端點,Preview 包含:
Docs
:產生的端點文件。
Try it out
:用於根據所選端點定義傳送請求的請求面板。
對於結構描述、定義與概觀節點,Preview 會顯示產生的文件檢視。
Validation 與 Preview 使用相同的側邊面板。開啟其中一個會關閉另一個。
從 Git 同步變更
#
當其他團隊成員將變更推送到已連接的儲存庫時,你可以將最新檔案拉取到 Apidog。
1
開啟
Specs
工作區。
2
在 Specs 側邊欄中點選目前分支名稱。
3
點選
Git Pull
。
如果已安裝 webhook 同步,Apidog 也可以從 Git 提供者接收推送事件並自動觸發同步。
提交並推送變更到 Git
#
在 Apidog 中編輯檔案後,將你的變更推送回已連接的儲存庫。
1
在 Specs 工作區中編輯一個或多個檔案。
2
點選
Changes
以檢視已修改、新增、重新命名與刪除的檔案。
3
點選
Commit & Push
。
4
在
Push to Git repo
彈窗中,選擇你想包含的檔案。
5
輸入提交訊息。
6
點選
Push
。
如果你不想保留本機編輯,請在推送前使用
Discard all changes
。
管理分支
#
Spec-first 模式支援以分支為基礎的協作。Apidog 會將同步的 Git 分支對應到專案分支,讓你可以在不同版本的規格之間切換。
切換分支
#
在 Specs 側邊欄中點選分支名稱,並從下拉選單選擇另一個分支。
追蹤既有 Git 分支
#
如果某個分支存在於 Git 中但尚未匯入 Apidog,請點選
Import New Branch
,選擇該分支並匯入。Apidog 隨後會開始追蹤並同步該分支。
建立分支
#
開啟
Project Settings > Git & Branches
,然後點選
New Branch
,從既有專案分支建立分支。
重新同步分支
#
如果分支同步失敗或檔案看起來不是最新狀態,請在
Project Settings > Git & Branches
中使用
Re-sync
。這會重設該分支的同步狀態並再次匯入檔案。
檢視同步記錄
#
如果同步失敗,請開啟分支操作並選擇
View Logs
,以檢查同步詳細資料。
停止追蹤或刪除分支
#
刪除已追蹤的分支會將其從 Apidog 的同步設定中移除。對於非主分支,也可以移除專案分支記錄。
Webhook 同步與權限
#
Webhook 同步是選用功能,但建議希望 Apidog 隨儲存庫推送保持最新狀態的團隊使用。
啟用 webhook 同步時:
Apidog 會在已連接的 Git 提供者上註冊 webhook。
只會處理支援的推送事件。
Apidog 會在同步前驗證 webhook 簽章或權杖。
權限需求:
安裝 webhook 通常需要儲存庫管理員權限。
推送變更需要寫入權限。
如果略過 webhook 安裝,仍可使用手動同步。
如果你在建立專案時略過 webhook 安裝,可以稍後從
Project Settings > Git & Branches
安裝。
以儲存空間為後端的 Spec-first 專案
#
某些 Spec-first 專案可能會使用 Apidog 的內部儲存空間,而不是外部 Git 儲存庫。
這些專案仍會使用 Specs 工作區、以檔案為基礎的編輯、驗證、預覽與分支管理。
UI 標籤略有不同:
Git Pull
會顯示為
Sync
。
Commit & Push
會顯示為
Save
。
Git 提供者資訊與外部 webhook 設定會隱藏。
注意事項與限制
#
Spec-first 模式目前處於 beta 階段。
Specs 工作區只會出現在 Spec-first 專案中。
Spec-first 專案不會建立範例 API 資料。
規格檔案是
單一事實來源
。變更應透過 Specs 工作區進行,或透過 Git 同步。
如果你沒有足夠的儲存庫權限,webhook 安裝可能會失敗。只要你有寫入權限,仍可使用手動同步。
Modified at
2026-06-11 10:26:02
Previous
自訂協定 API
Next
概觀