公家機關資料 API 製作與資料治理

背景

這份筆記整理自「公家機關資料 API 如何製作」的實習課程內容。核心概念是：API 不只是把資料放上網的技術工具，而是政府資料的自動化服務窗口。過去民眾、企業或其他機關要取得政府資料，可能需要下載 Excel、查詢網站、寄公文或人工索取；導入 API 後，外部系統可以透過固定網址與固定格式自動取得資料。因此 API 製作牽涉的不只是程式技術，而是資料治理、個資保護、資安控管、跨機關協作與長期維運的綜合工程。

知識架構圖

公家機關資料 API 製作
├─ 一、先分清楚 API 的類型
│   ├─ 公開資料 API：交通事故、天氣、停車場空位、法規、統計資料
│   │   （放於政府資料開放平臺，重點是開放格式、機器可讀、可重複利用）
│   └─ 機關間介接 API：A 機關同步資料給 B 機關、地方對中央同步詮釋資料
│       （須控管 IP、API Key、HTTP Basic Authentication 等身分驗證）
│
├─ 二、製作流程（資料 → 服務的六個層次）
│   ├─ 1. 資料盤點：確認資料是否可公開
│   │   ├─ 是否涉及個資、偵查不公開、國安或內部作業機密
│   │   └─ 是否會造成特定人、地點、案件被識別
│   ├─ 2. 資料整理與去識別化
│   │   ├─ 統一欄位名稱、日期格式、縣市／行政區名稱
│   │   ├─ 移除個人姓名、電話、身分證字號、完整地址等敏感資訊
│   │   └─ 敏感資料可改整理成統計形式（如月份、行政區、案類、案件數）
│   ├─ 3. 資料庫與資料品質管理
│   │   ├─ 資料庫像倉庫，API 像對外窗口
│   │   └─ 須有更新紀錄、版本控管、資料來源追蹤、錯誤回報機制
│   ├─ 4. API 設計（RESTful 風格 + OpenAPI Specification）
│   │   ├─ 網址設計：GET /api/v1/police-stations
│   │   ├─ 查詢條件：縣市、行政區、年度、案類、分頁等
│   │   ├─ 回傳格式：JSON（含 data 與 meta，如總筆數、頁數、更新時間）
│   │   └─ 明確錯誤代碼（查無資料、參數錯誤、權限不足、系統維護中）
│   ├─ 5. 資安與權限控管
│   │   ├─ 公開 API：HTTPS、流量限制、使用紀錄、防 SQL Injection、
│   │   │   錯誤訊息不洩漏系統細節
│   │   └─ 機關間 API：API Key、IP 白名單、身分驗證、權限分級、稽核紀錄
│   └─ 6. API 文件與維運
│       ├─ 文件須含：名稱、資料說明、網址、方法、參數、回傳欄位、
│       │   更新頻率、授權方式、錯誤代碼、範例請求與回應、聯絡窗口
│       └─ 上線非結束，需持續監控資料是否更新、使用量是否異常
│
└─ 三、公家機關 API 最重要的六個重點
    ├─ 合法性：資料是否可公開，是否涉及個資、偵查、機密
    ├─ 標準化：欄位名稱、格式、更新頻率固定
    ├─ 機器可讀：提供 JSON／CSV／XML，而非只有 PDF
    ├─ 文件完整：讓外部開發者知道怎麼查、查到什麼
    ├─ 資安控管：公開 API 也要限流、記錄、防攻擊
    └─ 維護更新：資料須定期更新，不能上架後放著不管

串聯邏輯：為什麼會這樣設計？

民眾、企業或其他機關過去要取得政府資料，只能靠下載 Excel、查詢網站、寄公文或人工索取，效率低且格式不統一 → 因此需要一個「自動化服務窗口」，也就是 API，用固定網址與固定格式讓外部系統自動取得資料 → 但公部門資料常涉及個資、偵查不公開或內部機密，不能直接把原始資料公開，必須先盤點哪些能公開、哪些要去識別化 → 去識別化與整理後的資料若欄位混亂、格式不一致，外部系統依然難以使用，因此要先標準化（統一欄位、日期、地名格式） → 標準化後的資料放入資料庫，再透過 RESTful API 設計固定網址、查詢條件與 JSON 回傳格式，讓資料變成「可程式化查詢的服務」 → 但只要對外提供服務，就一定要考慮資安：公開 API 仍需限流、記錄與防攻擊，機關間介接更需要 API Key、IP 白名單與身分驗證 → 最後，API 沒有文件就像窗口沒有告示牌，因此必須提供完整文件；上線後也要持續維運更新，才能真正成為長期可信賴的資料服務 → 整體而言，API 的目的不是「公開資料」這麼簡單，而是建立一套讓資料能被信任、被介接、被持續使用的治理制度。

重點摘要（可放入實習心得）

透過學習公家機關資料 API 的製作，我理解到政府數位轉型並不是單純導入新系統，而是把原本分散、人工、靜態的資料，整理成可被系統自動使用的服務。API 看起來只是技術介面，但背後其實包含資料盤點、資料品質管理、個資保護、資安控管、跨機關協作與長期維運。尤其在公部門場域中，資料不能只求方便，還必須兼顧合法性、正確性、安全性與穩定性。

我認為 API 的角色就像政府資料的「標準化出口」：如果資料沒有整理，API 只是把混亂資料包裝起來；如果沒有資安控管，API 可能成為風險來源；如果沒有文件與維護，API 上線後也難以被真正使用。因此，公部門資料 API 的核心價值，不只是開放資料，而是建立一套能讓資料被信任、被介接、被持續使用的制度。

這也讓我理解到，資訊工作在公家機關中不只是寫程式或維護系統，而是要協助機關把業務資料轉化為可治理、可服務、可決策的資源。未來若能結合資料中心、API、資安管理與 AI 分析，公部門就能從被動提供資料，進一步走向主動分析、預警與智慧決策。這與先前課程中「資料治理」「資安分級」「AI 導入須顧及資料敏感性」等主題的邏輯是一致的，顯示無論是勤務系統、資料中心維運或資料開放 API，公部門資訊工作的共同核心都是「效率」與「安全治理」的平衡。

事實查核表

內容	核實結果	報告寫法建議
政府資料應以開放格式、機器可讀且具一定品質方式提供	已確認，符合台灣政府資料開放作業原則之明文規定	可直接寫入報告
公部門 API 以 RESTful 風格為主，並導入 OpenAPI Specification	已確認，政府資料開放平臺之共通性應用程式介面指引採此原則	可直接寫入
跨平臺介接會以資料來源 IP、API Key 與 HTTP Basic Authentication 進行身分確認	已確認，屬政府資料開放平臺機關發布開發指引內容	可直接寫入
政府資料開放授權條款原則上可不限目的、時間及地域利用，但須標示資料來源	已確認	可直接寫入，並提醒使用時應標明資料來源與提供機關
資料集清單通常含名稱、格式、下載連結、描述、主要欄位、提供機關、更新頻率、授權方式、編碼格式、聯絡資訊	已確認，為政府資料開放平臺實務常見欄位	可作為 API／資料集文件設計參考

三個反思點

API 的技術難度其實不是最高門檻，「資料能不能公開」的判斷才是。 盤點資料是否涉及個資、偵查不公開或機密，需要法規素養而非只是工程能力，這也呼應了先前資安與個資保護課程中反覆強調的「合法性優先於便利性」原則。
標準化是自動化與 AI 應用的地基。 這和智慧化維運課程中「先標準化、再自動化、才能 AI 化」的邏輯完全一致——如果資料欄位、格式都不統一，無論是 API 介接或 AI 分析都很難真正發揮效用。
公開 API 不代表可以不設防。 即使是完全公開、免登入的資料服務，仍必須考慮流量限制、使用紀錄與資安防護，這提醒我「公開」與「不設防」是兩回事，資安意識應該貫穿所有對外服務,而不只是內部系統。