REST和GraphQL是構(gòu)建網(wǎng)站API的兩種規(guī)範(fàn)。 REST定義了一系列唯一的標(biāo)識(shí)符（URL），應(yīng)用程序使用這些標(biāo)識(shí)符來請求和發(fā)送數(shù)據(jù)。 GraphQL定義了一種查詢語言，允許客戶端應(yīng)用程序精確指定他們需要從單個(gè)端點(diǎn)獲取的數(shù)據(jù)。它們是相關(guān)的技術(shù)，用於大致相同的事情（事實(shí)上，它們可以並且經(jīng)常共存），但它們也截然不同。

讓我們用一種更有趣的方式來解釋它，這可能有助於你更好地理解，並可能讓你對GraphQL有點(diǎn)興奮！

? 你在一個(gè)雞尾酒會(huì)上

你參加這個(gè)酒會(huì)是為了拓展你的職業(yè)人脈，所以自然地，你想要收集一些關(guān)於你周圍人的數(shù)據(jù)。附近有五位其他與會(huì)者。

他們的名牌上寫著：

• Richy REST
• Richy REST的朋友
• Richy REST的雇主
• Georgia GraphQL

作為你充滿活力、社交、外向的本性，你徑直走到Richy REST面前說：“你好，我是Adam Application，你是誰？”Richy REST回答：

 <code>{ name: "Richy REST", age: 33, married: false, hometown: "Circuits-ville", employed: true // ... Richy REST的其他20條信息}</code>

“哇，這信息太多了，”你心裡想著。為了避免任何尷尬的沉默，你記得Richy REST提到他被雇傭了，於是問道：“你在哪里工作？”

奇怪的是，Richy REST不知道他在哪里工作。也許Richy REST的雇主知道？

你向Richy REST的雇主問了同樣的問題，他很樂意回答你的詢問！他這樣回答：

 <code>{ company: "Mega Corp", employee_count: 11230, head_quarters: "1 Main Avenue, Big City, 10001, PL" year_founded: 2005, revenue: 100000000, // ... Richy REST雇主的其他20條信息}</code>

這時(shí)，你精疲力盡了。你甚至不想見Richy REST的朋友！那可能要花很長時(shí)間，耗盡你所有的精力，而且你沒有時(shí)間。

然而，Georgia GraphQL一直禮貌地站在那裡，所以你決定和她交流。

“你好，你叫什麼名字？”

 <code>{ name: "Georgia GraphQL" }</code>

“你來自哪裡，你多大了？”*

 <code>{ hometown: "Pleasant-Ville", age: 28 }</code>

“你有多少愛好和朋友，你的朋友的名字是什麼？”

 <code>{ hobbies_count: 12, friends_count: 50, friends: [ { name: "Steve" }, { name: "Anjalla" }, // ...等等] }</code>

Georgia GraphQL太棒了，清晰、簡潔、切中要害。你100%想和她交換名片，並在未來的項(xiàng)目中和她一起合作。

這個(gè)故事概括了開發(fā)人員使用GraphQL而不是REST的經(jīng)驗(yàn)。 GraphQL允許開發(fā)人員用簡潔的查詢表達(dá)他們的需求，並且只接收他們指定的內(nèi)容——不多也不少。這些查詢是完全動(dòng)態(tài)的，因此只需要一個(gè)端點(diǎn)。另一方面，REST具有預(yù)定義的響應(yīng)，並且通常需要應(yīng)用程序使用多個(gè)端點(diǎn)來滿足完整的資料需求。

隱喻結(jié)束！讓我們談?wù)勚攸c(diǎn)。

為了進(jìn)一步闡述在雞尾酒會(huì)隱喻中提出的基本概念，讓我們具體討論使用REST時(shí)經(jīng)常出現(xiàn)的兩個(gè)限制。

1. 獲取相關(guān)資源時(shí)需要多次請求

數(shù)據(jù)驅(qū)動(dòng)的移動(dòng)和Web應(yīng)用程序通常需要相關(guān)的資源和數(shù)據(jù)集。因此，使用REST API檢索數(shù)據(jù)可能需要向多個(gè)端點(diǎn)發(fā)出多個(gè)請求。例如，請求Post實(shí)體和相關(guān)的作者可能需要向不同的端點(diǎn)發(fā)出兩個(gè)請求：

 <code>someServer.com/authors/:id someServer.com/posts/:id</code>

多次訪問API會(huì)影響應(yīng)用程序的性能和可用性。對於低帶寬設(shè)備（例如智能手錶、物聯(lián)網(wǎng)、舊款移動(dòng)設(shè)備等）來說，這也是一個(gè)更重要的問題。

2. 數(shù)據(jù)過度獲取和不足獲取

使用RESTful API時(shí)，數(shù)據(jù)過度獲取和不足獲取是不可避免的。使用上面的例子，端點(diǎn)domainName.com/posts/:id獲取特定Post的數(shù)據(jù)。每個(gè)Post都由屬性組成，例如id、body、title、publishingDate、authorId等。在REST中，總是返回相同的數(shù)據(jù)對象；響應(yīng)是預(yù)定義的。

在只需要Post標(biāo)題和正文的情況下，會(huì)發(fā)生數(shù)據(jù)過度獲取——因?yàn)榘l(fā)送到網(wǎng)絡(luò)上的數(shù)據(jù)比實(shí)際使用的數(shù)據(jù)多。當(dāng)需要整個(gè)Post及其作者的相關(guān)數(shù)據(jù)時(shí)，就會(huì)發(fā)生數(shù)據(jù)不足獲取——因?yàn)榘l(fā)送到網(wǎng)絡(luò)上的數(shù)據(jù)比實(shí)際使用的數(shù)據(jù)少。數(shù)據(jù)不足獲取會(huì)導(dǎo)致由於對API的多次請求而過度使用帶寬。

使用GraphQL進(jìn)行客戶端查詢

GraphQL引入了一種真正獨(dú)特的方法，為客戶端應(yīng)用程序提供了極大的靈活性。使用GraphQL，查詢被發(fā)送到你的API，並且只返回你所需的內(nèi)容——不多也不少——在一個(gè)請求中。查詢結(jié)果以與你的查詢相同的形狀返回，確保響應(yīng)結(jié)構(gòu)始終可預(yù)測。這些因素允許應(yīng)用程序運(yùn)行得更快、更穩(wěn)定，因?yàn)?em>它們可以控制它們獲取的數(shù)據(jù)，而不是服務(wù)器。

“結(jié)果以與查詢相同的形狀返回?！?/h3>

 <code>/* 查詢*/ { myFriends(first: 2) { items { name age } } }</code>

 <code>/* 響應(yīng)*/ { "data": { "items": [ { "name": "Steve", "age": 27 }, { "name": "Kelly", "age": 31 } ] } }</code>

現(xiàn)實(shí)檢驗(yàn)?

現(xiàn)在，你可能認(rèn)為GraphQL像用武士刀切熱黃油一樣容易。對於前端開發(fā)人員來說，這可能是現(xiàn)實(shí)——特別是那些使用GraphQL API的開發(fā)人員。然而，當(dāng)涉及到服務(wù)器端設(shè)置時(shí)，有人必須製作香腸。我們的朋友Georgia GraphQL付出了很多努力才成為她現(xiàn)在如此出色的專業(yè)人士！

構(gòu)建GraphQL API（服務(wù)器端）需要時(shí)間、精力和專業(yè)知識(shí)。也就是說，對於那些準(zhǔn)備好迎接挑戰(zhàn)的人來說，這並不是什麼無法處理的事情！有很多不同的方法可以在所有抽象級別上參與其中。例如：

• 無輔助:如果你真的想親自動(dòng)手，可以藉助軟件包來構(gòu)建GraphQL API。例如，喜歡Rails？查看graphql-ruby。喜歡Node.js？試試express-graphql。
• 輔助:如果完全維護(hù)你的服務(wù)器/自託管是一個(gè)優(yōu)先事項(xiàng)，像Graph.cool這樣的東西可以幫助你開始一個(gè)GraphQL項(xiàng)目。
• 即時(shí):厭倦了編寫CRUD樣板代碼，想要快速上手？ 8base提供了一個(gè)即時(shí)的GraphQL API和無服務(wù)器後端，它是完全可擴(kuò)展的。

總結(jié)

REST通過啟用高度可用的資源特定API，為Web服務(wù)帶來了巨大的進(jìn)步。也就是說，它的設(shè)計(jì)並沒有考慮到當(dāng)今互聯(lián)設(shè)備的激增，所有這些設(shè)備都有不同的數(shù)據(jù)限制和要求。這種疏忽很快導(dǎo)致了GraphQL（Facebook於2015年開源）的普及，因?yàn)樗鼮榍岸碎_發(fā)人員提供了巨大的靈活性。使用GraphQL是一種很棒的開發(fā)體驗(yàn)，對於個(gè)人開發(fā)人員和團(tuán)隊(duì)都是如此。

以上是在雞尾酒攪拌機(jī)上見GraphQL的詳細(xì)內(nèi)容。更多資訊請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！