OData対GraphQL
パフォーマンス、開発者の使いやすさ、コミュニティなどに関して、GraphQLとODataの良い比較はありますか。インターネットで見つけたすべての記事は非常に偏っています。
大きなかさばったJSONまたはバイナリデータを返す最良の方法は何でしょうか？
Dot NetのGraphQLとDotNet Web APIのOdataの両方を調査し、試してみて、実用的なデモを作成しました。
- 開発者の使いやすさ既存のWebAPI（DotNet Framework）があり、GraphQLまたはOData互換に移行することを検討するWebAPIの場合、私の簡単な統合とOut of the Box Filter、OrderBy、Select、Expandなどの機能のためにODataを選択します（ MSFT On DotNet OData を参照）。 GraphQLを選択した場合、タイプ、スキーマ、クエリの作成、各クエリのリゾルバーの実装など、多くの作業を行う必要があります。
- Performanceはクエリロジックによって異なります。 GraphQLとOdataの両方には、ODataで$ selectを使用して要求を取得する機能があり、GraphQLではQuery規則によって要求できます。
- 最初からのAPI開発、すべてのAPIリクエストに単一のエンドポイントのみが必要で、バージョン管理エンドポイントを維持したくない場合、Autosuggestフィールド名とスキーマのタイプが最適なオプションです。しかし、各フレームワークおよびコミュニティのGraphQLライブラリの可用性は、テクノロジースタックによって異なります（例：nodejs、C＃、Ruby、Javaなど）
はい、詳細を説明した Telerik による記事を確認し、読みました。比較PDF GraphQLおよびOdataの場合 参照リンクで詳細を掘り下げることができるのは、比較画像のみを並べて添付しています GraphQL vs OData 。
標準API
ここで、APIバージョン管理/メンテナンスのNoはポジティブであり、単一のエンドポイントを意味し、2つのバージョン管理されたAPIを取り除きます
クエリ機能
表面機能
主にODataサービスは、CRUD操作に最小限の労力でデータベースへのアクセスを提供する場合に使用されます。
ただし、Sharepoint REST APIおよびOffice 365 REST APIを知っている場合は、ODataに基づいており、幅広いAPIを提供します。現在、MicrosoftはGraph APIまたはMicrosoft Graphと呼ばれるユニバーサルAPIを構築しています。これは、デフォルトでCORS要求と、Office 365、dynamics 365、Outlook Exchange API、OneDrive APIなどからの要求に対する統合エンドポイントを有効にします。
また、POSTメソッドを使用してデータを要求することは良い考えとは思えません。そして、明らかに、サーバーに要求を出すために必要なデータの量ははるかに大きいです。 Sumit Sarkarの記事 の例によると：
リクエストを行うためにトラフィックされるデータの量は、ODataよりもGraphQLの方がはるかに多くなります。ただし、結果（応答）は同じです。