OData、JsonAPI、GraphQLの違いは何ですか？
私は自分のキャリアでODataをかなり使用しましたが、今ではさまざまなチームの同僚の何人かが、Microsoftに関連付けられていないため、JsonAPIとGraphQLに移行することを勧めています。これらのクエリ言語の両方での経験はあまりありません。私の知る限り、ODataはSalesforce、IBM、Microsoftで使用されている標準であり、非常に成熟しています。なぜJsonAPIやGraphQLに切り替える必要があるのですか？本当のメリットはありますか？ JsonAPIとGraphQLは新しい標準ですか？人気に基づいてパブリックAPIの実装を変更しても、特に大きなメリットがない場合は、役に立たないようです。
誰かが私を啓発してくれますか？
ODataは、JSON APIに似た仕様の1つです。どちらも、RESTful APIの作成と使用に関する標準について説明しています。 GraphQLは、API設計への新しいアプローチであり、APIリソースを照会する別の方法を指定します。
OData：2007年以降Microsoftで設計および開発され、 [〜＃〜] oasis [〜＃〜] コンソーシアムによって標準化されています。最新バージョンV4は、ISO/IEC JTC 1に提出され、国際標準として承認されます。技術委員会（TC）の企業には、CA Technologies、Citrix、IBM、Microsoft、Progress、Red Hat、SAP、SDLなどがあります。
.NET、Java、JavaScript、PHP、Rubyなどの一般的なプログラミング言語用のライブラリがいくつかあります。この仕様では動的リソースが許可されており、クライアントが検出できるすべてのAPIエンドポイントをリストしたサービスドキュメントがあります。さらに、スキーマを説明するメタデータドキュメントがあります。
JSON API：JSON APIは、2013年5月にYehuda Katzによって最初に作成されました。この最初のドラフトは、EmberデータのRESTアダプタ。仕様の現在の安定バージョンは 1. です。JSONAPI仕様は、両方のプログラミング言語の大部分に実装されていますクライアント側とサーバー側。
JSON APIは、JSONドキュメントの
linkプロパティを通じてHATEOASをサポートします。その他の機能には、ページネーション、ソート、フィルタリング、および関係があります。 JSON APIサーバーによって生成されたJSONドキュメントは、多くのネストされたプロパティを持つ非常に冗長です。GraphQL：2015年以降Facebookで開発されました。 仕様 はまだ草案です。 Reactファンの間で非常に人気があり、主にReactまたはVue.jsと組み合わせて使用されます。GraphQLに似ているのは、比較的新しいFalcorです。
GraphQLはHTTPを利用しますが、RESTとは見なされず、RESTの代替と見なされます。代わりに、クエリ/応答モデルを使用して単一の（仮想）JSONドキュメントを作成します。この新しいモデルは、開発者が作業するのにいくらか優れていますが、RESTよりも優れている点は議論の余地があります。その若さを考えると、エコシステムはまだ成熟していません。
明確かつ完全にするために、OpenAPIをリストに含めますが、これは厳密にはAPI仕様ではありません。それは一部の人々を混乱させる可能性があります。 OpenAPI標準は、APIを記述および定義するための言語に依存しない標準です。 APIは、上記の標準（GraphQLを除く）のいずれかに準拠し、Swagger 3を使用してドキュメント化することもできます。
- OpenAPI（別名Swagger）： OpenAPI Initiative およびLinux Foundationの一部として開発されました。 Google、Microsoft、IBM、SAP、Oracle、Ebay、Paypalなどの大手テクノロジー企業によってサポートされています。仕様の現在のバージョンは .0.2 です。大部分のプログラミング言語の実装だけでなく、Web UIジェネレーターなどの追加ツールも多数あります。
Swaggerのような仕様で得られる最良のものは、APIドキュメントページのジェネレーター、クライアントSDKコードのジェネレーターなど、それらの周りのツールです。
この標準は、おそらくAPIドキュメントとコード生成に現在最も一般的に使用されています。また、API GatewayのAmazon Web Servicesなどのクラウドプロバイダーでもサポートされています（v2のみ）。
私の個人的な意見：
ご覧のように、単一の普遍的な標準ではなく、かなりの数のRESTful仕様があります。私は xumix ここに同意します-それらはすべて「ここで発明されていない」症候群に苦しんでいるようです。上記のいずれかを選択する利点は、特にプロジェクトが小規模または中規模の場合は小さいです。 APIが実装する仕様は重要ですか？おそらくそれほどではないでしょう。一貫して十分に文書化されたAPIの構築に集中してください。