GraphQL API vs REST API
主要介紹了REST與GraphQL之間的差異以及在什麼情況下使用其中之一。 由於REST是建立API的一種常用方法，比GraphQL更為廣泛使用，所以可以假設你對其相當熟悉，現在讓我們看看GraphQL和REST之間的差異。 REST是一種概念 REST是一種事實上的架構標準，但沒有具體的規範，有許多非官方定義。而GraphQL有一個規範草案，它是一個查詢語言，而不是一種架構，其周圍建立了一套明確的工具集（和一個蓬勃發展的生態系統）。 REST是建立在現有架構之上的，最常見的情況是使用HTTP。而GraphQL則正在構建自己的一套約定，這既可以是優點，也可能不是優點。因為REST可以通過HTTP層的緩存功能免費獲益。 單一端點 GraphQL只有一個端點，您將所有的查詢都發送到該端點。而REST則使用多個端點，並使用HTTP 動詞來區分讀取操作（GET）和寫入操作（POST，PUT，DELETE）。GraphQL不使用HTTP動詞來確定請求類型。 根據需求量身定制 在REST中，您通常無法選擇服務器返回的數據，除非服務器實現了使用稀疏字段集進行部分響應的功能，並且客戶端使用該功能。API維護者無法強制執行此類過濾。 除非您也控制API服務器並為每個不同的請求定制響應，否則API通常會返回比您所需的更多信息。 在GraphQL中，您明確要求您所需的信息，您不會“選擇退出”完整的默認響應，而需要選擇您想要的字段。 這有助於節省服務器的資源，因為您可能需要更少的處理，同時也節省了網絡流量，因為要傳輸的有效載荷更小。 一個很好的例子來形象地展示這一點是一個Pizza端點的示例（我是義大利人，一個披薩的例子很完美）。 如果你調用GET /pizza/margherita，你會得到一個馬若里披薩。 如果你調用GET /pizza/napoli，你會得到一個拿坡里披薩。 如果你有30個不同的口味，你將有30個端點（除非你把披薩名稱作為參數傳遞給GET /pizza，例如）。 但也許你想要一種特定的披薩，但卻不要一種你不喜歡的成分。向服務生提出這個要求很容易，但對於REST端點來說有點困難。 一個GraphQL端點將讓你調用/pizza，然後你可以要求特定的成分，來打造你想要的完美披薩。 GraphQL使得監測字段使用變得容易 在REST中通常無法確定客戶端是否需要某個字段，因此在進行重構或淘汰時，無法確定實際使用情況。 GraphQL使得追踪客戶端使用的字段成為可能。 訪問嵌套數據資源 GraphQL允許進行更少的網絡調用。 來看一個例子：您需要訪問一個人的朋友的名字。如果您的REST API公開了一個/person端點，該端點返回一個包含朋友ID列表的人物對象，通常可以先通過GET /person/1獲取人物信息，其中包含朋友的ID列表。 除非該人的朋友列表已經包含有朋友的名字，否則對於有100個朋友的情況，您需要對/person端點發起101個HTTP請求，這是一個巨大的時間成本，也是一個資源密集型操作。 而GraphQL只需要一個請求，該請求要求查詢該人物的朋友的名字。 類型 REST API基於無法提供類型控制的JSON。GraphQL具有一個類型系統。 哪一個更好？ 全球各地的組織都在質疑他們的API技術選擇，他們正試圖找出從REST遷移到GraphQL是否適合他們的需求。 當您需要公開複雜的數據表示且客戶端可能只需要數據的子集，或者他們定期執行嵌套查詢以獲取所需的數據時，GraphQL非常適合。 和編程語言一樣，沒有絕對的贏家，一切都取決於您的需求。 同時，我還想說一點：您可以同時使用兩種方法。 您可以根據您的需求混合使用REST和GraphQL，有時這是最好的方法。