RESTとGRAPHQLは、WebサイトAPIを構(gòu)築するための2つの仕様です。 RESTは、アプリケーションがデータを要求して送信するために使用する一連の一意の識(shí)別子（URL）を定義します。 GraphQLは、クライアントアプリケーションが単一のエンドポイントから取得するために必要なデータを正確に指定できるようにするクエリ言語(yǔ)を定義します。それらは、ほぼ同じことのための関連手法です（実際、彼らは共存することができ、しばしば共存することができます）が、それらも非常に異なっています。

それをより興味深い方法で説明しましょう。これは、あなたがよりよく理解するのに役立ち、GraphQLについて少し興奮するかもしれません！

？あなたはカクテルパーティーにいます

このカクテルパーティーに參加して専門(mén)家のつながりを拡大するので、當(dāng)然、周?chē)欷稳恕─碎vするデータを収集したいと考えています。近くには他に5人の參加者がいました。

彼らの名前タグは言う：

• リッチな休息
• リッチーレストの友達(dá)
• Richy Restの雇用主
• ジョージアGraphQl

あなたのエネルギッシュで、社會(huì)的で、外向的な性質(zhì)として、あなたはまっすぐにリッチな休息に向かって歩き、「こんにちは、私はアダムアプリケーションです、あなたは誰(shuí)ですか？」と言いました。リッチー?レストは答えた：

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

「うわー、たくさんの情報(bào)があります」とあなたは自分自身に考えました。厄介な沈黙を避けるために、あなたは彼が雇われ、「どこで働いているの？」と尋ねたリッチー?レストが言及したことを覚えています。

奇妙なことに、Richy Restは彼がどこで働いているのかわかりません。多分リッチー?レストの雇用主は知っていますか？

あなたはRichy Restの雇用主に同じ質(zhì)問(wèn)をしました、そして彼はあなたの問(wèn)い合わせに喜んで答えてくれます！彼はこのように答えました：

 <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í)點(diǎn)で、あなたは疲れています。あなたはリッチー?レストの友達(dá)に會(huì)いたくありません！それには長(zhǎng)い時(shí)間がかかり、すべてのエネルギーを排出し、時(shí)間がありません。

しかし、ジョージアのグラフクルは丁寧にそこに立っているので、あなたは彼女とコミュニケーションをとることにしました。

「こんにちは、あなたの名前は何ですか？」

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

「どこから來(lái)たの、何歳ですか？」*

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

「趣味や友達(dá)はいくつありますか、友達(dá)の名前は何ですか？」

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

Georgia GraphQLは素晴らしく、明確で、簡(jiǎn)潔で、要點(diǎn)です。あなたは彼女と名刺を交換し、將來(lái)のプロジェクトで彼女と協(xié)力したいと考えています。

このストーリーは、休息の代わりにGraphQLを使用する開(kāi)発者の経験を要約しています。 GraphQLを使用すると、開(kāi)発者は簡(jiǎn)潔なクエリでニーズを表現(xiàn)し、指定したコンテンツのみを受け取ることができます。これらのクエリは完全に動(dòng)的であるため、1つのエンドポイントのみが必要です。一方、RESTには事前定義された応答があり、多くの場(chǎng)合、完全なデータニーズを満たすために複數(shù)のエンドポイントを使用するためにアプリケーションが必要です。

比phorは終わります！重要なポイントについて話しましょう。

カクテルパーティーのメタファーで提案されている基本的な概念についてさらに詳しく説明するために、RESTを使用するときによく表示される2つの制限を詳細(xì)に説明しましょう。

1.関連するリソースを取得するときは、複數(shù)のリクエストが必要です

データ駆動(dòng)型のモバイルおよびWebアプリケーションは、多くの場(chǎng)合、関連するリソースとデータセットが必要です。したがって、REST APIを使用してデータを取得するには、複數(shù)のエンドポイントへの複數(shù)の要求が必要になる場(chǎng)合があります。たとえば、ポストエンティティと関連著者の要求は、異なるエンドポイントに2つのリクエストを発行する必要がある場(chǎng)合があります。

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

APIへの複數(shù)のアクセスは、アプリケーションのパフォーマンスと可用性に影響を與える可能性があります。これはまた、低帯域幅デバイス（スマートウォッチ、モノのインターネット、古いモバイルデバイスなど）にとってより重要な問(wèn)題です。

2。過(guò)剰な取得と不十分なデータ収集

RESTFUL APIを使用する場(chǎng)合、過(guò)度のフェッチと不十分なデータ収集は避けられません。上記の例を使用して、Endpoint domainname.com/posts/:IDは、特定の投稿のデータを取得します。各投稿は、ID、ボディ、タイトル、PublishingDate、Authoridなどの屬性で構(gòu)成されています。STRESでは、同じデータオブジェクトが常に返されます。応答は事前に定義されています。

ポストタイトルとボディのみが必要な場(chǎng)合、データの過(guò)剰なデータが発生します。これは、実際に使用されているよりも多くのデータがネットワークに送信されるためです。投稿全體に関連するデータとその著者が必要な場(chǎng)合、実際に使用されるよりも少ないデータがネットワークに送信されるため、不十分なデータ収集が発生します。データ収集が不十分な場(chǎng)合、APIへの複數(shù)の要求により、帯域幅の使用が過(guò)度に使用される可能性があります。

GraphQLを使用したクライアントクエリ

GraphQLは、クライアントアプリケーションに優(yōu)れた柔軟性を提供する真にユニークなアプローチを紹介します。 GraphQLを使用して、クエリはAPIに送信され、必要なもののみをリクエストで返します。クエリの結(jié)果はクエリと同じ形で返され、応答構(gòu)造が常に予測(cè)可能であることを保証します。これらの要因により、アプリケーションは、サーバーではなく、得られるデータを制御できるため、より速く、より安定して実行できます。

「結(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)実のテスト?

今、あなたはGraphQLがSamuraiナイフでホットバターを切るのと同じくらい簡(jiǎn)単だと思うかもしれません。フロントエンド開(kāi)発者の場(chǎng)合、これは現(xiàn)実かもしれません。特にGraphQL APIを使用する人です。ただし、サーバー側(cè)のセットアップに関しては、誰(shuí)かがソーセージを作らなければなりません。私たちの友人ジョージアグラフクルは、彼女が今いるような傑出した専門(mén)家になることに多くの努力を注いでいます！

GraphQL API（サーバー側(cè)）の構(gòu)築には、時(shí)間、労力、専門(mén)知識(shí)が必要です。とはいえ、それは挑戦に直面する準(zhǔn)備ができている人のために処理できないものではありません！すべてのレベルの抽象化に関與するには、さまざまな方法があります。例えば：

• ヘルパーなし：本當(dāng)に自分でやりたい場(chǎng)合は、ソフトウェアパッケージを使用してGraphQL APIを構(gòu)築できます。たとえば、Railsのように？ GraphQl-Rubyをご覧ください。 node.jsのように？ Express-GraphQlをお試しください。
• アシスタント：サーバー/自己ホスティングを完全に維持することが優(yōu)先事項(xiàng)である場(chǎng)合、graph.Coolのようなものは、GraphQLプロジェクトを開(kāi)始するのに役立ちます。
• Instant： Crud bulerplateコードを書(shū)くのにうんざりしていて、すぐに始めたいですか？ 8Baseは、インスタントグラフクルAPIとサーバーレスバックエンドを提供します。これは完全にスケーラブルです。

要約します

RESTは、非常に利用可能なリソース固有のAPIを可能にすることにより、Webサービスに大きな進(jìn)歩をもたらしました。つまり、今日の相互接続されたデバイスの急増を考慮せずに設(shè)計(jì)されています。これらには、データの制限と要件が異なります。この監(jiān)視は、フロントエンド開(kāi)発者に大きな柔軟性を提供するため、GraphQL（2015年にFacebookがF(xiàn)acebookによってオープンソースを供給した）の人気にすぐに人気をもたらしました。 GraphQLを使用することは、個(gè)々の開(kāi)発者とチームの両方にとって、優(yōu)れた開(kāi)発體験です。

以上がカクテルミキサーでGraphQLに會(huì)うの詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國(guó)語(yǔ) Web サイトの他の関連記事を參照してください。