GraphQL Vs. REST？ API 開發方法的誠實比較 | transposit

對 GraphQL 和 REST API 開發方法及其用例之間差異的動手探索:

無論您是在開發內部工具、內容管理系統 (CMS) 整合還是電子商務外掛，您都會經常發現自己在做出選擇。您應該使用標準的 REST API 還是 GraphQL API？

Facebook 於 2012 年制定了 GraphQL 規範。自 2015 年公開發布以來，GraphQL 已被構建 API 的公司廣泛採用。儘管 GraphQL 基於幷包含 REST 熟悉的許多功能，但兩個系統處理資料的方式存在根本差異。

你需要決定嗎？在為客戶端開發 API 時，您可能想知道是否應該並行開發兩種端點。本文探討了這兩種 API 開發方法，為您提供有關如何處理下一個專案的明智決定所需的所有知識。

好訊息是這兩種方法都使用相同的技術。

作為開發人員，您通過 HTTP 傳送請求並期待響應。您使端點可用並在 API 級別為您的使用者保護它們。您構建伺服器，您的客戶使用他們的程式碼查詢它們。因此，您需要編寫高效的程式碼來儘快滿足客戶的資料需求。

這些 API 方法之間的區別在於它們向伺服器傳送什麼資料以及到達時會發生什麼。

獲取資料區別

兩個 API 之間的第一個關鍵區別是 GraphQL API 通常有一個端點，單個 HTTP 動詞查詢。但是，RESTful API 有許多端點，多個動詞可以查詢這些端點。

讓我們想象一下使用 RESTful 方法為 CMS 構建 API。這個基本的 CMS 有“使用者”寫的“帖子”，可能還有其他“使用者”建立的“評論”。編寫此 API 時，您需要建立多個端點：

• GET /api/posts - 此端點允許客戶端訪問所有帖子。
• POST /api/posts/:id - 此端點允許客戶端建立帖子。
• PATCH /api/posts/:id - 此端點允許客戶端更新帖子。
• DELETE /api/posts/:id- 此端點允許客戶端刪除帖子。

您還需要為其他每個資源、“使用者”和“評論”建立此結構。

此 API 的典型用例是客戶端嘗試檢索包含作者詳細資訊以及任何相關評論的帖子。您有兩種可能的選擇來支援此使用者。您可以建立自定義端點/api/post-with-details或記錄客戶端需要發出的三個請求。

讓我們想象一下使用 GraphQL 方法完成相同的練習。資料模型和後端儲存仍然相同，但您將只公開一個端點，例如https://api.ourproduct.com/graphql. 您的客戶端將向此端點發布 GraphQL 查詢。然後，您將解析並響應查詢。請求可能如下所示：

query {
 posts {
   title
   content
   date
   author {
     name
     byline
   }
   comments {
     content
     date
     author {
       name
     }
   }
}

您可以在這裡確切地看到您的客戶的要求。如果他們想要更多或更少的細節，他們可以簡單地編輯他們的查詢。他們控制自己想要什麼。隨著他們的資料需求發生變化，他們將使用相同的端點來執行其後續查詢。

您仍將使用相同的資料庫控制器來收集和組織資料。您將以不同的方式將它們“連線”在一起，但大的、合乎邏輯的部分仍然是相同的。

響應區別

使用 REST API，您的客戶端始終會收到結構一致的有效負載。

在設計 API 時，您決定在每個端點上公開哪些欄位以及如何構建資料。作為以使用者為中心的開發人員，您會考慮如何最好地對資料進行分組，以及是否需要針對特定​​用例的新路由。建立這些新端點可為您的使用者提供資料的全新檢視。

客戶可能會針對他們發現的您沒有預料到的問題請求自定義路由。您需要決定是否足夠重要以進入您的待辦事項或允許使用者開發他們自己的解決方案。

然而，GraphQL 響應完全匹配請求的結構。客戶可以設計他們想要的資料的確切範圍和形式。這種方法減少了過度獲取（給客戶端太多）和獲取不足（要求您的客戶端進行多次呼叫）的問題。這種更靈活的過程還允許開發人員專注於新欄位和資料，而無需猜測客戶想要什麼。

建立文件區別

在開發 API 時，您可能會發現自己將文件編寫工作拖到了流程的最後。

但是，首先編寫文件可能是有益的。這種方法有助於減少文件過時的情況，並確保您繼續構建相關功能。

另一種方法將文件作為工單中的最終任務，確保最新的示例和文件。在開發 REST API 時，使用這樣的策略可以使您的文件保持相關性併為您的使用者提供幫助。

GraphQL 採用了一種稍微不同的方法。

作為一個型別化的 API，GraphQL 是有效的自文件化。您可以允許您的客戶訪問 GraphQL 遊樂場以探索 API 以及可用的變更和查詢。當您更新 API 時，這些型別會同時更新。

由於這不是一個單獨的過程，因此您可以更加相信開發團隊保持 GraphQL 文件最新的能力。

快取

由於 GraphQL 全部來自單一路由，因此遠離伺服器的快取策略更具挑戰性。雖然存在一些產品，但沒有那麼多記錄良好的、開箱即用的解決方案。

對於基於 REST 的 API，您可以提供基於路由的快取層以減少伺服器和資料庫負載。這些策略得到了很好的部署，並且長期以來一直是行業標準做法。GraphQL 在這方面有一些追趕。

• 何時選擇 REST 

REST 是一種久經沙場的解決方案，可提供當今的大部分 Web 功能。它可能不是最新和最偉大的技術，但是這匹主力可以完成工作。

通常，當應用程式以可預測和可理解的方式請求您的資料時，REST 是正確的選擇。如果您正在構建的工具可能與其他工具（例如低程式碼平臺）整合，那麼 REST 通常是更好的解決方案。Bubble、Zapier 和其他公司為與基於 REST 的 API 整合提供了良好的支援。

• 何時選擇 GraphQL 

GraphQL 的受歡迎程度正在迅速增加，尤其是在前端開發人員中。

如果您的資料是靈活的，並且可以通過多種不同且不可預測的方式進行查詢，例如使用 CMS，那麼 GraphQL 可能是更好的選擇。

允許您的使用者做出決定，而不是試圖預測他們希望您的應用程式如何呈現資料和公開各種欄位。讓他們控制你的文件齊全的 API。

REST 穩定且眾所周知的架構提供了熟悉度，並使開發人員能夠快速提高工作效率。GraphQL 靈活且自文件化，允許使用者使用根據其特定需求定製的 API。