什麼是 GraphQL？
GraphQL 是一種與 API 通訊的替代方式，非常適合複雜的資料結構和在其基礎上建立介面。與將資料視為獨立的、獨立的片段不同，GraphQL 展示了資料片段如何連接和相互關聯，使得詢問和接收資訊變得容易。
想象 GraphQL 是一種查詢語言，讓您能像直接與資料庫對話一樣與 API 通訊。使用 GraphQL 讓您能最接近資料庫，讓您能挑選選擇想要的資料以及如何取得，提供巨大的效能優勢。
GraphQL 由 Facebook 創建以解決複雜資料結構的擴展問題。由於他們成功採用了它，越來越多的公司開始認識到將 GraphQL 用於其 API 的好處。
已經了解 REST？GraphQL 會感到熟悉。
GraphQL API 比您想像的更容易使用。如果您習慣於使用 REST API，以下是 REST 的核心概念如何轉換為 GraphQL。
| 功能↕ | REST↕ | GraphQL↕ |
|---|---|---|
| 端點 | 請求被發送到多個端點以進行不同的操作 | 所有請求都被發送到單一端點（例如 /graphql） |
| 資料檢索 | 在特定端點上使用 GET 方法來檢索資料 | 使用 查詢 來請求確切所需的資料，減少過度取得或不足取得 |
| 資料修改/操作 | 使用 HTTP 方法（如 POST、PUT、PATCH 或 DELETE）來修改或處理資料。 | 使用 變更 來執行操作（例如建立方，計算著陸成本） |
| 回應格式 | 固定的回應格式返回所有預定義的欄位，無論是否需要 | 靈活的回應允許指定要包括的確切欄位，減少不必要的資料傳輸（如果這種靈活性感覺複雜，只需在我們的文件中使用預先編寫的查詢範例以獲得 RESTful 體驗） |
| 資料連接 | 通常需要多個請求來取得相關資料 | 嵌套查詢能夠在單一請求中檢索相關資料（例如，方詳細資料和出貨項目一起）。使用者也可以建立工作流程以在單一 GraphQL 請求中管理多個變更，減少複雜性並提高效率 |
GraphQL 的優點
更快的回應
GraphQL 透過精確的資料檢索、使用單一端點以及改進的批處理和快取功能提供更快的回應。
精確的資料檢索
REST 的一個常見挑戰是過度取得或不足取得資料——要麼取得太多不必要的資訊，要麼一次性不足所需。GraphQL 透過允許請求確切所需的內容（不多不少）來消除這一問題。這種具體性不僅改善了效能，還簡化了與 API 互動者的流程，使系統更高效且更用戶友好。
此功能有用的範例：
- 這允許前端開發人員取得他們的 UI 元件所需的確切資料，減少到伺服器的往返次數，改善效能。
- 想象您想取得 HS 碼分類、紙箱化、出貨評等以及結帳中項目的著陸成本報價。如果您透過 GraphQL API 進行整合，您可以使用必要的工作流程進行單一呼叫以在單一回應中取得您需要的所有內容（和您不需要的任何內容）。相比之下，使用 REST API，您首先需要呼叫分類 REST API，然後單獨呼叫評等 REST API，最後將該分類和出貨評等插入您對著陸成本 REST API 的第三個呼叫中。所有這些 REST API 都會返回它們能夠返回的每一條資訊，導致您必須解析回應以尋找所需的資料。速度上的這種節省在快速返回完整著陸成本方面造成影響，在購物者離開之前。
單一端點
GraphQL API 通常具有單一端點，不同於 REST API，後者通常為不同的資源和操作有多個端點。這使得管理和理解 API 更加簡單。
批處理和快取
GraphQL 的批處理查詢的能力及其對快取策略的支援導致顯著的效能改善。這些功能減少了網路和伺服器的負載，轉化為對使用者更快、更可靠的互動。
定義明確的架構
GraphQL API 基於強型別架構。此架構定義了可用資料的結構和可執行的操作。這提供了可用資料以及如何存取它的清晰性，這可以提高開發人員的生產力並減少錯誤。例如，前端團隊可以探索圖形以取得確切他們需要的內容，而不是等待新的 REST 端點。
無需破壞現有用戶端即可改進的能力
在 GraphQL 中新增新功能或修改現有功能不會由於其靈活的查詢結構而中斷目前的整合。此功能確保可以進行改進，而不會破壞與現有用戶端的相容性。
最新的文件
感謝 GraphQL 的自省功能，文件會自動生成並隨著每次變更而更新。這確保提供給開發人員的所有資訊都是目前的，減少與過時文件相關的整合問題和支援票證——REST API 文件中常見的挑戰。
檢查我們的 GraphQL 文件 和我們的 REST 文件 以查看差異。
類比
想象您在一家餐廳，其菜單讓您按照自己的喜好訂購菜餚，與另一家只能從套餐中選擇的餐廳相比。GraphQL 就像第一家餐廳：
- 確切得到您想要的內容： 使用 GraphQL，您可以要求確切您需要的資料，不多不少。想象您只想要菜餚的名稱和價格，而不是整個成分列表。使用 REST API，您必須取得所有菜餚詳細資料並忽略您不需要的部分。
- 組成自訂菜餚： 我們的 GraphQL API 可以輕鬆結合以建立更多自訂解決方案，類似於一家自助餐廳風格的餐廳，您可以建立完全按照您需要的方式的獨特菜餚，使用他們已經擁有的成分。相比之下，REST API 就像一家麵包店，有已預製的商品包裝在籃子中——您只能訂購已經建立的內容，您無法選擇只帶回您想要的部分。
- 更少的等待： 由於您可以在單一請求中取得所有所需的資訊，就像請求您的伺服器同時帶上您的前菜、主菜和甜點，而不是在課程之間等待。大多數 REST API 要求您發送多個請求以取得不同的資訊片段。
- 輕鬆變更訂單： 如果您的應用程式的資料需求變更，GraphQL 更容易調整。您只需變更您需要的查詢。使用 REST，您可能需要等待廚房（後端）為菜單建立新的膳食（端點），這需要更多時間。
GraphQL 提供比 REST API 更多的靈活性、效率和簡潔性來提取資料，特別是當您的需求變更或增加時。
Zonos 如何使用 GraphQL
在過去幾年現代化我們的平臺時，Zonos 已選擇使用 GraphQL 而不是 REST 為我們的 API 建立新功能。我們決定這樣做是因為我們的資料很複雜且相互關聯，很像導致 Facebook 建立 GraphQL 的資料。這種複雜性使得建立可擴展的 REST API 變得困難，因為開發人員需要取得和使用資料的方式在實現中差異很大，而 REST 不靈活。
GraphQL 透過允許實現我們 API 的開發人員挑選選擇確切他們想要的資料以及如何取得它來整齊地解決此問題。這允許他們適應他們的工作流程，而無需 Zonos 為每種情況進行自訂工作（而他們在等待）。
使用 GraphQL 和我們平臺現代化的綜合結果使我們的 API 更高效，使 Zonos 的整合更快，並使 Zonos 能夠更快地提供新功能。
更好的功能
Zonos 不斷開發新功能，而 GraphQL 是第一個（通常也是唯一）接收這些更新的。相比之下，我們的 REST API 被認為是生命週期結束，無法存取我們的許多新功能。
GraphQL 獨有功能的範例：
- 包括定價
- Labels API
- 新的結帳和 Hello
- API 回應中的箱子大小
- 儀表板報告
- 如果可能的話，能夠要求 DDP 報價，但如果該國家提供該服務等級時 DDP 不可用則仍然返回 DDU 報價
- 關稅、稅款和費用的詳細明細（項目級資訊、特定費用）——儀表板由 GraphQL 供電，並為所有商店顯示此資料，但 REST API 回應不包括此詳細級別
- 測試模式（敬請期待）
為什麼選擇 GraphQL
了解我們為什麼建議透過 GraphQL 而不是 REST 進行整合。
在 Zonos，我們提供兩種主要類型的 API 供整合使用：GraphQL 和 REST。雖然 REST API 已經存在更久，且對許多人來說可能更熟悉，但我們已轉向 GraphQL 以提供更多靈活性和更快的創新速度。雖然兩者仍然被支援，但本指南說明了為什麼 GraphQL 不僅是我們整合的未來，也是業界整合的未來，且是今天滿足您需求的更強大工具。