「REST Vs GraphQL」は正しい比較ですか？
RESTとGraphQLを比較する多くのサイトで見ました。 「これは正しい比較ですか？」というこの懸念（実際には私の懸念）を調査した後、私はさらに混乱しています。 RESTはGraphQLに対して異なる定義を持っているので、この質問は、2つの異なる概念を一緒に比較できるのはなぜかと思ってしまいます。
実際には、比較は次のようなものだと私には思えます：
IDE対コンパイラ！??！またはBMW x6 Vs ISO 18541-5 （道路車両）
ウィキから：
残りの定義：
Representational State Transfer（REST） は、Webサービスの作成に使用される一連の制約を定義するソフトウェアアーキテクチャスタイルです。
GraphQl定義：
GraphQL は、API用のオープンソースのデータクエリおよび操作言語であり、既存のデータでクエリを実行するためのランタイムです。
あなたの答えで私の心を明るくしてください。ありがとう
[〜＃〜] rest [〜＃〜] は、1990年代にワールドワイドウェブと並行して開発された建築スタイルです。
ワールドワイドウェブは、REST建築様式（ 多少の偏差あり を使用）のリファレンスアプリケーションです。
HTTPはアプリケーションプロトコル ネットワーク経由でドキュメントを転送するため。
GraphQLは クエリ言語と実行エンジン です。
RESTとGraphQLを直接比較するのはごちゃごちゃです。しかし、あなたができることは、彼らが解決しようとしていた問題の種類を注意深く見ることです。
一般的なソフトウェアエンジニアリングの原則をコンポーネントインターフェイスに適用することにより、システムアーキテクチャ全体が簡素化され、相互作用の可視性が向上します。実装は、それらが提供するサービスから切り離されているため、独立した進化が促進されます。ただし、情報がアプリケーションのニーズに固有のものではなく、標準化された形式で転送されるため、均一なインターフェイスによって効率が低下するというトレードオフがあります。 RESTインターフェースは、大規模なハイパーメディアデータ転送に効率的になるように設計されており、Webの一般的なケースに合わせて最適化しますが、他の形式の建築相互作用には最適ではないインターフェースになります。 フィールディング、20
RESTでは、 caching は重要であり、現在のHTTP仕様には RFC全体 がキャッシングセマンティクス専用です。しかし、GraphQLを使用している人々は、明らかに、キャッシュは問題にとって重要ではないと判断しました。
私が知ることができるように、GraphQLは [〜＃〜] soap [〜＃〜] と同じ結合の選択を多数行っています。それは正しいか間違っているのではなく、トレードオフのバランスが異なるだけです。
いいえ、この比較は無効です。
あなたが言ったように、GraphQLとRESTは異なるものなので、リンゴとオレンジを比較するようなものです。
これは、この問題の1つの見方/視点です。 2つ目は全く逆ですGraphQL/REST比較は有効で非常に便利です。
この2番目のビューを理解するには、次の質問をする必要があります。
データをクライアントに配信するための可能な方法は何ですか？どれを選ぶべきですか？
最初の質問への回答には、RESTとGraphQLの両方が含まれます（他にも多くの方法があります）。どちらも、クライアントへのデータの配信（読み取り-APIの作成）に役立ちます。2番目の質問は、実際にはあなたが読んだすべての比較の背後にあります。
データの配信方法をさまざまな方法で比較することは、有効かつ必要です。この観点から、比較されたものの性質が異なっていても問題ありません。どちらも仕事ができるので、比較する必要があります。
それはリンゴとオレンジの味を比較するようなものです-あなたはそれを行うことができます。
個人的に私はいつもこの比較をしています。問題を解決する方法を同僚に教えるのに非常に役立ちます。