用 ASP.NET Core 理解什麼是 API Gateway（從概念到實作）

 在學習後端系統或系統架構時，「API Gateway」幾乎一定會出現。

但對許多人來說，它常常停留在一句話的定義：

「Gateway 是系統的入口」

這句話沒有錯，但不夠具體。
如果沒有實際看過「被擋下來」或「被放行」的過程，其實很難真正理解 Gateway 的價值。

這篇文章會用一個非常簡單、可以實際執行的 ASP.NET Core 範例，一步一步帶你理解：

• Gateway 到底在做什麼

• 為什麼它不是一般的 API

• 以及你要怎麼「親眼看到」它有沒有在工作

---

什麼是 API Gateway？

API Gateway 可以理解為：

系統對外的「唯一入口」與「守門人」

所有來自外部的請求（瀏覽器、前端、其他系統），
都必須先進入 Gateway，由 Gateway 決定：

• 這個請求可不可以進來？

• 有沒有帶正確的憑證？

• 要不要繼續交給後面的 API？

Gateway 常見負責的事情

• 身分驗證（Authentication / Authorization）

• 請求驗證與過濾

• 集中紀錄 Log / Audit
  -（進階）限流、路由、轉發、版本控管

你可以把 Gateway 想成：

大樓的一樓警衛
沒有證件 → 直接擋在門口
有證件 → 才能進入大樓內部

---

為什麼需要 Gateway？

沒有 Gateway 的情況

• 每一支 API 都要自己寫驗證邏輯

• 安全規則重複、分散

• 規則一改，要改很多地方

• 對外暴露太多內部細節

有 Gateway 的情況

• 所有入口規則集中在一個地方

• 後端 API 只專注在商業邏輯

• 架構更清楚，也更容易維護

即使是小型系統，這種「責任分離」的設計也非常重要。

---

本文的學習目標

在這篇教學中，我們希望清楚看到以下幾件事：

1. 所有請求一定會先進 Gateway

2. 沒有通過驗證的請求會被擋下來

3. 通過驗證的請求才能進入 API

4. 每一次請求都能在 Log 中看到紀錄

為了避免一開始就被複雜架構干擾，我們會：

👉 只用一個 ASP.NET Core Web API 專案
👉 用 Middleware 來模擬 Gateway 行為

這樣可以先把「Gateway 的本質」學清楚。

---

專案整體設計說明

這個專案包含兩個層次：

1. Gateway 層（Middleware）

   • 所有請求都會先經過這一層

   • 負責驗證、擋請求、記錄 log

2. 實際 API

   • 只有通過 Gateway 的請求才能進來

   • 不需要自己處理驗證邏輯

流程概念如下：

Client
  ↓
Gateway Middleware
  ↓
Actual API (/order)

---

Gateway 驗證方式說明

我們使用最簡單的方式示範：HTTP Header 驗證

Header Name : X-API-KEY
Header Value: my-secret-key

規則很單純：

• 沒帶或錯誤 → 回傳 401 Unauthorized

• 帶正確的 key → 允許請求繼續往下

教學範例:https://github.com/JeffChen19910528/GatewayExample.git