7月安卓手機(jī)好評(píng)榜：三星S23Ultra好評(píng)率第一
性能榜和性價(jià)比榜之后，我們來看最后的安卓手機(jī)好評(píng)榜，數(shù)據(jù)來源安兔兔評(píng)測(cè)，收集時(shí)間2023年7月1日至7月31日，僅限國(guó)內(nèi)市場(chǎng)。第一名：三星Galaxy S23 Ultra好評(píng)率：95.71%在即將迎來新
在本文中，簡(jiǎn)單比較 REST 和 GraphQL 的優(yōu)點(diǎn)和缺點(diǎn)，以便您可以決定哪種 API 架構(gòu)最適合您的項(xiàng)目
當(dāng)我們要?jiǎng)?chuàng)建數(shù)據(jù)驅(qū)動(dòng)的 Web 或移動(dòng)應(yīng)用程序，需要開發(fā)后臺(tái) API，通過它可以從后端服務(wù)器來訪問或操作數(shù)據(jù)。目前最流行的 API 架構(gòu)是 REST，盡管 REST 廣為人知并且通常易于使用，但它也有一些缺點(diǎn)，主要是包括冗余數(shù)據(jù)的過度獲取、擴(kuò)展效率低下。
GraphQL 是一種新型 API 架構(gòu)，其設(shè)計(jì)比 REST 更靈活、更高效，具有聲明式數(shù)據(jù)獲取等功能。雖然 GraphQL 已經(jīng)變得相當(dāng)流行，但它并沒有取代 REST，因?yàn)橐恍┯脩舭l(fā)現(xiàn)它更難使用，并認(rèn)為它是一個(gè)過度設(shè)計(jì)的解決方案，特別是對(duì)于較小的應(yīng)用程序來說。
在本文中，將深入探討 REST 和 GraphQL 的優(yōu)缺點(diǎn)，以便您可以決定哪種 API 架構(gòu)最適合您的項(xiàng)目。
當(dāng)前應(yīng)用程序開發(fā)中 API 的主流架構(gòu)是 REST，大多數(shù)后端框架將實(shí)現(xiàn) REST。REST API 通常使用 HTTP 方法通過稱為（例如GET /api/articles ）的 URL 集合進(jìn)行調(diào)用POST /api/articles。
以創(chuàng)建一個(gè)博客網(wǎng)站為例。在主頁(yè)上，顯示最新文章的摘要，包括標(biāo)題、圖像和簡(jiǎn)短說明。要為此提供數(shù)據(jù)，需要在后端服務(wù)器上設(shè)置一個(gè) REST API，GET/api/articles它將以 JSON 數(shù)組的形式返回所需的數(shù)據(jù)，如下例所示：
// GET /articles[ { "id": 1, "title": "REST is Awesome", "image": "https://myrestblog.com/img/dsh9a89.png", "description": "The benefits of REST" }, { "id": 2, "title": "How REST Works", "image": "https://myrestblog.com/img/33szad2.png", "description": "Learn about REST" }]REST 在很大程度上擊敗了 SOAP、WebService、XML 等較舊的 API 協(xié)議，并且盡管出現(xiàn)了 GraphQL 等較新的替代方案，但仍繼續(xù)流行，其主要原因?yàn)椋?/span>
在 Web 服務(wù)器應(yīng)用程序中設(shè)置 REST 很簡(jiǎn)單，尤其是當(dāng)它使用 Java的 Springcloud或 Python 的 Requests 等 API 框架時(shí)。例如，使用 MongoDB 在 Express 應(yīng)用程序中設(shè)置 REST 端點(diǎn)/articles就像調(diào)用數(shù)據(jù)庫(kù)并將記錄返回為 JSON 一樣簡(jiǎn)單，如下所示：
python：
app.get('/api/articles', async (req, res) => { try { const articles = await db.articles.find() res.json(articles) } catch (err) { res.status(500).send(err) }})無論 GraphQL 是否優(yōu)于 REST，大多數(shù)開發(fā)人員都會(huì)同意，當(dāng)您使用自己所知道的知識(shí)時(shí)，開發(fā)效率會(huì)更高。截至 2022 年，如果您有多個(gè)開發(fā)人員在開發(fā)您的應(yīng)用程序，或者您有公共 API，則大多數(shù)消費(fèi)者將熟悉 REST，GraphQL 還不能說同樣的情況，哈哈~~。
要理解為什么創(chuàng)建 GraphQL，我們需要首先看看 REST 的缺點(diǎn)
回到博客的示例，假設(shè)創(chuàng)建了一個(gè)移動(dòng)網(wǎng)站。與桌面版本一樣，在主頁(yè)上顯示文章摘要。由于手機(jī)屏幕較小，這里的摘要只需要標(biāo)題和圖片，可以省略描述。不幸的是，由于GET /api/articles端點(diǎn)是固定的，移動(dòng)版本description在調(diào)用 API 時(shí)仍然會(huì)收到該字段。這種低效率被稱為“過度獲取”，并且在發(fā)送大量數(shù)據(jù)時(shí)會(huì)成為挑戰(zhàn)。
當(dāng)對(duì)象包含表示相關(guān)實(shí)體的子對(duì)象時(shí)，該對(duì)象具有嵌套數(shù)據(jù)。例如，可能有一個(gè)帶有嵌套評(píng)論對(duì)象的文章對(duì)象。由于實(shí)體在 REST 中被分配了自己唯一的URL，因此可能需要通過單獨(dú)的 API 往返來填充嵌套數(shù)據(jù)。
例如，要獲取一篇文章，我們首先使用端點(diǎn)GET /api/articles。要獲取本文的評(píng)論，我們需要首先等待文章數(shù)據(jù)填充，以便我們知道在后續(xù)請(qǐng)求中需要獲取哪些特定評(píng)論，如下面的代碼示例所示。等待這些后續(xù)請(qǐng)求得到解決將增加用戶在與頁(yè)面交互之前必須等待的時(shí)間。
// GET /articles[ { "id": 1, "title": "REST is Awesome", "image": "https://myrestblog.com/img/dsh9a89.png", "description": "An article about REST", "comment_ids": [ 10, 14, 22 ] }, { ... }]REST 的低效率促使 Facebook 工程師在 2015 年創(chuàng)建了一種新的 API 設(shè)計(jì)，稱為 GraphQL。GraphQL 迅速成為開發(fā)人員和公司的熱門選擇，推出了相關(guān)工具和服務(wù)的生態(tài)系統(tǒng)。與 REST 一樣，GraphQL 不是一個(gè)特定的軟件，而是 API 設(shè)計(jì)的規(guī)范。
為了了解 GraphQL 的優(yōu)勢(shì)，快速概述它的工作原理。與 REST 不同，GraphQL 需要一個(gè)架構(gòu)來告訴客戶端和服務(wù)器允許通過 API 執(zhí)行哪些數(shù)據(jù)和操作。它們是使用 GraphQL 模式語言定義的——一種與語言無關(guān)的簡(jiǎn)單格式，具有強(qiáng)大的類型系統(tǒng)。
Article讓我們回到具有和實(shí)體的博客網(wǎng)站的示例Comment。在我們的 GraphQL 模式中，我們定義Article具有必需的整數(shù)id字段和title、image、 和的可選字符串字段的類型description，如下所示：
type Article { id: Integer! title: String image: String description: String}除了基本標(biāo)量類型之外，模式對(duì)象還可以相互引用。Article例如，我們可以在類型和類型之間創(chuàng)建一對(duì)多關(guān)系Comment，如下所示：
type Article { id: Integer! title: String image: String description: String comments: [Comment]}type Comment { content: String article: Article author: Author}GraphQL 模式的另一個(gè)重要用途是定義操作，其中包括讀取數(shù)據(jù)的查詢和寫入數(shù)據(jù)的突變。在這里，我們提供了 的查詢Articles，其類型為文章數(shù)組：
type Article { id: Integer! title: String image: String description: String comments: [Comment]}type Comment { content: String article: Article author: Author}type Query { articles: [Article]}通過對(duì) GraphQL 的基本了解，我們現(xiàn)在可以了解它的主要優(yōu)點(diǎn)。
GraphQL 的殺手級(jí)功能是聲明式數(shù)據(jù)獲取，客戶端可以準(zhǔn)確指定其需要的數(shù)據(jù)。這可以包括特定字段，甚至在嵌套對(duì)象內(nèi)。我們之前看到，操作必須在模式上定義。不過，在這些操作中，我們可以指定希望查詢返回哪些字段（最多達(dá)到架構(gòu)的限制）。
例如，我們可以創(chuàng)建一個(gè)查詢來Articles僅獲取我們想要的字段，無論是否有嵌套Comments。請(qǐng)參閱下面的示例：
query { articles { id title image description comments { content } }}這是將從該查詢返回的數(shù)據(jù)結(jié)構(gòu)。請(qǐng)注意，GraphQL 響應(yīng)中收到的數(shù)據(jù)將與請(qǐng)求它的查詢具有相同的形狀。
{ "data": { "articles": [ { "id": 1, "title": "REST is Awesome", "image": "https://restblog.com/img/dsh9a8.png", "description": "An article about REST", "comments": [ { "content": "GraphQL is better!" }, { ... } ] } ], ... }}通過這種方式，GraphQL 消除了過度獲取和對(duì)嵌套數(shù)據(jù)的順序調(diào)用的需要。
由于強(qiáng)類型化和預(yù)定義查詢的要求，GraphQL 可以提供開箱即用的驗(yàn)證和類型檢查。反過來，這意味著 GraphQL 本質(zhì)上是自記錄的。一旦字段、類型或查詢發(fā)生變化，基于模式的文檔就可以自動(dòng)更新。
每次應(yīng)用程序發(fā)生變化時(shí)，API 也可能需要更改。例如，假設(shè)我們決定將實(shí)體description中的字段重命名Article為blurb. REST 通過提供多個(gè)版本來處理這個(gè)問題，例如/api/v1，api/v2這對(duì)于 API 開發(fā)人員和消費(fèi)者來說都是很麻煩的。使用 GraphQL，可以從架構(gòu)中刪除已棄用的字段，而不會(huì)影響現(xiàn)有查詢。這為應(yīng)用程序提供了對(duì)新功能的持續(xù)訪問，并鼓勵(lì)更清潔、更易于維護(hù)的服務(wù)器代碼。
雖然 GraphQL 為 REST 的缺點(diǎn)提供了一個(gè)優(yōu)雅的解決方案，但請(qǐng)考慮一下 GraphQL 面臨的一些批評(píng)。
一些開發(fā)人員認(rèn)為 GraphQL 正在解決的問題常常被夸大了。例如，對(duì)于大多數(shù)小型應(yīng)用程序來說，如果過度獲取的幾個(gè)字節(jié)的數(shù)據(jù)進(jìn)入有效負(fù)載，這可能并不重要。
另一個(gè)批評(píng)是 GraphQL 實(shí)現(xiàn)最終比 REST 更難編碼，它還為新用戶提供了更困難的學(xué)習(xí)曲線。
最后，GraphQL 經(jīng)常因更難以緩存而受到批評(píng)，REST 客戶端可以獲得 HTTP 緩存的好處，因?yàn)樗卸它c(diǎn)都是 URL，而 GraphQL 客戶端需要實(shí)現(xiàn)自己的自定義解決方案，如使用本地緩存，譬如redux-persit、localforage
雖然 REST 架構(gòu)在過去十年中主導(dǎo)了 Web 開發(fā)，但它對(duì)設(shè)置端點(diǎn)的使用使其有些不靈活且低效。GraphQL 通過提供嚴(yán)格類型的模式語言來解決這些問題，消費(fèi)者可以根據(jù)需要進(jìn)行查詢。
本文鏈接：http://www.www897cc.com/showinfo-26-19015-0.html如何選擇 REST 還是 GraphQL
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)