GraphQL vs REST API 架構(gòu)，誰更勝一籌？
2015年， Facebook開源GraphQL 。 此后，它在前端Web中大受歡迎。 傳統(tǒng)的REST API有何不足？GraphQL優(yōu)勢何在？在本文中， 我們將深入探討GraphQL的設(shè)計原則，比較 GraphQL 與 REST 的異同，并討論GraphQL 相對其他架構(gòu)的優(yōu)點(diǎn)。
1 你的 API 應(yīng)該用哪項(xiàng)技術(shù)？
自從 2015 年 Facebook 開源 GraphQL 規(guī)范以來，它就在前端 Web 開發(fā)中迅速流行起來。
-
為什么這種新技術(shù)會突然流行起來？
-
與傳統(tǒng) REST API 相比，GraphQL 提供了哪些優(yōu)勢？
我們將討論 GraphQL 的設(shè)計原則，比較 GraphQL 與 REST 中的相同請求，并 深入探討 GraphQL 相對其他架構(gòu)的優(yōu)點(diǎn) 。
為理解 GraphQL 作為 API 架構(gòu)的好處，我們要討論 API 在客戶端 - 服務(wù)器結(jié)構(gòu)中的作用。API（應(yīng)用程序編程接口）是一個中間層，它允許服務(wù)器從客戶端接收結(jié)構(gòu)化數(shù)據(jù)請求，并針對請求的數(shù)據(jù)發(fā)送結(jié)構(gòu)化的響應(yīng)。設(shè)計 API 架構(gòu)的方法有很多種。
讓我們來研究一下促使 GraphQL 適合現(xiàn)代化 Web 應(yīng)用程序的重要基本設(shè)計原則。
2 GraphQL 服務(wù)器的設(shè)計原則
GraphQL 規(guī)范概括了 5 個設(shè)計原則，這使其成為現(xiàn)代前端開發(fā)的良好解決方案。 我們看一下 GraphQL 的設(shè)計原則，并以 Facebook 新聞推送作為我們的用例。
-
查詢?yōu)榉謱咏Y(jié)構(gòu)，使用將查詢與響應(yīng)數(shù)據(jù)1對1匹配的分層和嵌套字段格式。查詢和響應(yīng)的形狀類似于樹，可查詢每個項(xiàng)的其他嵌套字段。在 Facebook 的新聞推送中，這種結(jié)構(gòu)允許一個查詢返回一個帖子列表、每個特定帖子的評論，以及每個評論的點(diǎn)贊。
-
該結(jié)構(gòu)以產(chǎn)品為中心，關(guān)注前端希望如何接收數(shù)據(jù)，并構(gòu)建交付所需的運(yùn)行時。這使得 Facebook 的新聞推送可通過一次請求從后端獲取需要的所有數(shù)據(jù)，使服務(wù)器按照 GraphQL 的規(guī)范從不同的端點(diǎn)獲取數(shù)據(jù)。
-
它使用特定于應(yīng)用程序的類型系統(tǒng)，該系統(tǒng)使開發(fā)人員能在執(zhí)行前確保查詢使用了有效類型，并且語法正確。例如，新聞推送的 GraphQL 模式要求字段“user”必須包含一個字符串，而“likes”必須包含一個數(shù)字。如果查詢試圖添加不同類型的輸入，GraphQL 將在執(zhí)行查詢前拋出一個錯誤。
-
GraphQL 查詢是在客戶端指定的，因此，客戶端確切知道它將以何種格式接收數(shù)據(jù)。這意味著，如果前端請求的格式是包含用戶名、評論和點(diǎn)贊的 post 數(shù)據(jù)，那么來自 Facebook 新聞推送的請求會構(gòu)建在一個對象中，而不是像其他架構(gòu)那樣構(gòu)建多個單獨(dú)的數(shù)據(jù)塊。
-
使用 GraphQL 的服務(wù)器結(jié)構(gòu)必須是內(nèi)省的，或者可由 GraphQL 自己查詢。于是才有了像 GraphiQL 或 GraphQL playground 這樣的強(qiáng)大工具。這兩種工具都可以讓 Facebook 開發(fā)人員準(zhǔn)確地看到在他們的服務(wù)器上使用了哪些查詢和字段。
為討論向 GraphQL 的轉(zhuǎn)變，以及這些設(shè)計原則如何給開發(fā)帶來好處。
我們首先深入了解傳統(tǒng)的 REST API 架構(gòu)和它的不足之處。
3 傳統(tǒng)的 RESTful 架構(gòu)
REST 架構(gòu)的設(shè)計范式側(cè)重于分配 HTTP 請求方法（GET、POST、PUT、PATCH、DELETE）和 URL 端點(diǎn)之間的關(guān)系。
在 REST 架構(gòu)中，方法和端點(diǎn)的每個組合得到不同的封裝功能。如果客戶端需要的數(shù)據(jù)特定端點(diǎn) / 方法不提供，則可能需要額外請求。從 REST 請求返回的數(shù)據(jù)格式依賴于端點(diǎn)—不能保證這些數(shù)據(jù)會按照前端需要的方式進(jìn)行格式化。為使用來自響應(yīng)的數(shù)據(jù)（格式與缺省情況下從端點(diǎn)返回的格式不同），必須在客戶端編寫數(shù)據(jù)解析和數(shù)據(jù)操作。
接下來，讓我們看看 GraphQL 規(guī)范與 REST 的不同之處，以及它的優(yōu)點(diǎn)。這些優(yōu)點(diǎn)使這個新架構(gòu)成為特別適合解決客戶端和服務(wù)器之間數(shù)據(jù)交付問題的解決方案。
4 GraphQL 架構(gòu)
與 RESTful API 一樣，GraphQL API 設(shè)計用于處理 HTTP 請求并對這些請求提供響應(yīng)。無論如何，這就是相似之處。REST API 構(gòu)建在請求方法和端點(diǎn)之間的連接上，而 GraphQL API 被設(shè)計為只通過一個端點(diǎn)，始終使用 POST 請求進(jìn)行查詢，其 URL 通常是 yourdomain.com/graphql。
請求到達(dá) GraphQL 端點(diǎn)后，客戶端請求的載荷完全在請求體中處理。這個請求體必須遵循 GraphQL 規(guī)范，API 必須有適當(dāng)?shù)姆?wù)器端邏輯來處理這些請求并提供適當(dāng)?shù)捻憫?yīng)。
這提供了比 RESTful API 更流暢的客戶端體驗(yàn)，后者可能要求客戶端針對多個數(shù)據(jù)塊發(fā)出多個請求，并在數(shù)據(jù)返回后進(jìn)行操作。
為了闡明 GraphQL 是如何實(shí)現(xiàn)這一點(diǎn)的，讓我們分解一下 GraphQL 服務(wù)器的結(jié)構(gòu)。
5 GraphQL 服務(wù)器
啟用 GraphQL 邏輯的服務(wù)器端邏輯由定義了服務(wù)器功能的 Documents 組成。這些 Documents 包含可執(zhí)行文件和類型系統(tǒng)定義。顧名思義，類型系統(tǒng)定義為每個數(shù)據(jù)字段定義可接受的類型和格式輸入及結(jié)果。
可執(zhí)行文件包含要處理的可能的操作列表，其中包括操作類型（查詢、修改或訂閱）、操作名稱、要查詢或?qū)懭氲淖侄魏鸵粋€選擇集，該選擇集準(zhǔn)確定義了將從操作返回的數(shù)據(jù)。選擇集是 GraphQL 的最大價值所在——它們允許客戶端查詢特定的數(shù)據(jù)集并接收包含所請求信息的響應(yīng)：不多不少。
- GET /graphql?query={ books(id:12) { authors { firstName, lastName } title, yearPublished, length }
- {
- Query { // operation type
- books (id:12) { // operation endpoint
- authors { // requested fields
- firstName
- lastName
- }
- title
- yearPublished
- }
- }
- }
接下來，我們將看下 GraphQL 中查詢的結(jié)構(gòu)。
6 GraphQL 查詢解析
下面是一個結(jié)構(gòu)化的 GraphQL 查詢，用于獲取特定書籍的數(shù)據(jù)，包括作者的姓和名
- GET /graphql?query={ books(id:12) { authors { firstName, lastName } title, yearPublished, length }
- {
- Query { // operation type
- books (id:12) { // operation endpoint
- authors { // requested fields
- firstName
- lastName
- }
- title
- yearPublished
- }
- }
- }
這一切都可以通過一個查詢由 GraphQL 服務(wù)器邏輯解析和處理完成。當(dāng)把它與 REST 架構(gòu)中相同結(jié)構(gòu)的請求進(jìn)行比較時，GraphQL 的優(yōu)勢就開始顯現(xiàn)出來了。
讓我們看看下面的 REST 請求結(jié)構(gòu)，然后重點(diǎn)討論其中的一些差異！
7 REST 請求解析
要向 REST API 發(fā)出相同的請求，客戶端首先需要向能夠返回圖書數(shù)據(jù)的端點(diǎn)發(fā)送一個請求，并將圖書 id 作為參數(shù)傳入：
- GET /books/12
這個請求可能會返回一個包含特定圖書所有數(shù)據(jù)的對象，例如：
- {
- "title" : "The Hitchhiker's Guide to the Galaxy",
- "authorID": 42,
- "yearPublished" : 1978,
- "length": 208,
- "genre": "Science Fiction"
- }
在我 們的例子里，與相同的 GraphQL 查詢相比，該響應(yīng)有兩個缺點(diǎn)：
-
REST 響應(yīng)包含類似 genre 這樣的額外數(shù)據(jù)，返回的信息超出了我們的需求。
-
REST 需要再發(fā)送一個請求來獲得我們實(shí)際上正在查找的數(shù)據(jù)：這個特定作者的所有書籍。
為了獲得這些數(shù)據(jù)，我們需要使用我們的 authorID 發(fā)出一個額外的請求：
- GET /authors/42
這個請求的響應(yīng)應(yīng)該包含我們正在查找的所有數(shù)據(jù)：
- {
- "firstName": "Douglas",
- "lastName": "Adams"
- }
現(xiàn)在我們已經(jīng)有了需要的所有書籍和作者數(shù)據(jù)，響應(yīng)解析由客戶端完成?，F(xiàn)在，前端應(yīng)用程序必須將來自不同端點(diǎn)的數(shù)據(jù)組合在一起，用于實(shí)現(xiàn)期望的功能?？偟膩碚f，與 REST API 相比，GraphQL 提供的性能優(yōu)勢可以為前端開發(fā)人員帶來回報。使用 GraphQL 規(guī)范創(chuàng)建服務(wù)器可能需要更多的設(shè)置以及編寫預(yù)測性的服務(wù)器端邏輯來解析和處理請求。
雖然 GraphQL 的設(shè)置成本可能比傳統(tǒng)的 REST 架構(gòu)要高，但是，更易于維護(hù)的代碼、健壯的開發(fā)工具和精簡的客戶端查詢所帶來的好處通常會超過成本。
