主要介紹了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,有時這是最好的方法。