晚上，RESTful發(fā)明人羅伊悄悄來到了咖啡館，他想看看自己引以為傲的RESTful到底用得怎么樣。

(RESTful的故事參見《RPC發(fā)展簡史》)

靠著門的那張桌子有一幫人，他們居然還在討論老掉牙的Java RMI，似乎遇到了什么技術(shù)難題。

看來無論是什么技術(shù)，都會有非常古老的遺留系統(tǒng)需要維護，真是苦逼的程序員啊， 羅伊感慨。

這邊的一群人在討論Google的Protobuf ， 看來在序列化這一塊兒已經(jīng)有了長足的進展，都可以實現(xiàn)跨語言序列化了。

再往里邊走，終于有人討論RESTful了! 羅伊心中一陣激動。

只聽到一個人說道：“我們領(lǐng)導(dǎo)剛開始強制用RESTful的面向資源的風(fēng)格，大家還挺新奇的，可是用著用著，我們就‘退回’到那種面向函數(shù)的方式了。”

“是啊是啊，我還是更習(xí)慣傳統(tǒng)的RPC方式，更加直觀，尤其是用了Dubbo以后，面向函數(shù)的風(fēng)格不要太爽。”

羅伊心中有點失望。

RESTful的硬傷

“其實吧，RESTful有個硬傷，你們發(fā)現(xiàn)沒有?” 有個叫做格拉夫的人突然來了一句。

“什么硬傷?”

“我給你們舉個例子，” 格拉夫說道，“比如我有兩個資源，一個叫做Article ，一個叫做User。”

 

“這很正常啊，對資源可以增刪改查。” 羅伊說道，他的話也引起了周圍人的附和。

“聽我說完，我現(xiàn)在要開發(fā)一個手機端，要展示一個文章的列表，假設(shè)界面原型是這個樣子：”

 

“***步，我需要獲得這些文章列表，可以這么做 GET /articles ”

 

“這也沒問題啊!不就是一個普通的獲取資源表示的方式嗎?” 人群中有人說道。

可是羅伊敏銳地發(fā)現(xiàn)，界面中需要一個“作者頭像”， 很明顯，這個作者頭像并不在Article這個資源中保存， 而是在User中。

在返回的結(jié)果中只有author_id， 如果想要獲得作者頭像，需要對返回的文章列表做循環(huán)，取出author_id ，然后在通過/users這個資源進行查詢。

 

當(dāng)羅伊把這個查詢展示出來以后，周圍人群就炸了鍋：“有多少個文章，就額外發(fā)出多少次查詢，這怎么行?! 實際中肯定不能這么干!”

還有人說：“我們僅僅需要頭像信息(avatar_url)，你返回這么多亂七八糟的gender, age,last_login_time干嘛! ”

“這RESTful真是糟糕啊!”

羅伊有點尬尷，沒想到我的RESTful會存在這么兩個問題：

1. 發(fā)送請求過多 (對每個文章，都得額外查詢作者信息)

2. 太多的額外信息(其實只想要avatar_url這個字段)

想到此處，羅伊的心一下子就沉了下去，怎么解決這個問題呢?

中間層

老祖宗教導(dǎo)我們： 計算機科學(xué)領(lǐng)域的任何問題都可以通過增加一個間接的中間層來解決!

這個中間層是什么? 羅伊想到了前后端還沒有分離的時候，頁面都是在后端渲染的，程序員會創(chuàng)建一個VO(View Object)，在這個VO中，會把界面展示所需要的信息都封裝起來，然后再發(fā)給JSP去使用。

在RESTful當(dāng)中，也可以搞一個類似VO的資源出來啊， 想到此處，他對格拉夫說道：“你為什么不搞一個HotArticle這樣的資源出來呢? ”

 

這個HotArticle可以把文章和作者做個組合，只返回那些界面需要的數(shù)據(jù)。

格拉夫說道：“這樣可不好， 這個HotArticle資源相當(dāng)于和界面深度綁定了。界面如果要變化，這個HotArticle也得變化，很麻煩啊。”

羅伊說：“那就一起變化唄，反正兩個是一致的。”

“不，還有更復(fù)雜的情況， 假設(shè)界面發(fā)生了變化，需要把作者頭像替換成文章的封面圖， 這時候怎么辦呢?”

羅伊說：“我明白你的意思，不就是說要同時支持老的手機端和新的手機端嗎?簡單，有兩種方案。”

(1) 復(fù)用HotArticle， 保留原來的avatar_url， 添加一個新的字段 article_img_url， 不同的手機端各取所需。

(2) 給HotArticle做個新版本。老的手機端用老版本，新的手機端用新版本。

“***種方案好!很簡單!” 人群中有人說道。

“好啥啊，如果手機界面持續(xù)變化，你用***種辦法，那個HotArticle很快就成了垃圾堆了，要是沒有準(zhǔn)確無誤的文檔，都不知道哪個字段被誰使用!”

“第二種方案會搞出很多版本來，假設(shè)要改個公共的東西，比如要增加一個文章的閱讀數(shù)，那豈不是所有的都得改? ”

可見兩種辦法各有優(yōu)劣， 在應(yīng)對手機端界面持續(xù)變化時都有問題，都不***。這也是后端資源和前端界面綁定后的惡果啊。

靈活查詢

羅伊陷入了沉思： 能不能讓手機端按需查詢呢?

服務(wù)器端保持最簡單的Article 和 User的概念，把他們看成兩張表，手機端發(fā)出像SQL 那樣的查詢，把自己需要的給查出來，***能類似于Join的功能。

想到此處，他就寫了這么一個SQL :

select a.id, a.title, a.abstract, a.liked_count, u.avatar_url from Article a , User u where a.author_id = u.id

 

看到這個圖，人群轟然叫好：“還是SQL大法好!”

只有格拉夫冷冷地說道：“SQL的局限性太大， 比如我還要把作者的朋友同時顯示到手機端，這SQL就不好寫了，文章和作者是一一對應(yīng)的，但是作者的朋友可能有多個，這樣SQL的結(jié)果集中就會有重復(fù)的文章id , title , abstract了。”

羅伊說：“那你說怎么辦?”

“關(guān)系模型在表示這樣的關(guān)聯(lián)的時候，非常不方便，我發(fā)明了一個新的模型和新的查詢語言， 大家看看吧。”

古怪的查詢

格拉夫展示了一個查詢的方法：

 

大家猛地一看， 這個查詢太古怪了啊，這是什么語法?

雖然古怪，卻非常實用，精確地描述了這個需求：我需要一個id 為11的用戶， 把他的name, age, avatar_url等字段給我取過來，其他字段就不用發(fā)過來了。

查詢結(jié)果也是標(biāo)準(zhǔn)的JSON格式，和要查詢的內(nèi)容一一對應(yīng)，非常容易理解。

羅伊問道：“這也沒啥啊，你怎么解決之前的問題?”

格拉夫又展示了一個查詢，這一次復(fù)雜了一些：

 

“看到?jīng)]有? 這次表示一個article列表，每個article元素里邊有id, title, abstract，liked_count等字段。 還有一個特殊字段叫做author，相當(dāng)于在article中嵌套了一個元素，這個author元素還有一個字段叫做avatar_url。 ”

眾人一看，覺得非常有意思，用這種方式***地解決了之前的問題。

只需要一次查詢，文章和作者的頭像一起就發(fā)回來了，更重要的是，沒有什么亂七八糟的額外信息。

如果想加上作者的朋友信息，可以把查詢改成下面這個樣子，非常靈活。

 

看到此處，羅伊就明白了幾分，這是一種新的查詢方式，不同于關(guān)系數(shù)據(jù)庫的SQL， 也不同于RESTful， 很明顯，后端的數(shù)據(jù)模型也得發(fā)生變化。

他問道：“你后端的數(shù)據(jù)模型難道是圖Graph嗎?”

格拉夫贊道：“被你看出來了，真是厲害，為了支持這樣的查詢，在后臺的數(shù)據(jù)模型就是一張圖：”

 

“根據(jù)這張圖，我就可以查找出任意的數(shù)據(jù)了，從Article找到作者， 從作者找到相關(guān)的朋友......， 只要你把關(guān)聯(lián)做好，沒有什么做不到的。”

“那些Article, User類型及其屬性是不是也得明確地定義下來?” 羅伊又問道。

格拉夫?qū)α_伊投去贊嘆的目光， 說道：“沒錯，可以這么定義。”

 

一目了然，大家都非常喜歡!

“這個新的查詢語言叫什么名字?”

“我叫格拉夫(Graph)，所以這個查詢語言叫做GraphQL!”

【本文為51CTO專欄作者“劉欣”的原創(chuàng)稿件，轉(zhuǎn)載請通過作者微信公眾號coderising獲取授權(quán)】

 

戳這里，看該作者更多好文