GraphQL和RESTful的比較

GraphQL和RESTful的比較

引言

在2017年5月，Github也發佈了它第四版的API，採用的正是GraphQL，而且推薦集成商在GitHub App中使用最新版本的GraphQL API v4。

思考

GitHub的REST API已經很是完善，設計得很優秀，不少公司開發本身的REST API時都會參考GitHub的實現。

那GitHub爲何選擇GraphQL？

RESTful的一些不足

• 擴展性，單個RESTful接口返回數據愈來愈臃腫

  好比獲取用戶信息/users/:id，最初可能只有id、暱稱，但隨着需求的變化，用戶所包含的字段可能會愈來愈多，年齡、性別、頭像、經驗、等級，等等等等。

  而具體到某個前端頁面，可能只須要其中一小部分數據，這樣就會增長網絡傳輸量，前端獲取了大量沒必要要的數據。

• 某個前端展示，實際須要調用多個獨立的RESTful API才能獲取到足夠的數據

  好比一個文章詳情頁，最初可能只須要文章內容，那麼前端就調用/articles/:aid獲取到文章內容來展示就好了

  但隨着需求的演進，產品可能會但願加上做者信息（暱稱、頭像等），這時前端又須要在獲取文章詳情後，根據其中的做者id字段繼續獲取做者相關的信息，/user/:uid

  而後，需求又變化了，產品但願在加上這篇文章的評論，這時前端須要繼續調用/comment/:aid來拉取評論列表

  對於Web前端而言，因爲ajax技術的存在，這種的請求數據方式，也就開發上稍微麻煩些，並不會形成太大的問題；但對於App來講，渲染的方式不一樣，必需要拉取的所有的數據以後，才能繪製界面，就會致使這個界面必需要等到全部3個RESTful接口的返回數據都拿到，才能進行繪製。

GraphQL的一些優勢

• 所見即所得

  查詢的返回結果就是輸入的查詢結構的精確映射

  查詢：

  {
      user(uid:1) {
          uid
          name
      }
  }

  返回：

  {
    "data": {
      "user": {
        "uid": "1",
        "name": "xxx"
      }
    }
  }

• 減小網絡請求次數

  若是設計的數據結構是從屬的（例如，上文中文章的做者信息），直接就能在查詢語句中指定

  {
      article(aid:1) {
          title
          content
          author {
              uid
              name
          }
      }
  }

  即便數據結構是獨立的，也能夠在查詢語句中指定上下文，只須要一次網絡請求，就能得到資源和子資源的數據（例如，上文中文章的評論信息）

  {
      article(aid:1) {
          title
          content
          author {
              uid
              name
          }
      },
      comment {
          content,
          author {
              uid
              name
          }
      }
  }

• 代碼即文檔

  GraphQL會把schema定義和相關的註釋生成可視化的文檔，從而使得代碼的變動，直接就反映到最新的文檔上，避免RESTful中手工維護可能會形成代碼、文檔不一致的問題。

• 參數類型強校驗

  RESTful方案自己沒有對參數的類型作規定，每每都須要自行實現參數的校驗機制，以確保安全。

  但GraphQL提供了強類型的schema機制，從而自然確保了參數類型的合法性。

使用心得

從Facebook最初開發GraphQL的目的，和筆者實際使用的狀況而言，GraphQL仍是存在一些缺點的，徹底替代RESTful做爲一種新的接口規範還有些爲時過早.

GraphQL做爲RESTful的一種輔助工具，尤爲是針對前端App在複雜頁面，原本要調用有上下文關係的屢次RESTful請求時，採用GraphQL，只須要一次請求，就能夠拿回所需的所有數據（有點JSON直出的意思），仍是能夠起到很是好的效果，大大提高App的性能。