REST API 如何運作——一次請求的來回 · 心智圖
REST API 如何運作——一次請求的來回. 可編輯嘅心智圖，以彩色分支、子題目同曲線連結呈現概念。 曲線表示關聯；只有方向重要時先用箭嘴。
REST API 是一場以 HTTP 進行的對話：用戶端送出一個指名資源與動作的請求，伺服器處理它，而回應則承載狀態碼與結果。
REST API 如何運作——一次請求的來回 · 心智圖
The interactive MindMap canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
點樣閱讀呢張心智圖
- 由中央主題開始，沿住彩色分支探索相關概念。
- 曲線表示關聯；只有方向重要時先用箭嘴。
Request
呢個分支匯集 “The method is the verb — GET reads, POST creates, PUT replaces, PATCH updates, DELETE removes. REST names resources by URL and acts on them with these verbs.”, “Client sends the request over HTTPS”.
Routing
呢個分支匯集 “The URL path is the routing key: /users/42 is the handler for one user. Query parameters, headers and the body carry everything else the handler needs.”, “Validation covers authentication (are you who you say you are?), authorization (are you allowed?), and the payload itself (is the data well formed?).”.
Business logic
呢個分支匯集 “Handler runs the business logic”, “Server reads or writes the resource in the database”.
Response
呢個分支匯集 “The status code is the contract: 200 OK, 201 Created, 204 No Content, 404 Not Found, 500 Server Error. Clients branch on it before they read the body.”, “Client receives the response and parses it”, “Client renders the result to the user”.
Errors
呢個分支匯集 “Server returns 400 / 401 / 403”.
跨分支關聯
REST 是一份以 HTTP 寫成的契約：方法是動詞，URL 是資源，而狀態碼是機器可讀的結果。
用戶端是無狀態的——每一個請求都帶齊伺服器所需的一切，因此不需要共用的工作階段。
驗證就是保安邊界；無效的請求會在任何業務邏輯執行之前被拒絕。
一個回應先由它的狀態碼定義，其次才是它的主體。
REST 的流量跑在其他技術圖解所描繪的同一套 DNS、HTTPS 與互聯網基礎設施之上。
Key relationships and takeaways
- REST 是一份以 HTTP 寫成的契約：方法是動詞，URL 是資源，而狀態碼是機器可讀的結果。
- 用戶端是無狀態的——每一個請求都帶齊伺服器所需的一切，因此不需要共用的工作階段。
- 驗證就是保安邊界；無效的請求會在任何業務邏輯執行之前被拒絕。
- 一個回應先由它的狀態碼定義，其次才是它的主體。
- REST 的流量跑在其他技術圖解所描繪的同一套 DNS、HTTPS 與互聯網基礎設施之上。
When to use this visual
- 在工程師設計第一個端點之前，向他們講解 HTTP 方法、URL 與狀態碼這個模型。
- 按 REST 的慣例覆核一個 API 的契約——錯誤是用狀態碼表示，還是用 200 加一個旗標？
- 把關於冪等性與快取的討論，落到請求實際是如何組成與驗證之上。
運作方式
調整中央主題
按項目或課堂修改中央主題名稱。
擴展分支
編輯概念並加入例子或註解。
連結相關概念
畫出跨分支連結；只有方向重要時先用箭嘴。
常見問題
甚麼是 REST API？
REST API 是一組把系統的資源公開出來的 HTTP 端點。用戶端以 HTTP 方法對資源動作——GET 讀取、POST 建立、PUT 或 PATCH 更新、DELETE 移除——而伺服器以一個狀態碼和一份表示回應，通常是 JSON。REST 是一種風格而不是一項標準，它的價值在於任何懂得 HTTP 的用戶端都可以使用它。
GET、POST、PUT 與 DELETE 有甚麼分別？
它們是 REST 契約的動詞。GET 讀取一個資源，而且不應有副作用。POST 建立一個新資源並傳回它的識別。PUT 整份取代一個資源，而且是冪等的——重複執行不會再有任何改變。PATCH 做部分更新。DELETE 移除一個資源。動詞加上 URL 一起指明完整的動作，這就是為甚麼圖解中的請求方框首先點出方法。
狀態碼在 REST 裡為甚麼重要？
因為它們是請求的機器可讀結果。用戶端可以按狀態碼分支而不必解析主體：2xx 是成功、4xx 是用戶端的錯、5xx 是伺服器的錯。那些傳回 200 卻在主體裡放一個錯誤旗標的 API 破壞了這份契約，逼使每一個用戶端都要為那個回應寫特例。
怎樣才算是一個「RESTful」的 API？
實用的檢查清單：以 URL 為資源命名、以 HTTP 方法表達動作、無狀態的請求（每一個都帶齊伺服器所需的一切）、正確使用狀態碼的回應，以及常見的超媒體或版本化 URL。畫布模擬的正是那趟來回——請求、驗證、處理、回應——這就是每一次 RESTful 交換所共有的形狀。
喺 QueryChart 編輯呢張心智圖
喺可編輯畫布開啟心智圖。移動概念、加入分支同畫連結。