API 請求生命週期——一個請求所走的每一跳 · 心智圖
API 請求生命週期——一個請求所走的每一跳. 可編輯嘅心智圖，以彩色分支、子題目同曲線連結呈現概念。 曲線表示關聯；只有方向重要時先用箭嘴。
一個 API 請求並不是一跳——它是一條鏈：DNS 解析、連線建立、加密、路由、處理與回應，而每一個階段都由不同的一層擁有。
API 請求生命週期——一個請求所走的每一跳 · 心智圖
The interactive MindMap canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
點樣閱讀呢張心智圖
- 由中央主題開始，沿住彩色分支探索相關概念。
- 曲線表示關聯；只有方向重要時先用箭嘴。
Find the service
呢個分支匯集 “The first round trip is DNS — the domain is resolved to an IP address before a single request is sent. See How DNS Works for the full lookup chain.”, “A TCP connection is established”, “The encryption handshake negotiates keys before the HTTP request travels — see How HTTPS Works for what happens inside it.”.
Send request
呢個分支匯集 “The HTTP request is sent”, “With several servers behind one address, the load balancer picks a healthy instance for each request and spreads traffic across them.”.
Application
呢個分支匯集 “Handler validates and processes the request”, “Server queries the database”.
Return response
呢個分支匯集 “Server serialises the response”, “Response travels back through the same path”, “Client parses and renders the response”.
跨分支關聯
DNS、TCP 與 TLS 都排在 HTTP 請求之前——在任何應用程式的程式碼執行之前，已經有三趟來回。
負載平衡器令多部伺服器看起來像同一個位址；用戶端永遠不會見到真正的那一部伺服器。
在大多數 API 呼叫裡，資料庫查詢是最慢的一跳，這就是為甚麼快取與索引重要。
回應會沿著請求的路徑折返——兩個方向跨越的是同一個網絡與同一個負載平衡器。
這個生命週期把其他圖解組合起來：DNS、HTTPS 與 REST 都是這一趟旅程裡的階段。
Key relationships and takeaways
- DNS、TCP 與 TLS 都排在 HTTP 請求之前——在任何應用程式的程式碼執行之前，已經有三趟來回。
- 負載平衡器令多部伺服器看起來像同一個位址；用戶端永遠不會見到真正的那一部伺服器。
- 在大多數 API 呼叫裡，資料庫查詢是最慢的一跳，這就是為甚麼快取與索引重要。
- 回應會沿著請求的路徑折返——兩個方向跨越的是同一個網絡與同一個負載平衡器。
- 這個生命週期把其他圖解組合起來：DNS、HTTPS 與 REST 都是這一趟旅程裡的階段。
When to use this visual
- 向新的工程師講解，為甚麼 API 延遲不只是伺服器程式碼——網絡與建立連線那幾個階段是實實在在的。
- 診斷緩慢：畫布點名了要量度的那幾跳——DNS 時間、TTFB、伺服器時間、傳輸時間。
- 把關於負載平衡與快取的討論，落到它們各自在這趟旅程中的位置之上。
運作方式
調整中央主題
按項目或課堂修改中央主題名稱。
擴展分支
編輯概念並加入例子或註解。
連結相關概念
畫出跨分支連結；只有方向重要時先用箭嘴。
常見問題
一個 API 請求有哪些階段？
在任何 HTTP 送出之前，用戶端會先透過 DNS 解析域名、開啟一條 TCP 連線，並完成一次 TLS 握手。然後請求前往負載平衡器，由它路由到一部應用伺服器；伺服器驗證並處理它、查詢資料庫，再把一個回應序列化；而回應會沿同一條路徑返回。圖解的三條直欄，正正就是這三組階段。
為甚麼伺服器還未做任何事，一次 API 呼叫就已經很慢？
因為 DNS 解析、TCP 連線與 TLS 握手全都是真實的來回，而且都發生在第一個 HTTP 位元組送出之前。在一條冷連線上，它們花的時間可以比實際的請求處理還要長。這就是為甚麼圖解要由「請求之前」這一欄開始——第一個請求的延遲大部分是建立連線，而不是伺服器程式碼。
負載平衡器在請求生命週期裡扮演甚麼角色？
負載平衡器是那道穩定的前門，真正的伺服器住在它背後。它接下請求、挑選一個健康的執行個體，再把流量轉發過去；健康檢查與 TLS 亦經常在這裡終結。用戶端永遠不會知道是哪一部伺服器處理了自己，正是這一點，令伺服器可以在不改動用戶端的情況下增減。
為甚麼回應要沿同一條路徑折返？
因為連線就是路徑：回應是經由承載過請求的同一條 TCP/TLS 連線，穿過同一個網絡與同一個負載平衡器傳回的。這種對稱在營運上很重要——一跳變慢或壞掉，兩個方向都會受影響，這就是為甚麼圖解把回應那一欄畫成請求那一欄的倒影，而不是假設回程是免費的。
喺 QueryChart 編輯呢張心智圖
喺可編輯畫布開啟心智圖。移動概念、加入分支同畫連結。