你還在用 REST API 嗎？要不換一個！
點擊上方藍(lán)色字體，選擇“標(biāo)星公眾號”
優(yōu)質(zhì)文章，第一時間送達(dá)
作者 | Harsha Vardhan 策劃 | 田曉旭
通過 HTTP 發(fā)送數(shù)據(jù)，許多開發(fā)人員已經(jīng)在用 REST 了，而 GraphQL 通常被認(rèn)為是一種代替遺留 REST API 的技術(shù)。本文將對比兩者各自的優(yōu)勢、劣勢以及它們之間的差異，希望能為你今后項目的技術(shù)選型提供幫忙。
1.什么是 REST？
REST（Representational state transfer，表述性狀態(tài)轉(zhuǎn)移） 是一種 API 設(shè)計架構(gòu)，用于通過使用一組預(yù)定義的無狀態(tài)操作（包括GET、POST、PUT和DELETE）來實現(xiàn) Web 服務(wù)。
REST 的核心思想是，通過向資源的 URL 發(fā)送請求并獲得響應(yīng)（通常是 JSON，但這取決于 API）來檢索資源。
REST 的優(yōu)勢
REST 是 可擴(kuò)展的，因為它分離了客戶端和服務(wù)端，因此我們可以輕松擴(kuò)展應(yīng)用程序。 靈活性 是使用 REST 的另一個優(yōu)勢，因為可以將其設(shè)計成處理不同類型的調(diào)用并返回不同的數(shù)據(jù)格式。
REST 的劣勢
抓取過度——這是指 API 端點提供的信息比客戶端所需要的要多得多。 抓取不足——這是指 API 端點并沒有提供所需的全部信息。因此，客戶端必須發(fā)出多個請求才能獲取應(yīng)用程序所需的全部內(nèi)容。
2.什么是 GraphQL？
GraphQL 是一種 API 設(shè)計架構(gòu)，它采用了不同的方法，在這種方法中，所有的東西都被視為一個表示其連接的圖。這也意味著我們可以定制我們的請求，這樣我們就可以從端點發(fā)出任何請求，并且能獲得我們所請求的任何內(nèi)容，僅此而已，無需更多操作。我們傳遞查詢并得到響應(yīng)。除此之外，它還允許我們將不同的實體組合到單個查詢中。
GraphQL 的優(yōu)勢
檢索精確的數(shù)據(jù)，無任何多余數(shù)據(jù)。在 GraphQL 中，可以得到我們所請求的內(nèi)容，這是一個很大的優(yōu)勢。 客戶端開發(fā)速度更快。通常，當(dāng)數(shù)據(jù)需求發(fā)生變化時，我們只需修改查詢，且無需太多的變更，因此可以快速進(jìn)行產(chǎn)品迭代。客戶端和服務(wù)端團(tuán)隊都可以獨立工作，前提是他們都知道數(shù)據(jù)的結(jié)構(gòu)。
GraphQL 的劣勢
對于簡單的應(yīng)用程序來說，設(shè)置類型、查詢等可能有點 復(fù)雜，因為使用 REST 可以很容易地完成。 它使用的是 單個端點，而不是遵循 HTTP 規(guī)范進(jìn)行緩存。在網(wǎng)絡(luò)級別進(jìn)行緩存是很重要的，因為它可以減少到服務(wù)端的流量。
3.兩者對比的簡單示例
例如，我們正在顯示用戶的供稿，其中包含用戶的帖子及其關(guān)注者的列表。在我們的例子中，我們必須顯示該帖子的作者、帖子以及該用戶的關(guān)注者。
如果使用 REST，我們至少要發(fā)出 2 到 3 個請求，類似于：
/user/以獲得用戶（作者）的詳細(xì)信息，比如名稱。/user/獲取該用戶發(fā)布的帖子列表。/posts /user/以獲取該用戶的關(guān)注者列表。/followers
但是在所有這些情況下，我們都過度抓取數(shù)據(jù)了。例如，在第一個請求中，我們只需要名稱，但是當(dāng)我們使用這種方法時，我們將會獲取該用戶相關(guān)的所有詳細(xì)信息。
此時就是 GraphQL 顯示其強(qiáng)大功能的時候了。我們需要指定查詢，然后才能獲得所需的輸出。要使用 GraphQL 實現(xiàn)相同的效果，我們可以使用類似于這樣的查詢：
query?{??
??User(id:?'123')?{????
????name????
????posts?{??????
???????title????
????}????
????followers?{??????
????name????
????}??
??}
}
通過使用這樣的查詢，我們將能獲得具有以下屬性的 JSON 響應(yīng)。簡潔明了，不是嗎？
4.GraphQL vs REST
總結(jié)一下，兩者主要有如下幾個明顯的差異：
數(shù)據(jù)抓取
REST 會導(dǎo)致抓取過度或抓取不足，而 GraphQL 則不會這樣。在 GraphQL 中，我們得到的就是我們所要求的。
對象定義（JSON 響應(yīng)）
在 REST 中，我們可以在后端定義對象，而在 GraphQL 中，我們則要在前端定義該對象。
自動緩存
REST 能自動生效緩存，而 GraphQL 則沒有自動緩存系統(tǒng)，但是可以借助 Apollo Client、Relay 等客戶端實現(xiàn)緩存。
錯誤處理
REST 中的錯誤處理比 GraphQL 簡單得多，GraphQL 通常會給我們一個 200 OK 的狀態(tài)碼，即使已經(jīng)出現(xiàn)錯誤了。但是，當(dāng)使用 Apollo Client、Relay 等客戶端時，它也能很容易處理錯誤。
5.結(jié)論
與 REST 相比， GraphQL 當(dāng)然更具優(yōu)勢，但它可能并不總是最佳實踐。正如我前面所說的，是選擇 REST 還是 GraphQL，取決于我們的應(yīng)用程序。
希望本文能為大家在未來項目的技術(shù)選型中提供幫忙。如果大家想分享自己關(guān)于 GraphQL 或 REST 的經(jīng)驗，請在評論區(qū)留言，感謝您的閱讀！
原文鏈接：
https://medium.com/javascript-in-plain-english/stop-using-rest-for-apis-d697727ae6dd
PS：歡迎在留言區(qū)留下你的觀點，一起討論提高。如果今天的文章讓你有新的啟發(fā)，歡迎轉(zhuǎn)發(fā)分享給更多人。
Java后端編程交流群已成立
公眾號運(yùn)營至今，離不開小伙伴們的支持。為了給小伙伴們提供一個互相交流的平臺，特地開通了官方交流群。掃描下方二維碼備注 進(jìn)群 或者關(guān)注公眾號 Java后端編程 后獲取進(jìn)群通道。
—————END—————
推薦閱讀：
最近面試BAT，整理一份面試資料《Java面試BAT通關(guān)手冊》，覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫、數(shù)據(jù)結(jié)構(gòu)等等。
獲取方式：點“在看”，關(guān)注公眾號并回復(fù)?666?領(lǐng)取，更多內(nèi)容陸續(xù)奉上。
明天見(??ω??)??