REST API
1. 為什麼你應該關心
REST(REpresentational State Transfer,表述性狀態轉移)是 Web 服務事實上的標準風格:你會遇到的公共 API 中大約每 10 個就有 8 個遵循它,因此掌握其基礎知識,幾乎就能與任何現代後端通訊。(Integrate.io)
2. 60 秒瞭解 REST
REST API 通過普通的 HTTP 公開資源(名詞,例如 /users/42)。客戶端使用標準動詞對這些資源進行操作:
| 動詞 | 典型用途 | 冪等? |
|---|---|---|
| GET | 讀取 | ✔︎ |
| POST | 建立 / 其他操作 | ✖︎ |
| PUT | 替換 | ✔︎ |
| PATCH | 部分更新 | ✖︎ |
| DELETE | 刪除 | ✔︎ |
RESTful 伺服器還必須遵循六項架構約束(統一介面、客戶端-伺服器、無狀態、可快取、分層系統,以及可選的按需程式碼)。(restfulapi.net,Integrate.io)
3. 常見響應碼
- 200 OK / 201 Created——成功
- 400 Bad Request——客戶端錯誤(JSON 格式錯誤、缺少欄位)
- 401/403 Unauthorized / Forbidden——認證/授權問題
- 404 Not Found——URI 錯誤或記錄不存在
- 500+ 伺服器錯誤——bug、服務中斷等。(Postman Blog)
4. 一個小小的“Hello World”示例
GET https://api.example.com/items/123
Accept: application/json
典型的 JSON 響應:
{
"id": 123,
"name": "Widget",
"price": 9.99
}
5. 在 Divooka 中試用 REST
在 Divooka 中,你可以用節點圖來構建請求,而不必填寫冗長的表單:
- Send (HTTP) Request 節點——設定為 GET,URL 為
{{baseUrl}}/items/{{itemId}}。 - Headers——放置一個 Custom Header 節點,用於
Accept: application/json這樣的鍵值對。 - (可選)Auth node——選擇 Basic、Bearer 或 OAuth 2.0。
- 使用 Preview JSON 節點解析 JSON 負載——它會美化列印響應體並進行型別檢查。
一切都是視覺化且可複用的:把同一個響應連線到後續邏輯中(儲存到資料庫、更新 UI、觸發另一個請求),無需編寫膠水程式碼。

你可以在 Web API 測試頁面檢視更多實際示例。
環境變數
在 Environments 中定義一次 baseUrl、apiKey 或 authToken,然後就可以在任何地方通過 Get Environment Variable 節點引用它們。使用 Switch 節點在不同環境(dev/staging/prod)之間切換。
儲存與共享
把相關的請求儲存並歸組到圖中,作為文件儲存,以便輕鬆複用和共享。
6. 最佳實踐清單
設計你自己的 REST API 時:
- URI 以名詞為基礎(使用
/orders/17,而不是/getOrder)。 - 使用正確的動詞(不要用
GET /deleteUser)。 - 提供分頁和過濾(
?page=2&limit=50)。 - 在路徑或請求頭中標明版本(
/v1/),絕不破壞現有客戶端。 - 使用 HTTPS、身份驗證和合理的速率限制來保障安全。
- 使用 OpenAPI 編寫文件;Divooka 可以匯入該規範並自動生成節點腳手架。(idratherbewriting.com)
7. 延伸閱讀
- 還想了解更多?請檢視我們對 HTTP、方法與 Web API 這一主題的深入討論。
- Divooka 中的使用文件。
- Roy Fielding 的 REST 博士論文(原始出處)
- RFC 9110——HTTP 語義
- Postman 的“REST API examples”部落格文章,介紹真實場景中的模式(Postman Blog)
- Divooka Wiki → App Development > API Testing(深入介紹每個節點和功能)
掌握了這些要點,你就可以自信地探索任何 REST 端點,並將其接入你的 Divooka 流程,以滿足你的應用需求。