REST是構建API的一種流行方法，而且比GraphQL應用更廣泛，讓我們看看GraphQL和REST的區別。
Rest是一個概念
REST是一個事實上的架構標準，但它實際上沒有規範，有大量的非官方定義。GraphQL有一個規範草案，它是一種查詢語言，而不是一個架構，有一套圍繞它的定義良好的工具（和一個繁榮的生態系統）。
REST是建立在現有的架構之上的，如HTTP，而GraphQL則是建立自己的一套規則。這可能是一個優勢點，也可能不是，因為REST可以使用HTTP層上的快取。GraphQL必須在系統中建立自己的快取。
單一的端點
GraphQL只有一個端點，你在那裡傳送你的所有查詢。通過REST方法，你建立了多個端點，並使用HTTP動詞來區分讀取動作（GET）和寫入動作（POST、PUT、DELETE）。GraphQL不使用HTTP動詞來確定請求型別。
根據您的需求定製
使用REST，您通常無法選擇伺服器返回給您的內容，除非伺服器實現部分響應稀疏欄位集，並且客戶端使用該功能。 API維護人員無法強制執行此類過濾。
API通常會返回比你需要的多得多的資訊，除非你也負責API服務，併為每個不同的請求定製響應。
在GraphQL中，情況就不同了：你向一個端點發出一個請求，只取回你需要的東西。
它避免了服務端大量冗餘資料的返回，查詢速度更快，更靈活。
下面我們來看一個Pizza endpoint的例子。
如果你呼叫GET /pizza/margherita，你將得到一個Margherita比薩。如果你呼叫GET /pizza/napoli，你將得到一份Napoli比薩。
如果你有30種不同的口味，你就會有30個端點（除非你把比薩餅的名字作為引數傳給GET /pizza)
但也許你想要一種特定的比薩，這很容易向服務員描述，但很難向REST endpoint表達。
一個GraphQL端點可以讓你呼叫/pizza，描述你要求的特定成分，以建立你想要的完美比薩。
GraphQL使監測欄位的使用變得容易
在REST中，通常沒有辦法確定一個欄位是否被客戶端所需要，所以當涉及到重構或廢棄時，不可能確定實際的使用情況。
GraphQL可以知道哪些欄位被客戶使用。
訪問巢狀的資料資源
GraphQL產生更少的網路請求。
舉個例子。訪問一個人的所有朋友的姓名。如果你的REST API暴露了一個端點/person/1/friends，返回一個人朋友的資訊列表，你首先通過GET /person/1得到/person/1，然後GET /person/1/friends。
除非一個人的朋友列表已經包含了朋友的名字，否則如果有100個朋友，你就需要向/person端點做101次HTTP請求，這是一個巨大的時間和資源的浪費。
使用GraphQL，你只需要一個請求，即詢問一個人的朋友的名字。
型別
API是基於JSON的，不能提供型別控制。GraphQL有一個型別系統。
哪一個更好？
現在，全世界的開發者正試圖找出從REST遷移到GraphQL是否適合他們的需求。
當你需要公開復雜的資料表示時，客戶可能只需要資料的一個子集，或者他們經常執行巢狀查詢以獲得他們需要的資料時，GraphQL是一個完美的選擇。
與程式語言一樣，沒有單一的贏家，這完全取決於你的需求。
另外，我想說的是：你可以同時使用。
你可以根據你的需要混合和使用REST和GraphQL，有時這是最好的做法。