「REST Vs GraphQL」は正しい比較ですか？

RESTとGraphQLを比較する多くのサイトで見ました。「これは正しい比較ですか？」というこの懸念（実際には私の懸念）を調査した後、私はさらに混乱しています。RESTはGraphQLに対して異なる定義を持っているので、この質問は、2つの異なる概念を一緒に比較できるのはなぜか、と私の心を混乱させます。

実際には、比較は次のようなものだと私には思えます：

IDE対コンパイラ！??！またはBMW x6 Vs ISO 18541-5（道路車両）

ウィキから：

残りの定義：

表現状態転送（REST）は、Webサービスの作成に使用される一連の制約を定義するソフトウェアアーキテクチャスタイルです。

GraphQl定義：

GraphQLは、API用のオープンソースのデータクエリと操作言語、および既存のデータでクエリを実行するためのランタイムです。

あなたの答えで私の心を明るくしてください。ありがとう

RESTは、1990年代にWorld Wide Webと並行して開発されたアーキテクチャスタイルです。

World Wide Webは、RESTアーキテクチャスタイルのリファレンスアプリケーションです（多少の違いがあります）。

HTTPは、ネットワーク経由でドキュメントを転送するためのアプリケーションプロトコルです。

GraphQLはクエリ言語であり、実行エンジンです。

RESTとGraphQLを直接比較するのはごちゃごちゃです。しかし、あなたができることは、彼らが解決しようとしていた問題の種類を注意深く見ることです。

一般的なソフトウェアエンジニアリングの原則をコンポーネントインターフェイスに適用することにより、システムアーキテクチャ全体が簡素化され、相互作用の可視性が向上します。実装は、それらが提供するサービスから切り離されているため、独立した進化が促進されます。ただし、情報がアプリケーションのニーズに固有のものではなく、標準化された形式で転送されるため、均一なインターフェイスによって効率が低下するというトレードオフがあります。RESTインターフェースは、大規模なハイパーメディアデータ転送に効率的になるように設計されており、Webの一般的なケースに合わせて最適化されますが、その結果、他の形式のアーキテクチャーの相互作用には最適ではないインターフェースになります。 フィールディング、2000

RESTでは、キャッシングは重要なことであり、現在のHTTP仕様には、セマンティクスのキャッシング専用のRFC全体があります。しかし、GraphQLを使用している人々は明らかに、キャッシュは問題にとって重要ではないと判断しました。

私が知ることができるように、GraphQLはSOAPと同じカップリングの選択をたくさん行っています。それは正しいか間違っているのではなく、トレードオフのバランスが異なるだけです。

いいえ、この比較は無効です。

あなたが言ったように、GraphQLとRESTは別物なので、リンゴとオレンジを比較するようなものです。

これは、この問題の1つの見方/視点です。2つ目はまったく逆です。GraphQL/ RESTの比較は有効で非常に便利です。

この2番目のビューを理解するには、次の質問をする必要があります。

データをクライアントに配信するために可能な方法は何ですか？どれを選ぶべきですか？

最初の質問への回答には、RESTとGraphQLの両方が（他の多くの方法で）含まれています。どちらもクライアントにデータを配信するのに役立ちます（読み取り-APIの作成）。2番目の質問は、実際に、あなたが読んだすべての比較の背後にあるものです。

データを配信する方法をさまざまに比較することは、有効かつ必要です。この観点から、比較されたものの性質が異なっていても問題ありません。どちらも仕事ができるので、比較する必要があります。

リンゴとオレンジの味を比べるようなものです。

個人的に私はいつもこの比較をしています。問題を解決する方法を同僚に教えるのに非常に役立ちます。