# JSON-RPC vs gRPC vs REST 技術比較表

比較三種常見的 API 通訊技術：**JSON-RPC**、**gRPC**、**REST**，涵蓋傳輸格式、效能、擴充性、適用場景等面向。

## 📊 技術特性比較

| 特性 / 技術 | JSON-RPC | gRPC | REST |
|----------------------|------------------------------------------|----------------------------------------------|-------------------------------------------|
| 🔧 傳輸協定 | 通常使用 HTTP/HTTPS（POST） | HTTP/2（可支援 HTTP/1.1 降級） | HTTP/HTTPS（GET/POST/PUT/DELETE） |
| 📦 資料格式 | JSON | Protocol Buffers（Protobuf） | JSON（可選 XML、YAML 等） |
| 🧠 介面定義方式 | 無固定格式，靠慣例（如 `method`, `params`） | 需定義 `.proto` 檔案 | 自由定義 URL + HTTP 動詞 + DTO |
| 🛠️ 工具支援度 | 中等，手動較多 | 高，自動生成 Client/Server stub | 高，原生支援於各大 Web 框架 |
| 📈 效能 | 中等 | 高（快、低延遲） | 中等偏低（人類可讀） |
| 📚 可讀性 | 高（JSON 格式） | 低（binary 格式） | 高（REST URL + JSON） |
| 🔁 雙向通訊 / 推播 | 不原生支援 | 支援 bidirectional streaming | 不原生支援（需 WebSocket 等實作） |
| 🌎 語言支援 | 廣泛（JSON 是標準格式） | 非常廣泛（官方支援多種語言） | 廣泛（HTTP/JSON 為萬國通用） |
| 🔌 第三方整合 | 中等，需設計統一格式 | 較弱（需 client 生成碼） | 最佳（最適合公開 API） |
| 🧩 結構自由度 | 高（可定義自有 method/action 格式） | 中（需配合 proto 規格） | 高（依 URL 與資源設計） |

## ✅ 適用場景建議

| 情境／需求 | 建議技術 | 理由 |
|--------------------------------------|------------------|----------------------------------|
| 自訂 RPC 框架、物件導向參數傳遞 | JSON-RPC | 結構自由、易整合自有系統如 ERP |
| 高效能、微服務內部 RPC 通訊 | gRPC | 高速、內部通訊最佳選擇 |
| 開放給第三方、前端或行動裝置使用 | REST | 簡單通用、無需額外工具 |
| 需要串流（如影像、IoT、大量即時資料） | gRPC | 支援雙向/單向 Streaming |
| 想省開發時間、快速上手 | REST / JSON-RPC | JSON 可讀性高，易除錯 |