用API Gateway + Lambda打造溫度數據查詢REST API，串接工廠儀表板
工廠IT技術人員專用Amazon API GatewayREST APIATLANTIS 自有品牌
用API Gateway + Lambda打造溫度數據查詢REST API，串接工廠儀表板
ATLANTIS的品牌使命「Re-Atlantis」，重現古代理想文明對精密秩序的追求——而秩序的最終目的，是讓知識能被更多人使用，而不是被少數工程師鎖在程式碼裡。當資料能透過一個乾淨的API被查詢，整條雲端監控管線才算真正完成了它的使命：把現場的每一份量測，變成任何人都能安心倚賴的資訊。詳見 ATLANTIS 品牌故事。
一、為什麼要多加一層API Gateway，而不是讓儀表板直接查DynamoDB？
你可能會想：既然第六篇已經教過怎麼用boto3查詢DynamoDB，為什麼儀表板不能直接呼叫DynamoDB的API？原因在於安全性與職責分離：DynamoDB的存取需要AWS憑證（Access Key），若把這組憑證直接放進前端網頁的JavaScript程式碼中，等於把整個資料庫的存取金鑰公開給任何瀏覽器使用者，這是嚴重的資安風險。
任何AWS憑證
都能直接呼叫
速率限制與配額管理
設定支援瀏覽器呼叫
API Gateway扮演的角色
Amazon API Gateway是AWS的無伺服器API管理服務，它站在「外部呼叫者」與「內部Lambda函式」之間，負責處理HTTP請求路由、身分驗證、速率限制與CORS設定，讓Lambda函式只需要專注在「查詢資料並回傳結果」這件事，不需要自己處理這些網路層級的細節。
二、架構總覽：從儀表板到DynamoDB的完整查詢路徑
這條路徑把本系列前面所有篇章串成一個閉環：第一篇的感測器數據，經過第三、四篇的解析，第六篇存入DynamoDB，現在透過②③的API Gateway與Lambda，重新變成前端可以直接使用的資料。這也是整個系列文章從「資料如何上雲」走到「資料如何被使用」的最後一塊拼圖。
三、REST API vs HTTP API：該選哪一種？
API Gateway提供兩種主要的API類型，命名容易讓人混淆，這裡整理清楚的比較讓你快速判斷。
| 比較項目 | REST API | HTTP API |
|---|---|---|
| 功能完整度 | 功能最完整，支援API金鑰、使用計畫、請求驗證等進階功能 | 功能較精簡，聚焦於代理Lambda等核心情境 |
| 延遲與成本 | 相對較高 | 延遲更低、每百萬請求費用通常更低 |
| 身分驗證選項 | 支援IAM、Cognito、Lambda授權方、API金鑰等多種方式 | 支援IAM、Cognito、JWT授權方，選項略少 |
| 適合情境 | 需要完整企業級功能（如按客戶分配API金鑰配額） | 單純的內部工廠儀表板查詢，重視低成本與低延遲 |
對於本篇「工廠內部儀表板查詢溫度數據」的情境，建議優先選用HTTP API——功能已經足夠應付大多數查詢情境，且費用與延遲表現更好；若未來需要對外提供給多個不同客戶或協力廠商，且需要精細的用量配額管理，再考慮升級為REST API。
四、建立API：路由設計與Lambda程式碼
路由設計：一個直觀的資源路徑
建議的API路徑設計如下，讓使用者一看就懂：
路由範例
其中{device_id}是路徑參數（Path Parameter），例如ATL-STT-001；start_time與end_time是查詢字串參數（Query String Parameter），代表要查詢的時間範圍（Unix時間戳記）。這樣的設計直接對應第六篇DynamoDB資料表的主鍵結構，讓Lambda函式的實作邏輯保持單純。
Lambda函式：處理API Gateway事件並查詢DynamoDB
範例一：查詢指定裝置與時間範圍的溫度數據API
import boto3
from decimal import Decimal
from boto3.dynamodb.conditions import Key
dynamodb = boto3.resource("dynamodb", region_name="ap-northeast-1")
table = dynamodb.Table("factory_temperature_history")
class DecimalEncoder(json.JSONEncoder):
# DynamoDB回傳的數字是Decimal型態，需自訂JSON編碼器才能序列化
def default(self, obj):
if isinstance(obj, Decimal):
return float(obj)
return super().default(obj)
def lambda_handler(event, context):
path_params = event.get("pathParameters") or {}
query_params = event.get("queryStringParameters") or {}
device_id = path_params.get("device_id")
start_time = int(query_params.get("start_time", 0))
end_time = int(query_params.get("end_time", 9999999999))
if not device_id:
return build_response(400, {"error": "缺少device_id路徑參數"})
response = table.query(
KeyConditionExpression=(
Key("device_id").eq(device_id) &
Key("timestamp").between(start_time, end_time)
)
)
items = response.get("Items", [])
return build_response(200, {"device_id": device_id, "count": len(items), "records": items})
def build_response(status_code: int, body: dict):
return {
"statusCode": status_code,
"headers": {
"Content-Type": "application/json",
"Access-Control-Allow-Origin": "*"
},
"body": json.dumps(body, cls=DecimalEncoder)
}
這段程式碼有兩個工廠IT技術人員常忽略的細節：一是DynamoDB回傳的數字是Decimal型態，必須自訂JSON編碼器才能正確序列化；二是回應必須包含Access-Control-Allow-Origin標頭，否則瀏覽器會因CORS政策擋下這個請求，這也是下一節要詳細說明的重點。
五、CORS：為什麼瀏覽器呼叫API時常常失敗？
CORS（跨來源資源共用）是瀏覽器內建的安全機制，用來防止網頁在使用者不知情的情況下，向其他網域發送惡意請求。當你的儀表板網頁（例如部署在dashboard.atlantis-internal.com）呼叫API Gateway的端點（不同網域）時，瀏覽器會先發送一個「預檢請求（Preflight Request）」確認伺服器是否允許這個跨網域請求。
| CORS設定項目 | 用途 | 常見錯誤 |
|---|---|---|
| Access-Control-Allow-Origin | 指定允許哪些網域可以呼叫這個API | 忘記設定，導致瀏覽器直接擋下回應 |
| Access-Control-Allow-Methods | 指定允許的HTTP方法（GET、POST等） | 只設定了實際使用方法之外的其他方法 |
| Access-Control-Allow-Headers | 指定允許前端傳送哪些自訂標頭 | 前端傳送了未在此列出的標頭導致被擋下 |
| OPTIONS方法設定 | API Gateway需要為每個資源設定OPTIONS方法回應預檢請求 | 只設定了GET方法，忘記處理瀏覽器自動發出的OPTIONS請求 |
API Gateway的HTTP API類型提供內建的CORS設定選項，只需要在主控台勾選允許的來源、方法與標頭，不需要自己撰寫OPTIONS方法的處理邏輯，這也是我們建議工廠IT技術人員優先選用HTTP API的另一個原因——CORS設定簡化了不少除錯時間。
六、身分驗證：這個API該不該公開給任何人呼叫？
| 驗證方式 | 適用情境 | 實作複雜度 |
|---|---|---|
| 無驗證（公開） | 僅限內網環境使用，或資料本身不敏感 | 最簡單，但安全性最低，不建議用於正式環境 |
| API金鑰（API Key） | 內部系統間呼叫，簡單區分不同呼叫來源 | 簡單，但金鑰外洩風險需留意 |
| IAM驗證 | 僅限AWS帳號內部服務或已設定IAM角色的用戶端呼叫 | 中等，需要簽署AWS請求 |
| Amazon Cognito | 需要讓工廠員工用帳號密碼登入後才能查詢 | 較高，需建立使用者池與登入流程 |
對於「內部工廠儀表板」這種情境，建議至少使用API金鑰做基本區隔，避免API端點完全公開；若儀表板需要依員工角色顯示不同權限的資料（例如只能查看自己負責產線的數據），則建議進一步導入Amazon Cognito做使用者身分驗證與角色管理。
使用計畫（Usage Plan）：避免API被過度呼叫
API Gateway的「使用計畫」功能可以為每個API金鑰設定速率限制（每秒請求數）與配額（每日/每月總請求數），避免因程式錯誤（如儀表板陷入無限迴圈輪詢）或惡意呼叫導致下游Lambda與DynamoDB被過度消耗，造成非預期的高額費用。
七、儀表板端如何呼叫這支API
範例二：前端JavaScript呼叫API並繪製簡易趨勢
async function fetchTemperatureHistory(deviceId, startTime, endTime) {
const url = `https://xxxx.execute-api.ap-northeast-1.amazonaws.com/devices/${deviceId}/temperature?start_time=${startTime}&end_time=${endTime}`;
const response = await fetch(url, {
method: "GET",
headers: { "x-api-key": "YOUR_API_KEY" }
});
if (!response.ok) {
console.error("API呼叫失敗：", response.status);
return null;
}
const data = await response.json();
console.log(`取得 ${data.count} 筆記錄`);
return data.records;
}
取得data.records後，就能直接交給Chart.js、Grafana或任何前端圖表函式庫繪製趨勢線，工廠管理者或PM完全不需要理解背後的AWS架構，只需要知道「這個網址可以查到最新溫度數據」。
八、ATLANTIS 適合作為儀表板數據來源的量測產品
ATFC-305A 攜帶型數位熱電偶溫度計（單通道型）—— 搭配K型熱電偶測溫棒，測量範圍-50℃~1300℃，適合作為現場巡檢數據補充輸入儀表板
DDPG-X082(0.4) 數位式差壓錶 —— 高精度智能型數位錶，內置擴散矽壓力傳感器，適合作為潔淨室壓差儀表板的即時查詢數據來源
MDI-SDDB 全不鏽鋼單膜片雙波紋管差壓錶 —— 全不鏽鋼結構耐腐蝕，適合作為工廠儀表板長期穩定顯示的差壓監測數據來源
PT-E100M系列 鋼鐵、能源行業壓力傳送器 —— 疲勞強度大於1000萬次，防護等級IP67，適合惡劣工業環境長期穩定回報儀表板數據
完整規格請參考 ATLANTIS 產品型錄與工業4.0壓力感測器整合指南。
九、案例分享：某台南封測廠的工程師自助查詢儀表板
以下案例經匿名化處理，客戶為台南一家半導體封測相關工廠，過去每當工程師需要查詢特定機台的溫度歷史數據，都必須請IT人員手動從資料庫撈取，導入本篇架構後的改變如下。
| 階段 | 作法 | 導入前 | 導入後 |
|---|---|---|---|
| API建置 | API Gateway（HTTP API）+ Lambda查詢DynamoDB | 工程師需透過IT人員協助撈取數據，平均等待2小時 | 工程師自行在儀表板輸入機台編號與時間範圍即可查詢 |
| 權限管理 | 為每個部門發放獨立API金鑰並設定使用計畫 | 資料存取權限不易區分 | 各部門查詢額度獨立管理，避免單一部門過度佔用資源 |
| 儀表板整合 | 前端呼叫API並用Chart.js繪製趨勢圖 | 僅有IT人員能產出Excel報表 | 工程師可自助產生互動式趨勢圖表，大幅減少IT人員的報表負擔 |
資深工程師賴祥德分享：「這個案例最有價值的地方，不是技術有多複雜，而是它把『資料查詢』這件事，從『IT部門的特權』變成『任何工程師都能自助完成的日常操作』。這正是雲端監控系統真正的商業價值——不是炫技，而是讓對的人能更快拿到對的資訊。」
資料來源與延伸閱讀
本文技術架構參考 Amazon API Gateway 官方文件（docs.aws.amazon.com/apigateway）中關於REST API與HTTP API的比較說明，以及CORS跨來源資源共用機制的W3C標準規範。費用與功能差異請以AWS官網最新公告為準。ATLANTIS產品技術規格引用自內部產品規格書。
十、內連延伸閱讀
十一、20 大常見問題 FAQ（API Gateway + Lambda REST API）
1. 為什麼不能讓儀表板直接用AWS SDK查詢DynamoDB？
2. HTTP API和REST API可以之後再切換嗎？
3. Lambda代理整合（Proxy Integration）是什麼？
4. 為什麼我的API回應在瀏覽器主控台顯示CORS錯誤？
Access-Control-Allow-Origin，或API Gateway未正確設定OPTIONS方法回應瀏覽器的預檢請求，建議優先確認HTTP API的CORS設定選項是否已正確啟用。5. API金鑰洩漏了怎麼辦？
6. 查詢時間範圍太大（如查詢一整年數據），API會逾時嗎？
7. 我可以在同一個API裡同時提供溫度和壓力兩種查詢路由嗎？
/devices/{device_id}/temperature與/devices/{device_id}/pressure兩個資源路徑，並對應到不同的Lambda函式或同一函式內的分流邏輯，依實際資料表設計決定。8. build_response()裡固定回傳Access-Control-Allow-Origin為星號安全嗎？
9. 使用計畫（Usage Plan）的速率限制設多少比較合適？
10. API Gateway的費用怎麼計算？
11. 我需要用API金鑰還是IAM驗證比較好？
12. Lambda函式回傳的JSON裡如果有巢狀的Decimal型態，DecimalEncoder還能正確處理嗎？
json.dumps()搭配自訂的JSONEncoder子類別，會遞迴處理巢狀結構中所有符合條件的物件，不論Decimal出現在物件的哪一層都能正確轉換。13. 我可以用API Gateway直接整合DynamoDB而不透過Lambda嗎？
14. 前端呼叫API時，如果沒有網路連線會怎樣？
fetch()請求會拋出網路層級的錯誤，建議在前端程式碼加上適當的錯誤處理與重試邏輯，並在儀表板上顯示明確的錯誤提示，而非讓畫面靜默地顯示空白圖表。15. 我該把不同工廠據點的API分開建立，還是共用一個API？
16. API Gateway可以設定快取嗎？
17. 這支API的回應速度大概多快？
18. 我可以讓這支API同時支援分頁查詢嗎？
LastEvaluatedKey機制實現分頁，可在API回應中加入分頁游標欄位，讓前端在資料量龐大時分批載入，避免單次回應過大影響效能。19. API文件要怎麼提供給其他部門的工程師？
20. 學會這篇API Gateway整合後，這系列文章還有其他主題嗎？
十二、下一步：讓 ATLANTIS 協助你規劃從感測器到儀表板的完整資料服務
31年工業儀錶製造經驗 × 完整數位化資料服務規劃
從變送器選型、資料表設計，到API權限規劃與儀表板串接，我們可以陪工廠IT團隊打造真正讓每個工程師都能自助查詢的資料服務。
📞 02-2820-3405 免費選型諮詢 📧 線上快速詢價
業務一部 Ian：ian@atlantis.com.tw ｜ 業務二部 Nori：nori@atlantis.com.tw
文章更新時間：2026年7月｜作者：ATLANTIS 應用工程團隊｜本文為系列教學文章第九篇，下一篇將以完整案例研究總結「感測器→IoT Core→Lambda→DynamoDB→儀表板的完整串接架構」。