選擇將包含在下一個專案的技術堆疊中的技術可能很困難。在許多情況下——尤其是在 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 的公司
- 什麼是 RESTful API？
- GraphQL 的優點
- REST 的優點
- GraphQL 的缺點
- REST 的缺點
- 為什麼使用 GraphQL 而不是 REST
- GraphQL 與 REST 對決
什麼是 GraphQL？
GraphQL 是一種 API 查詢語言，也是使用現有資料回答這些查詢的執行時。它還配備了強大的工具來處理最複雜的查詢。
GraphQL 的核心特性是它能夠僅請求和接收所請求的特定資料——僅此而已。這使得隨著您的應用程式擴充套件您的 API 變得更加簡單。
GraphQL 最令人興奮的部分是它能夠在一個端點中為您提供所有資料。
GraphQL API 架構
上圖是 GraphQL 架構的典型表示。客戶端從不同的裝置發出請求，GraphQL 處理他們的請求並只返回他們請求的資料。這巧妙地解決了 RESTful API 中的過度獲取和獲取不足的問題。
在 GraphQL 遊樂場中成功查詢
在上面的示例中，我們展示了一個 GraphQL 遊樂場以及如何使用單個端點查詢資料。頂部是 API 端點，左側是請求大陸名稱的查詢，最後，在右側，我們響應我們請求的查詢。
GraphQL 由 Facebook 建立，主要目的是解決他們的移動應用程式開發人員在使用 REST API 時的體驗。自 2015 年釋出第一個開源版本以來，GraphQL 經歷了巨大的增長，因為科技行業的大公司採用了該技術。
使用 GraphQL 的公司
下面列出了一些在其伺服器上積極使用 GraphQL 的公司和應用程式。
Facebook 建立了 GraphQL，自 2012 年以來，他們一直在生產中使用它來支援他們的移動應用程式。這家價值數十億美元的社交網路公司於 2015 年開源了 GraphQL 規範，使其可以在許多環境和各種規模的團隊中訪問.
Facebook 使用 GraphQL
GitHub
GitHub 還通過提供 GraphQL API 來宣佈使用 GraphQL，該 API 用於使用 GitHub GraphQL API 建立整合、檢索資料和自動化您的工作流程。GitHub GraphQL API 提供比 GitHub REST API 更精確和靈活的查詢。
GitHub 也使用 GraphQL
Pinterest 也是 GraphQL 的早期採用者。這家照片共享巨頭公開討論了他們對 GraphQL 的早期探索，以及他們如何使用支援其價值數十億美元的公司的 GraphQL 技術。
Pinterest 也將 GraphQL 用於他們的網站
許多其他價值數十億美元的公司，例如 Intuit、Shopify、Coursera 和 Airbnb，都使用 GraphQL 為他們的應用程式提供支援。這種對 REST 的廣泛偏好只會繼續增長。
什麼是 RESTful API？
REST 代表“Representational State Transfer”，這是一種分散式超媒體系統的軟體架構風格。它定義了伺服器和客戶端之間交換資源的原則和約束。
如果 API 遵循這些原則，則該 API 的應用程式稱為“RESTful”。WordPress REST API 就是一個很好的例子。
以下是 API 必須滿足的一些原則和約束才能被稱為 Restful API：
- 客戶端-伺服器解耦：客戶端（前端）和伺服器（後端）完全分離，只能通過端點進行通訊。
- 統一的介面：介面中看到的資料在所有裝置上都是相同的。
- 無狀態：伺服器不記得當前請求是否是第一次發出。每次發出請求時，它都需要包含從頭開始處理它所需的所有資訊。
- 可快取性：允許快取和會話儲存，但必須將它們配置為允許終端使用者選擇退出資料快取。
- 分層系統架構： API 的設計必須使客戶端和伺服器都無法判斷它們是直接通訊還是通過中介進行通訊。
下圖是基本的 REST 架構。它顯示了通常如何處理請求和響應。
REST API 架構
GraphQL 的優點
以下是使用 GraphQL 的一些優勢，說明了為什麼它對於構建下一個價值十億美元的應用程式綽綽有餘。
通過單個 API 端點獲取資料
GraphQL 的最大優勢在於它能夠通過單個 API 端點訪問任何或所有資料點。
RESTful API 最常見的問題之一是有太多端點來訪問資訊。在 GraphQL 中，您只有一個端點，因此您無需傳送多個請求來檢索有關物件的不同資訊。
下圖描繪了一個使用 RESTful API 和 GraphQL 檢索資源的清晰示例。可以看到 GraphQL 伺服器中只有一個端點可以訪問資源，而 RESTful API 中需要多個 API 端點來訪問不同的資源。
REST 和 GraphQL 中的 API 端點
沒有過度獲取或不足獲取
過度或不足的問題是 RESTful API 的一個已知問題。這是當客戶端通過點選返回固定資料結構的端點來下載資料時，或者他們檢索的資料多於或少於他們的預期。
過度獲取會導致請求接收（或“獲取”）比給定請求所需的資料更多的資料。想象一下，您正在獲取一個表中的所有使用者，目的是在您的主頁上顯示他們的使用者名稱。在這種情況下，過度獲取將返回每個使用者的所有資料，包括（但不僅是）名稱。
獲取不足的情況比較少見，但當特定端點未能提供所有請求的資訊時，確實會發生這種情況。客戶將需要根據需要發出額外的請求以訪問其他資訊。
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 與 REST
小結
GraphQL 是一種遵循 RESTful API 架構模式的新技術，就像引入 REST 來解決 SOAP API 模式的問題一樣。
GraphQL 為您提供更快的響應、針對所有查詢的單一 API 端點以及用於一致資料訪問的嚴格模式。這些原因使得價值數十億美元的公司開始轉向 GraphQL，即使是在早期階段。然而，儘管有其侷限性，GraphQL 的祖先 REST 繼續在舞臺上保持強大的存在。
在本指南中，我們探討了您需要了解的有關 GraphQL 和 RESTful API 的所有資訊，包括每種技術的優缺點，以幫助您自信地決定您更喜歡哪一種。我們還討論了 RESTful API 的已知問題——例如過度獲取、獲取不足和多個端點——以及 GraphQL 如何嘗試解決這些問題並提高應用程式的效能。
評論留言