「REST API」作為API設計方法早已成為業界標準。然而，近年來，隨著前端變得越來越複雜，越來越多的公司開始採用 GraphQL。 在討論技術細節之前，我們先以在餐廳點餐為例來思考一下兩者之間的差異。
REST API 在餐廳中的局限性
REST API 就像一個“美食廣場”，每個菜單都有不同的櫃檯。
例如，假設您要訂購一份漢堡包套餐。您必須先前往漢堡櫃檯（/api/burgers/1），然後前往馬鈴薯櫃檯（/api/sides/potato），最後前往飲料櫃檯（/api/drinks/coke）。
這就需要多次來回櫃檯（多次要求）的麻煩。另外，即使你想把漢堡中的泡菜去掉，櫃檯也會送你有泡菜的成品。這是一個稱為「過度獲取」的問題，即檢索不必要的資料。
名為 GraphQL 的終極定制
另一方面，GraphQL 是「非常能幹的私人服務員」。 你遞給服務生一份訂單（查詢），上面寫著「漢堡（不含泡菜）、小份薯條和可樂」。然後服務生去廚房，把你指定的東西端到一個托盤上。
這是GraphQL最大的特色。前端（客戶）可以準確地指定他們想要什麼資料以及以什麼形式，後端將相應地傳回準確的資料量。
GraphQL 的好處和實作障礙
此機制具有以下優點：
- 減少通訊量： 在智慧型手機等行動環境中，不取得不必要的數據可以顯著提高效能。
- 靈活的UI變更： 即使您想要在螢幕上新增新的顯示項，也不需要像REST那樣讓後端建立新的端點，只需重寫前端查詢即可完成。
另一方面，它不是一根魔杖。 還有諸如「快取難以控制」、「容易出現N+1問題」、「後端實現變得更加困難」等問題。對於簡單的部落格網站，REST API往往更簡單、更合適。
你該選擇哪一個？
GraphQL 是開發在單一畫面上顯示多種類型資源（使用者資訊、貼文、留言、按讚等）的複雜 Web 應用程式的最佳選擇。 確定您的“餐廳”收到最多的訂單類型並選擇合適的架構。