API 與非同步：系統之間怎麼說話

你的手機 App 怎麼跟伺服器要資料？程式跟程式之間怎麼互相使喚？靠 API（Application Programming Interface，應用程式介面）。

• 類比：餐廳的服務生＋菜單。你（客戶端）不用進廚房（伺服器內部），也不用知道菜怎麼煮（內部實作）——看菜單（API 文件）知道有什麼能點，跟服務生（API）下單，餐點會送上來（回應）。
• 好處是隔離：廚房怎麼改裝、換廚師（重構、換技術），只要菜單不變，客人完全無感。
• Endpoint（端點）：每道菜的「點餐窗口」，實際上是一個網址。例如 https://api.example.com/users/123 ＝「使用者 123 號」這項資源的窗口。
• JSON：現代 API 傳遞資料最通用的格式——人看得懂、機器好解析的巢狀鍵值對：
  { "name": "Andy", "age": 30, "tags": ["aws", "dev"] }。

REST 是一套 API 的設計慣例（不是新技術），核心就兩條：「網址表達資源、HTTP 動詞表達動作」——基礎篇 ch02 學的 HTTP 動詞直接用上：

• GET /users ＝ 給我使用者列表（讀取）
• GET /users/123 ＝ 給我 123 號使用者（讀取單筆）
• POST /users ＝ 新增一個使用者
• PUT /users/123 ＝ 更新 123 號使用者
• DELETE /users/123 ＝ 刪除 123 號使用者

回應用 HTTP 狀態碼表達結果（ch02 的知識再用一次）：200 成功、404 找不到這筆、429 你叫太兇被限流、500 廚房炸了。

• 因為全世界都遵守同一套規矩，任何語言寫的程式都能互相溝通——這就是 REST 風行的原因。

系統之間的溝通分兩種模式，這是理解 AWS ch09 整章的鑰匙：

• 同步（Synchronous）＝ 打電話：發出請求後原地等待回應，拿到答案才繼續。優點：馬上知道結果。缺點：對方慢，你就跟著慢；對方掛了，你就跟著失敗——命運綁在一起。
• 非同步（Asynchronous）＝ 留言/傳訊息：把訊息留下就繼續做自己的事，對方有空再處理。優點：彼此解耦、各忙各的。缺點：不會馬上有結果，要另外設計「怎麼知道做完了」。
• 什麼場景該用非同步？後續動作「不需要馬上完成」的：下單後的發票開立、Email 通知、影片上傳後的轉檔——使用者按下按鈕只需要知道「收到了」，不需要站在原地等全部做完。

非同步的「留言板」具體長什麼樣？就是佇列（Queue）——一條先進先出的訊息隊伍：

• 生產者（Producer）把訊息丟進佇列就走人；消費者（Consumer）依自己的步調從佇列取出處理，做完把訊息刪掉。
• 類比：銀行取號機。客人抽號碼牌（訊息進佇列）就可以去旁邊坐（生產者不用等），櫃檯（消費者）照自己的速度一號一號叫。
• 佇列帶來三大好處，AWS 考題翻來覆去就考這三個：
  ・解耦（Decoupling）：前後端只認識佇列、不直接認識彼此——後端全掛了，訊息還安穩地排在佇列裡，修好再處理，一筆都不丟。
  ・削峰填谷（緩衝）：搶購瞬間湧入十萬筆訂單？全部先進佇列排著，後端照常速消化——尖峰流量被「拉平」了。
  ・獨立擴展：佇列越積越長＝後端不夠力，多開幾個消費者就好，前端完全不用動。

非同步訊息還有第二種模式，兩者的差別是 AWS ch09 的核心考點：

• 佇列（Queue）＝ 工單池：每則訊息只會被一個消費者領走處理（處理完就從佇列刪除）。多個消費者是在分工（你處理 1 號單、我處理 2 號單）。適合：任務分派——「這件事，找一個人做掉」。
• 發布/訂閱（Pub/Sub）＝ 廣播電台：發布者對一個主題（Topic）喊話，所有訂閱者都收到同一則訊息、各自做各自的事。適合：事件通知——「這件事發生了，所有關心的人都該知道」。
• 例子：「訂單成立」這個事件，發到 Topic 之後——Email 服務發通知、庫存服務扣庫存、分析服務記一筆——三個系統同時收到、互不干擾。
• Fan-out（扇出）經典架構：Pub/Sub 的每個訂閱者各接一條佇列（Topic → 多條 Queue），兼得「廣播給所有人」與「每條線各自排隊、不丟訊息」。