Enter your search text in the box above

Select a result to preview

API 範式比較 (API Paradigms)

#networking #application-layer #api-design #system-design

三種範式速覽

範式 傳輸格式 底層協定 面試預設
REST JSON HTTP/1.1+ ✅ 預設選擇
GraphQL JSON HTTP/1.1+ 有特定需求時
gRPC Protocol Buffers（二進位） HTTP/2 內部微服務

REST：簡單且靈活

以**資源（resource）**為核心，用 HTTP 方法表達操作。

GET    /users/{id}       → 取得用戶
PUT    /users/{id}       → 更新用戶
POST   /users            → 建立用戶
GET    /users/{id}/posts → 取得用戶的貼文
常見反模式

❌ /updateUser、/startGame（操作命名，非 RESTful）
✅ PUT /users/{id}、PATCH /games + {"status": "started"}

REST 用資源 + HTTP 動詞，不是在 URL 裡放動詞。

何時用：外部 API、幾乎所有情境的預設選擇。

GraphQL：彈性的資料獲取

解決的問題：前後端分屬不同團隊時的 over-fetching 和 under-fetching。

Over-fetching：API 回傳遠多於當前需要的資料
Under-fetching：一個頁面需要多個 API 請求才能拿到所有資料

GraphQL 讓客戶端精確指定需要的欄位和結構：

query {
  users(limit: 10) {
    id
    username
    profile { fullName avatar }
    groups { id name }
  }
}

何時用：

面試建議

在固定需求的面試中，GraphQL 的優勢較不明顯（需求不像真實產品會一直移動）。
只在問題明顯聚焦於靈活性時才提出 GraphQL。

gRPC：高效能微服務通訊

使用 Protocol Buffers 定義嚴格綱要，生成二進位序列化：

message User { string id = 1; string name = 2; }
service UserService {
  rpc GetUser (GetUserRequest) returns (GetUserResponse);
}
對比 JSON Protocol Buffers
格式 文字（含綱要） 二進位（標籤+可變長度）
範例大小 {"id":"123","name":"Terry"} = 40 bytes 同等內容 ≈ 15 bytes
解析速度 較慢 快（某些基準吞吐量高 10 倍）

何時用：內部微服務間高效通訊、需要強型別 API 定義。

面試陷阱

不要過早跳到 gRPC。面試官想看你如何思考問題，在解決其他實質瓶頸前就優化協定選擇不是好做法。
策略：內部 API 用 gRPC，外部 API 用 REST。

選型決策流程

預設 REST
    │
    ▼
前端需要靈活查詢且資料結構複雜？
    │
   Yes ──► GraphQL
    │
   No
    │
    ▼
是內部微服務間通訊且效能瓶頸明確？
    │
   Yes ──► gRPC
    │
   No  ──► 繼續用 REST