API 概覽
一個平台，兩種 API，職責清楚分明。
Flowtig API 是整個平台的基礎。
每個 Flowtig 用戶端——無論是網頁應用程式、原生 macOS 應用程式，還是背景服務——都透過相同的公開 API 層進行通訊。業務邏輯集中於後端，確保所有用戶端都具有一致的行為。
Flowtig 採用 API 優先的設計方式，將 API 視為平台的主要介面，而不只是實作細節。
API 優先架構
每個 Flowtig 應用程式都透過相同的 API 進行通訊。
沒有享有特殊權限的用戶端、隱藏端點，也沒有只存在於特定前端的業務邏輯。
為什麼有兩種 API？
Flowtig 將業務功能與平台功能分開。
因此形成兩種互補的 API，各自具有明確的職責。
| API | 用途 |
|---|---|
| GraphQL | 業務應用程式與領域資料 |
| REST | 平台服務與系統操作 |
這樣的分工讓平台保持可預測、可擴充且容易維護。
GraphQL
GraphQL 是 Flowtig 應用程式的主要 API。
所有業務應用程式都透過 GraphQL 進行通訊，包括：
GraphQL 負責：
- 業務資料
- 查詢
- Mutation
- 強型別
- 租戶專屬資料
- 精確選擇所需欄位
如果您正在開發 Flowtig 應用程式，GraphQL 將會是您的主要介面。
→ 繼續閱讀 GraphQL 文件。
REST
REST 用於平台層級的功能。
典型範例包括：
- 驗證
- 組織管理
- 訂閱管理
- 計費
- 系統管理
- 檔案發布
- 更新來源
REST 端點負責屬於平台本身的功能，而不是個別業務應用程式的功能。
→ 繼續閱讀 REST 文件。
原生的多租戶支援
每個 API 請求都會在單一組織的環境中執行。
Flowtig 會自動強制執行：
- 租戶隔離
- 以角色為基礎的權限
- 成員資格驗證
- 服務權限
- 以 Token 為基礎的驗證
應用程式永遠無法存取其所屬組織環境之外的資料。
更多資訊請參閱架構文件。
多用戶端架構
Flowtig 的設計支援多種用戶端，而不需要修改業務邏輯。
目前的用戶端包括：
- 網頁應用程式
- 原生 macOS 應用程式
- 背景工作程序
未來可以加入行動應用程式或命令列工具等其他用戶端，而不需要修改平台架構。
設計原則
Flowtig API 遵循幾項基本原則。
API 優先
每項功能都先透過 API 實作，再由用戶端使用。
明確的職責
業務功能屬於 GraphQL。
平台功能屬於 REST。
明確且穩定的契約
API 為所有用戶端提供穩定且可預測的介面。
租戶隔離
每個請求都會在其所屬組織的環境中進行評估。
長期演進
可以加入新的應用程式，而不需要改變平台架構。
接下來從哪裡開始？
根據您想要開發的內容，可以從以下指南開始。
| 我想要…… | 從這裡開始 |
|---|---|
| 建立 Flowtig 應用程式 | GraphQL |
| 與平台進行整合 | REST |
| 了解平台架構 | 架構 |
| 探索現有應用程式 | 應用程式 |
需要協助嗎？
正在尋找更多資訊？