API 通常被稱為應用程式從後端服務訪問資料和業務邏輯的前門。 API 本質上是軟體提供給其他人或程式的介面，允許他們與該軟體進行互動。
在建立 API 時，需要選擇一種程式語言（j**a、python、php 等）來編寫 API 邏輯，還需要將 API 部署到伺服器，並監控 API，以確保基礎設施有足夠的容量來處理大量請求。
API Gateway 將這些步驟抽象化，您無需編寫太多內容，也無需擔心管理底層基礎設施，只需建立客戶端可以在其中傳送請求的 API 終端節點。
主要的雲提供商提供完全託管的 API 閘道器服務：
AWS API 閘道器。
GCP API 閘道器。
Azure API 管理。
本文將解釋為什麼要使用 API 閘道器，它們是如何工作的，我們將研究實際應用程式中的 API 閘道器示例。
我們將涵蓋的內容：：
1.為什麼要使用 API 閘道器？
2.API Gateway 的工作原理。
2.1 請求驗證。
2.2 授權認證。
2.3 速率限制。
2.4 請求路由。
2.5 請求和響應翻譯。
3.真實世界的例子。
API Gateway 是一項完全託管的服務，使開發人員能夠更輕鬆地建立、發布、維護、監控和保護幾乎任何規模的 API。
在雲計算環境中，“完全託管”意味著服務的維護和管理責任在於雲提供商，這意味著底層基礎設施、軟體更新、安全性、可擴充套件性、可用性和災難恢復都由雲提供商管理。
這種抽象主要使開發人員的工作更容易，因為他們只需要專注於開發服務，而不必擔心管理它。
在這種情況下，這種抽象是以失去靈活性為代價的，大多數雲提供商提供的 API 閘道器對每秒處理的請求數 （RPS） 有硬性限制。
使用 API Gateway 等託管服務的成本也較高，必須與從頭開始構建 API 所需的更多開發人員天數（開發人員數量 * 工作日）進行權衡。
為了真正了解使用 API Gateway 的好處，讓我們看一下設計、編寫和部署傳統 API 時需要遵循的步驟：
步驟 1：定義要求和範圍
了解目標使用者或系統的需求。
確定 API 將公開的資料和功能。
步驟 2：設計 API
定義 API 端點和方法（get、post、put、delete）。
設計請求和響應格式（通常為 JSON 或 XML）。
指定 API 將與之互動的資料模型和資源。
計畫錯誤處理和狀態**。
步驟 3：開發 API
選擇程式語言和框架。
實現在設計階段定義的 API 端點。
根據需要與資料庫或其他服務整合。
確保實施安全實踐，例如輸入驗證和速率限制。
步驟 4：部署 API
選擇託管解決方案（雲提供商、現場伺服器）。
設定部署環境。
將 API 部署到伺服器。
步驟 5：監視和維護 API
監控 API 的正常執行時間、效能和錯誤。
定期更新 API 以修復錯誤並修補安全漏洞。
使用 API 閘道器時，您主要需要關注步驟 1、2 和 3，其他步驟大多由 API 閘道器抽象和處理。
使用 API 閘道器的主要原因是簡化開發和維護 API 的過程。
API 閘道器可以同時做很多事情。
為了理解 API 閘道器的工作原理，讓我們打個比方。
API閘道器就像馬 tre d'（法語，意思是maîch服務員），馬 tre d'通常出現在高階餐廳，儘管它是乙個正在慢慢消失的職業。
女總管是客人和餐廳工作人員之間的聯絡人，負責：
問候語和座位分配： maître d'être d'n' 通常是客人到達餐廳時遇到的第乙個人。 他們熱情地歡迎客人，詢問預訂情況，並根據客人的喜好和特殊要求協助客人安排座位。
保留：領班負責管理預訂並確保有效分配餐桌。 他們跟蹤可用的桌子和預訂時間，進行必要的調整以滿足客人的需求。
管理等待時間： 在繁忙時期，領班通過提供預計的等待時間並提供替代方案來管理客人的等待時間，例如讓客人在酒吧或等候區就座。
問題解決如果在用餐過程中出現任何問題或疑慮，領班應及時干預並解決問題，以確保客人滿意。
處理特殊要求如果客人有特殊要求或飲食限制，女主人會將這些資訊傳達給廚房，並確保滿足客人的需求。
簡而言之，maître d'être d'être de la maître d'être de l'ð （d'être） 是餐廳中具有多重才能和責任的人，從以下**中，我們可以看到 maître d'être d'être ù 是如何與
API 閘道器的工作方式與此類似，充當客戶端與其可能需要訪問的許多服務之間的通訊器。
讓我們更詳細地了解一下 API 閘道器可以做什麼。
這包括在到達後端服務之前檢查傳入請求以確認它們是否滿足預定義的條件。
這可能包括檢查請求的結構、驗證資料型別、確保存在所需的引數，以及根據架構驗證查詢引數、標頭和請求正文。
這樣一來，API 閘道器就充當了第一道防線，防止非標準或惡意請求到達後端系統。
用餐廳的比喻來說，這類似於在餐廳門口等候迎接客人的領班，但請記住，這是一家高檔餐廳，所以領班會確保客人穿著符合餐廳的著裝要求——類似於根據預定義的模式驗證傳入的 API 請求。
身份驗證是驗證發出請求的使用者或服務的身份的過程，通常通過使用者名稱和密碼、令牌或 API 金鑰等憑據進行驗證。
通過身份驗證後，授權將確定經過身份驗證的實體有權訪問或執行哪些資源或操作。
API 閘道器通常與身份提供商整合，並支援各種身份驗證和授權機制，例如 OAuth、JWT、API 金鑰等。 它們確保只有合法的授權請求才能通過後端服務。
身份驗證側重於“誰”，而授權側重於“許可權”。
對於迎接客人進入餐廳的領班來說，身份驗證涉及客人證明他們是他們所說的人，通常是通過出示某種形式的身份證明，上面有與他們的臉相匹配的**。
授權將涉及檢查他們是否有預訂，這意味著他們有權進入餐廳點餐。
速率限制涉及控制使用者或服務在指定時間範圍內可以發出的請求數，通常定義為對每秒請求數 （rps） 的限制。
速率限制有助於避免後端服務過載，並確保它們仍然可用。 速率限制也用作成本控制策略的一部分，因為您需要為傳送到 API 閘道器的每個請求付費。
API Gateway 可以根據訪問的使用者、服務或終端節點實施不同的速率限制策略。
以我們的餐廳類比為例，想象一下，我們的餐廳裡有客人，他們都經過驗證、認證和授權進入餐廳。 但這些客人特別餓口渴，不斷點食物和飲料。 在某些時候，這對餐館來說變得無法控制。 廚師和服務員過度勞累，無法接受任何新訂單，盤子和餐具都用完了，廚房裡的食物也用完了。
廚師可以介入並限制顧客可以點餐的數量，例如，通過限制每小時可以點的主菜或葡萄酒的數量，限制限制可以確保餐廳不會超負荷，仍然可以為新顧客提供服務。
API 閘道器根據各種條件（如 URL 路徑、HTTP 方法、標頭或查詢引數）管理傳入請求到相應後端服務的路由。 它是微服務架構不可或缺的一部分，其中不同的服務處理 API 的不同部分。
回到我們之前的餐廳比喻，根據客人的目的，領班不會將他們引導到正確的人或地方——食客引導服務員，只想喝酒的客人引導到酒吧，要求預訂餐廳活動的人引導活動協調員。
這涉及在請求和響應通過 API 閘道器時對其進行修改。
對於請求，這可能意味著新增、刪除或修改標頭、重寫 URL，甚至更改請求正文。 對於響應，這可能涉及更改狀態**、修改頭部或轉換。
此功能允許 API 閘道器充當中介，可以轉換請求和響應，以滿足客戶端和後端服務的需求。
後端服務也可以執行這種請求和響應轉換。 關於哪個元件（API 閘道器或後端服務）進行轉換的決定是主觀的。 但是，API 閘道器通常是以最小的工作量集中此轉換的理想位置，而不是在每個後端服務中進行自定義轉換。
例如，如果餐廳客人不耐麩質，則必須更改他們的訂單以確保餐點不含任何麩質。
這種訂單切換的邏輯可以通過工頭在將訂單傳送給廚師之前明確指出哪些成分應該從選單中排除來實現，或者在廚房裡，工頭只需告訴廚師客人點了無麩質菜餚並要求他相應地修改訂單。
微服務架構是一種開發軟體的方法，它將大型應用程式分解為更小的獨立元件，稱為微服務。 每個微服務都是乙個獨立的單元，在更廣泛的應用程式中具有特定的功能或職責。
下圖顯示了基本電子商務應用程式的簡單微服務體系結構。
客戶：這些是與電子商務平台互動的不同客戶端。 它們可以是移動應用程式、Web 瀏覽器或任何其他第三方應用程式。
API 閘道器：作為所有型別客戶端的單一入口點，根據請求的性質（使用者相關、產品相關、訂單相關）將請求路由到相應的微服務。
服務業：這些是特定於電子商務的微服務示例。 每個服務都處理業務邏輯的不同方面，例如使用者配置檔案、產品目錄和訂單處理。
資料庫：每個微服務都有自己的專屬資料庫，保證資料隔離和服務獨立性。
在此示例中，API 閘道器為：
確保每個客戶的請求都得到滿足驗證
確保客戶在做訂購或撰寫產品評論等事情之前得到它身份驗證和授權
速率限制請求，以確保服務不會因傳送大量請求的惡意行為而關閉。
根據不同的條件，例如 URL 路徑、HTTP 方法、標頭或查詢引數，它將客戶端請求路由到相應的後端服務。
加工請求和響應轉換。例如，來自產品服務的響應可能具有複雜的格式和廣泛的細節。 API 閘道器將此響應轉換為更適合移動應用程式的格式。 這可能涉及簡化資料、將其轉換為更輕的格式或僅提取移動應用程式所需的基本資訊。
API Gateway 是一項完全託管的服務，使開發人員能夠更輕鬆地建立、發布、維護、監控和保護幾乎任何規模的 API，並且由於它是完全託管的，因此它抽象化了管理和維護底層基礎設施所需的工作，這些基礎設施由提供服務的雲提供商處理。
API 閘道器充當客戶端和許多需要訪問的服務之間的中間人，它處理請求驗證、身份驗證和授權、速率限制、請求路由和請求響應轉換。
它在微服務體系結構中特別有用，是管理、處理傳入請求並將其路由到相應微服務的中央入口點，在簡化客戶端互動和為一組微服務提供中央介面方面發揮著至關重要的作用。