GraphQL vs REST：你需要知道的一切
已發表: 2022-09-20選擇將包含在下一個項目的技術堆棧中的技術可能很困難。 在許多情況下——尤其是在 GraphQL 和 RESTful API 之間進行選擇時——都是為了選擇下一個最佳 API 設計架構。
構建 API 有四種重要的方法：SOAP、GRPC、REST 和 GraphQL。 每當我們想要構建 API 時，我們經常將注意力集中在 REST 和 GraphQL 上。 這是因為 REST 改變了使用 SOAP 和 GRPC 構建 API 的傳統方式。
GraphQL 被廣泛標記為更好的 REST，因為它代表了一種更好的構建 API 的方式。 許多開發人員認為 GraphQL 將取代 REST。 更多人已經發現 GraphQL 有助於解決開發人員在構建 REST API 時面臨的一些常見挑戰。
這兩種構建 API 的方法完全不同。 在實踐中，這些技術通過發送 HTTP 請求並接收結果來工作。 它們各有利弊，在本文中，我們將廣泛討論這兩種改變了我們開發和擴展 API 方式的偉大技術。
不過，在深入了解細節之前，讓我們先探討一下 GraphQL 和 RESTful API 的含義。
什麼是 GraphQL？
GraphQL 是一種 API 查詢語言，也是使用現有數據回答這些查詢的運行時。 它還配備了強大的工具來處理最複雜的查詢。
GraphQL 的核心特性是它能夠僅請求和接收所請求的特定數據——僅此而已。 這使得隨著您的應用程序擴展您的 API 變得更加簡單。
GraphQL 最令人興奮的部分是它能夠在一個端點中為您提供所有數據。
上圖是 GraphQL 架構的典型表示。 客戶端從不同的設備發出請求，GraphQL 處理他們的請求並只返回他們請求的數據。 這巧妙地解決了 RESTful API 中的過度獲取和獲取不足的問題。
在上面的示例中，我們展示了一個 GraphQL 遊樂場以及如何使用單個端點查詢數據。 頂部是 API 端點，左側是請求大陸名稱的查詢，最後，在右側，我們響應我們請求的查詢。
GraphQL 由 Facebook 創建，主要目的是解決他們的移動應用程序開發人員在使用 REST API 時的體驗。 自 2015 年發布第一個開源版本以來，GraphQL 經歷了巨大的增長，因為科技行業的大公司採用了該技術。
使用 GraphQL 的公司
下面列出了一些在其服務器上積極使用 GraphQL 的公司和應用程序。
Facebook 創建了 GraphQL，自 2012 年以來，他們一直在生產中使用它來支持他們的移動應用程序。這家價值數十億美元的社交網絡公司於 2015 年開源了 GraphQL 規範，使其可以在許多環境和各種規模的團隊中訪問.
GitHub
GitHub 還通過提供 GraphQL API 來宣布使用 GraphQL，該 API 用於使用 GitHub GraphQL API 創建集成、檢索數據和自動化您的工作流程。 GitHub GraphQL API 提供比 GitHub REST API 更精確和靈活的查詢。
Pinterest 也是 GraphQL 的早期採用者。 這家照片共享巨頭公開討論了他們對 GraphQL 的早期探索，以及他們如何使用支持其價值數十億美元的公司的 GraphQL 技術。
許多其他價值數十億美元的公司，例如 Intuit、Shopify、Coursera 和 Airbnb，都使用 GraphQL 為他們的應用程序提供支持。 這種對 REST 的廣泛偏好只會繼續增長。
什麼是 RESTful API？
REST 代表“Representational State Transfer”，這是一種分佈式超媒體系統的軟件架構風格。 它定義了服務器和客戶端之間交換資源的原則和約束。
如果 API 遵循這些原則，則該 API 的應用程序稱為“RESTful”。 WordPress REST API 就是一個很好的例子。
以下是 API 必須滿足的一些原則和約束才能被稱為 Restful API：
- 客戶端-服務器解耦：客戶端（前端）和服務器（後端）完全分離，只能通過端點進行通信。
- 統一的界面：界面中看到的數據在所有設備上都是相同的。
- 無狀態：服務器不記得當前請求是否是第一次發出。 每次發出請求時，它都需要包含從頭開始處理它所需的所有信息。
- 可緩存性：允許緩存和會話存儲，但必須將它們配置為允許最終用戶選擇退出數據緩存。
- 分層系統架構： API 的設計必須使客戶端和服務器都無法判斷它們是直接通信還是通過中介進行通信。
下圖是基本的 REST 架構。 它顯示了通常如何處理請求和響應。
GraphQL 的好處
以下是使用 GraphQL 的一些好處，說明了為什麼它對於構建下一個價值十億美元的應用程序綽綽有餘。
通過單個 API 端點獲取數據
GraphQL 的最大優勢在於它能夠通過單個 API 端點訪問任何或所有數據點。
RESTful API 最常見的問題之一是有太多端點來訪問信息。 在 GraphQL 中，您只有一個端點，因此您無需發送多個請求來檢索有關對象的不同信息。
下圖描繪了一個使用 RESTful API 和 GraphQL 檢索資源的清晰示例。 可以看到 GraphQL 服務器中只有一個端點可以訪問資源，而 RESTful API 中需要多個 API 端點來訪問不同的資源。
沒有過度獲取或不足獲取
過度或不足的問題是 RESTful API 的一個已知問題。 這是當客戶端通過點擊返回固定數據結構的端點來下載數據時，或者他們檢索的數據多於或少於他們的預期。
過度獲取會導致請求接收（或“獲取”）比給定請求所需的數據更多的數據。 想像一下，您正在獲取一個表中的所有用戶，目的是在您的主頁上顯示他們的用戶名。 在這種情況下，過度獲取將返回每個用戶的所有數據，包括（但不僅是）名稱。
想知道我們是如何將流量提高到 1000% 以上的嗎？
加入 20,000 多人的行列，他們會通過 WordPress 內幕技巧獲得我們的每週時事通訊！
獲取不足的情況比較少見，但當特定端點未能提供所有請求的信息時，確實會發生這種情況。 客戶將需要根據需要發出額外的請求以訪問其他信息。
GraphQL 通過抓取客戶端請求的確切資源而無需任何額外細節，有效地解決了過度獲取或獲取不足的問題。
更好地處理複雜系統和微服務
GraphQL 可以統一和隱藏集成多個系統的複雜性。
例如，假設我們想從單體後端應用程序遷移到微服務架構。 GraphQL API 通過將各種微服務合併到一個 GraphQL 模式中來幫助處理它們之間的通信。
一旦定義了這些模式，前端和後端就可以單獨通信而無需任何進一步的更改，因為前端知道模式中的數據將始終在整個系統中保持同步。
快速安全
過度獲取的問題可能會導致客戶端的帶寬消耗更高，這可能會及時導致您的應用程序滯後。 使用 RESTful API 設計模式從巨大的有效負載中整理出所需的信息更加耗時。
由於 GraphQL 能夠避免過度獲取和獲取不足，服務器返回一個安全、易於閱讀和可預測的形狀，從而使您的 API 請求和響應更快。
REST 的好處
儘管 GraphQL 越來越受歡迎，但 REST 仍然是最流行的 API 標準之一。 讓我們來看看為什麼。
- 學習曲線： RESTful API 是最容易學習和理解的。 這是它優於其他 API 的主要優勢。
- 序列化： REST 提供了一種靈活的方法和格式來序列化 JSON 中的數據。
- 緩存： REST API 可以在 HTTP 代理服務器和緩存的幫助下管理高負載。
- 複雜請求： REST API 對不同的請求有一個單獨的端點，這有助於使復雜請求比其他 API 更易於管理
- 乾淨且簡單： REST API 優雅、簡單且乾淨。 它們很容易探索。
- 標準 HTTP 過程： REST 使用標準 HTTP 過程調用來檢索數據並發出請求。
- 客戶端/服務器：這意味著它的業務邏輯與表示分離。 所以你可以改變一個而不影響另一個。
- REST 是無狀態的：客戶端和服務器之間交換的所有消息都具有知道如何處理消息所需的所有上下文。
GraphQL 的缺點
既然我們已經討論了 GraphQL 與 REST 的優點，讓我們來探討一下 GraphQL 的一些缺點：
- 困難的學習曲線： GraphQL 不像 REST 那樣容易學習。 構建 GraphQL API 最具挑戰性的部分是設計模式。 這需要大量時間和領域知識。
- 文件上傳： GraphQL 沒有原生文件上傳功能。 這可以使用 Base64 編碼來解決，但是以這種方式編碼和解碼的成本可能既耗時又昂貴。
- Web緩存：緩存有助於減少服務器的頻繁流量，通過將頻繁訪問的信息保持在服務器附近，從而加快請求和響應過程。 GraphQL 不支持或不依賴 HTTP 緩存方法，而是依賴於 Apollo 或 Relay 客戶端的緩存機制。
- 不適合小型應用程序： GraphQL 可能不是構建小型應用程序的最佳 API 架構。 如果您的應用不需要 GraphQL 提供的更靈活的查詢，那麼 REST 就是您的選擇。
- 複雜查詢問題： GraphQL 能夠準確地為客戶端提供所需內容的能力也可能導致查詢傳播問題。 如果客戶端提交的嵌套查詢過多，可能會導致發送錯誤的查詢，這對服務器來說可能非常耗時。 最好使用帶有自定義端點的 REST 來滿足此類請求。
REST 的缺點
現在，讓我們將注意力轉向 REST 的一些缺點：
- 多次往返： REST API 的最大問題是眾多端點的性質。 這意味著客戶端要獲取完整應用程序的所有資源，需要進行無數次往返才能獲取數據。
- Over-fetching and Under-fetching：過度獲取和不足獲取的問題是 RESTful APIS 的一個主要缺點。 由於獲取大量不需要的有效負載，它可能導致響應滯後。
- 層次結構：由於 REST API 是基於 URI 引用資源構建的，因此它們不適合在簡單層次結構中自然組織或訪問的資源。
為什麼使用 GraphQL 而不是 REST
接下來，我們將討論為什麼您可能希望在未來的 API 開發中考慮使用 GraphQL 而不是 RESTful API。
強類型模式
GraphQL 使用強類型系統來定義 API 的功能。 在 GraphQL 中，模式定義語言 (SDL) 用於定義圍繞客戶端如何訪問服務器數據的參數。 所有暴露給客戶端的 API 都寫在 SDL 中，解決了 RESTful API 中出現的數據不一致問題。
沒有過度獲取或獲取不足
過度或不足的問題是 RESTful API 的一個已知問題，其中客戶端返回的信息比他們請求的多或少。 GraphQL 通過為客戶端提供一種媒介來指定所需信息，然後準確且僅返回該特定信息來解決此問題。
多個端點
RESTful API 的最大問題之一是有太多端點來訪問信息。
假設您想通過他們的 ID 號訪問特定用戶。 您將看到像/users/1這樣的端點。 但是，如果您想訪問該用戶的照片，則必須向另一個端點發送請求，例如/users/1/photos 。
在 GraphQL 中，您有一個端點，您無需發送多個請求來檢索有關用戶的不同信息。
GraphQL 與 REST 對決
最後，我們將探討 GraphQL 和 RESTful API 之間的主要區別。 之後，我們將討論一個好的 API 設計的一些特性，並比較每種技術如何處理它們。
表現
毫無疑問，GraphQL 比 RESTful API 執行得更快，因為它能夠提供單個端點來訪問您的所有資源。 RESTful API 使用多個端點，這可能會導致網絡延遲。
查詢複雜度
由於端點沒有分成多個端點，GraphQL 查詢會隨著時間的推移變得越來越複雜。 另一方面，RESTful API 端點是分離的，這將 RESTful API 限制為簡單的查詢。
人氣和社區支持
GraphQL 是一種不斷發展的 API 架構模式和查詢語言。 雖然它還很年輕，但它的採用率和資源池正在迅速增長，對於那些有興趣自己學習它的人來說，資源已經比比皆是。
另一方面，REST 已經擁有廣泛的社區支持，並繼續被各種公司使用，從構建小型微服務的公司到創建複雜社交應用程序的公司等等。
目前，GraphQL 與 REST 的人氣較量是平局。 這兩種技術繼續被開發社區廣泛使用並得到很好的支持。
學習曲線
GraphQL 的學習曲線非常陡峭。 它需要 API 開發和通用軟件工程的良好領域知識。 一個完整的初學者將很難充分理解 GraphQL 以構建複雜的應用程序。
相反，REST 非常容易上手，並且需要較少的領域知識。 RESTful API 很好地集成到大多數主要的編程語言和流行的框架中，這使得學習變得非常容易。
概括
GraphQL 是一種遵循 RESTful API 架構模式的新技術，就像引入 REST 來解決 SOAP API 模式的問題一樣。
GraphQL 為您提供更快的響應、針對所有查詢的單一 API 端點以及用於一致數據訪問的嚴格模式。 這些原因使得價值數十億美元的公司開始轉向 GraphQL，即使是在早期階段。 然而，儘管有其局限性，GraphQL 的祖先 REST 繼續在舞台上保持強大的存在。
在本指南中，我們探討了您需要了解的有關 GraphQL 和 RESTful API 的所有信息，包括每種技術的優缺點，以幫助您自信地決定您更喜歡哪一種。 我們還討論了 RESTful API 的已知問題——例如過度獲取、獲取不足和多個端點——以及 GraphQL 如何嘗試解決這些問題並提高應用程序的性能。
您現在已經有足夠的洞察力來選擇 GraphQL 與 REST 是否適合您的下一個項目。 在評論部分讓我們知道您將與您選擇的獲勝者一起構建什麼！