在 API 架構設計中，有多種方式可以選擇。

為了要能因應每個專案的需求都不同，以及隨著技術環境和商業需求的變化，

API的設計不僅是要符合現有需求的方案，更要能支持未來的擴展、性能、維護性和成本效益。

但是每一種架構都有其特點
在考量API架構時，可以先思考一下，這個需求所要考慮的特點是什麼

最好地支持即時性?
在多樣化的客戶端需求下,可以更靈活地返回所需數據?
如果系統需要支持跨語言和分散式架構的高效通信?
安全性和數據一致性需求較高的行業是否應該選擇不同的架構?

 

以下是每種架構的簡單介紹：在 API 架構設計中,有多種方式可以選擇。每一種架構都有其特點、優點和缺點,適合不同的應用場景。以下是每種架構的簡單介紹：

 

1. REST (Representational State Transfer)

REST 是基於 HTTP 的架構風格,透過標準的 HTTP 方法（如 GET、POST、PUT、DELETE）來操作資源。

  • 優點：

    • 簡單易懂：基於 HTTP 標準,開發者易於理解和使用。

    • 無狀態性：每個請求是獨立的,伺服器不需要追蹤用戶的狀態,方便水平擴展。

    • 廣泛支持：多數編程語言和框架都支持 REST,易於整合。

  • 缺點：

    • 數據量控制困難：返回數據可能過多或過少,會影響效能。數據量控制困難：返回數據可能過多或過少,會影響效能。

    • 靈活性較低：端點設置固定,數據需求變更時需要新增或調整端點。

    • 適合靜態資源場景：不太適合高互動性或即時性需求高的應用。

       

2. GraphQL

GraphQL 是 Facebook 開發的查詢語言，允許客戶端指定所需數據並透過單一端點請求。

  • 優點：

    • 靈活數據請求：客戶端可指定所需數據，避免數據不足或過多的問題。

    • 單一端點：降低多端點管理的複雜性。

    • 適合複雜數據需求：能夠處理多層嵌套或關聯數據的查詢需求。

  • 缺點：

    • 查詢處理複雜：後端需處理複雜的查詢解析。

    • 無內建快取：不像 REST 支持 HTTP 快取，GraphQL 需要自定義快取機制。

    • 學習成本：需要學習 GraphQL 的查詢語法和特性。

       

3. gRPC (Google Remote Procedure Call)

gRPC 是 Google 開發的高效能 RPC 框架,基於 HTTP/2 並使用 Protocol Buffers 進行編碼。

  • 優點：

    • 高效能：HTTP/2 和二進制編碼使傳輸效率更高。

    • 多模式支援：支援雙向流和多路復用,適合高效能應用。

    • 跨語言支持：gRPC 支援多種語言，適合多語言的開發環境。

  • 缺點：

    • 依賴 HTTP/2：不適用於舊版 HTTP/1.1 瀏覽器環境。

    • 開發和調試複雜：需要設計 Protocol Buffers 並管理多語言支持。

    • 比較適合微服務內部通訊。

       

4. WebSocket

WebSocket 是一種雙向通訊協議，允許伺服器和客戶端之間保持持續連接，適合於實時性要求高的應用。

  • 優點：

    • 雙向通訊：伺服器可主動推送數據給客戶端,適合即時性需求。

    • 低延遲：持續連接，減少頻繁握手的延遲。

    • 節省頻寬：避免輪詢方式，減少無效請求，節省資源。

  • 缺點：

    • 伺服器資源消耗：需要維持長連接，伺服器資源佔用較大。

    • 無法使用 HTTP 快取：WebSocket 無法利用 HTTP 快取和代理。

    • 特定場景適用：適合即時互動應用，例如即時聊天和遊戲。

       

5. SOAP (Simple Object Access Protocol)5. SOAP（簡單物件存取協定）

SOAP 是一種基於 XML 的協議，提供高安全性和高可靠性的通訊方法。

  • 優點：

    • 標準化：具有嚴格標準（如 WSDL、WS-Security），確保跨平台一致性。

    • 高安全性：支援 WS-Security 等安全機制,適合安全性要求高的應用。

    • 內建錯誤處理：SOAP 提供標準化的錯誤處理和回應。

  • 缺點：

    • 結構複雜：XML 格式繁瑣，傳輸效率低。

    • 靈活性不足：SOAP 的結構固定，擴展性不如 REST 或 GraphQL。

    • 重度依賴 XML：傳輸數據量大，效率不高。

  • 適合場景：需要高安全性和跨平台支持的應用,如金融、電子支付和銀行系統。

     

6. Webhook

Webhook 是一種服務端主動推送數據的方式,通常在事件發生時將資料傳送到指定的 URL。

  • 優點：

    • 即時推送：事件發生後立即推送,不需要輪詢。

    • 節省資源：減少輪詢請求,節省流量和計算資源。

    • 簡單易於實現：只需設定回調 URL。

  • 缺點：

    • 無法保證消息成功送達：若回調 URL 無效或伺服器故障,無法保證重發。

    • 安全風險：需要認證和驗證以防 URL 被不當使用。

    • 調試難度：跨服務調試和錯誤處理需要額外設計。

  • 適合場景：需要即時通知的場景，如支付通知、訂閱事件更新和持續集成。

 

每種架構都有其適用場景，畢竟在架構設計裡，選對了 API 架構就像是點對了菜品，既能吃得開心，也能安心滿足後續的需求。

 

懶人包選擇建議

  • REST：適合簡單、易用、廣泛支持的情況。

  • GraphQL：適合數據需求不確定、查詢複雜的應用。

  • gRPC：適合高效能和跨語言支持的內部通訊。

  • WebSocket：適合實時性和雙向通訊應用。

  • SOAP：適合高安全性和跨平台的場景。

  • Webhook：適合即時推送、輕量型事件通知。

On this day..

«