Public APIs：高星 GitHub 公共 API 清單，適合原型但不能把「免費」當成 SLA

先確認正確倉庫與目前定位

原文只說「GitHub 搜尋 public-apis 即可找到該倉庫」，容易讓讀者混淆同名專案。這次查核的正確倉庫是 public-apis/public-apis，GitHub API description 為「A collective list of free APIs」，授權為 MIT。README 開頭也明確說，這個 repository 是由社群成員與 APILayer 相關人員手動整理，收錄許多領域的 public APIs，可作為多年社群維護的 API treasure trove。這些是可以寫入文章的可查證事實。

星數方面，原文的 46.2 萬顆星大致符合查核時 GitHub API 顯示的 466,000+ stars 等級；但星數會變動，文章不應把它當成固定規格。API 數量也不宜只寫「1000+」就結束；研究腳本在 README 中解析到約 1700 筆 API row 與 50 多個分類，但 README 隨時會因 PR、刪除、分類重整而改變。因此正文可寫「收錄上千個條目」或「查核時 README 解析約 1700 筆」，並明確標示這是當時快照而非永久數字。

它提供什麼欄位，為什麼對原型有用

Public APIs 的價值在於降低找資料源的時間。README 以分類索引組織條目，例如 Animals、Anime、Anti-Malware、Art & Design、Authentication & Authorization、Blockchain、Books、Business、Calendar、Weather、Transportation、URL Shorteners 等。每個 API 條目通常包含名稱、說明、Auth、HTTPS 與 CORS 等欄位；這些欄位對前端 demo、教學作業、資料清洗練習、低風險內部工具非常有用，因為工程師可以先篩出不需 OAuth、支援 HTTPS、瀏覽器環境可用的候選服務。

不過，欄位存在不代表服務一定可直接上 production。Auth 顯示「No」只代表清單中的維護者如此標註，不代表沒有速率限制、沒有隱性使用條款、沒有 IP 封鎖、沒有資料授權限制。CORS 顯示支援，也不代表瀏覽器端應直接暴露商業金鑰。對 BigIntTech 或 Allen 的實務工作流來說，Public APIs 應作為第一層篩選，而不是最終供應商評選。

使用場景	適合程度	原因
教學範例	高	可快速找到天氣、貨幣、圖片、文字、動漫等資料源
Hackathon / PoC	高	能用低成本驗證 UI、資料流程與 API 串接
內部一次性工具	中	可用，但仍需記錄來源與限制
正式商業產品	低到中	必須逐項查 SLA、商業條款、隱私與穩定性

免費 API 的四個風險

第一是可用性風險。社群清單可能仍連到已停用、搬家或改成付費的服務；即使 PR 曾經驗證，幾個月後也可能失效。第二是授權風險。Public APIs 倉庫本身是 MIT，代表清單內容的程式碼/文件整理方式較寬鬆，但不代表每個被列出的第三方 API 都是 MIT、都允許商業再利用。第三是隱私與法遵風險。若 API 涉及地理位置、email 驗證、金融、航班、健康或使用者資料，應先查資料處理條款與區域合規。第四是成本風險。許多「free」服務可能只是有免費額度，超額後需要付款、限速或綁定帳號。

建議的使用 SOP

1. 從 README 分類找候選 API，不要直接把第一個結果寫進產品。
2. 進入該 API 的官方文件，確認授權、rate limit、商業使用、資料來源與停用政策。
3. 用最小請求測試可用性，記錄 HTTP 狀態、CORS、回應格式與錯誤行為。
4. 若要進 production，替每個外部 API 加 timeout、retry、fallback、cache 與監控。
5. 若資料要進 KB、CRM 或客戶系統，額外檢查資料授權與隱私條款。

對 Allen KB 的整理價值