安全性

REST API業界ディスカッション：OData vs GraphQL vs ORDS



Rest Api Industry Discussion



同僚がRestAPIに関する記事を翻訳しましたが、少し興味深いですが、それを共有してください。

ポータルリンク



=========== ================
RESTAPIとの対話方法は常に進化しています。この記事では、Webサービステクノロジの最前線にあるいくつかの標準を見てみましょう。

ProgressのシニアソフトウェアエンジニアであるJeffLeinbachと開発者のエバンジェリストであるSaikrishnaTeja Bobbaが調査を実施し、アプリケーションまたはデータ分析管理ツールで検討する標準APIを決定するのに役立てました。インターネットを介してデータをクエリおよび更新するための標準APIおよびサービスであるOData、GraphQL、およびORDSの違いを比較しました。焦点は、分析、統合、およびデータ管理のためのAPI間の相互運用性にあります。



AWS re：Invent、Oracle OpenWorld、Dreamforce、API Worldなどの業界の議論に基づいて、これらの問題を追跡してきました。 Progressは、ODBC、JDBC、ADO.NET、そして現在はOData（REST）の開発と貢献など、データアクセス標準の豊富な経験もあり、OData技術委員会に初めて参加しました。

RESTとは何ですか？

REST（Representational State Transfer）またはRESTful Webサービスは、インターネット上のコンピューターシステム間の相互運用性を提供する方法です。 RESTful Webサービスを使用すると、要求システムは、統合された事前定義されたステートレス操作のセットを使用して、Webリソースのテキスト表現にアクセスして操作できます。 RESTful実装は、HTTP、URI、JSON、XMLなどの標準を使用します。

RESTはアーキテクチャスタイルであり、標準ではないことに注意してください。



インターネット経由でデータをクエリするための標準API

  • ODataは、もともと2007年にMicrosoftによって開発されました。 一度 これはOASIS標準のRESTAPIであり、Microsoft、SAP、CA、IBM、Salesforceなどの企業間で確立されています。シンプルで標準的な方法でクエリ可能で相互運用可能なRESTfulAPIの作成と使用を可能にします。 ODataは、豊富なクエリ機能を提供し、優れたスケーラビリティだけでなく、オープンソースアプローチの基盤を急速に獲得しています。

  • GraphQLは、2015年に一般公開される前に、2012年にFacebookで社内で開発されました。 GraphQL これは、Facebook、Shopify、Intuitなどの企業によって展開されているデータクエリ言語です。 GraphQLは、API内のデータの完全で理解しやすい説明を提供し、クライアントが必要なものを正確に尋ねることを可能にし、APIの進化を容易にし、強力な開発ツールをサポートします。

  • ORDS ORDS （Oracle REST Data Services）は、Oracle中心のアプリケーションに同様の標準化を提供するOracleRESTサービスです。これにより、SQLおよびその他のデータベーススキルを持つ開発者は、Oracleデータベース用のエンタープライズレベルのデータアクセスAPIを構築できます。 Oracle Databaseは、最新の高度なアプリケーション開発者が使用したいものであり、実際、アプリケーションを構築するためにOracleDatabaseを使用する必要性がますます高まっています。 Oracleの60チームは、Oracle Database、Times Ten、NoSQLなどのORDSを使用しています。

比較標準API

  • チャート-1


    1411204-05965ec416988543.pngstandard-apis-table-1

    図1の標準APIを比較するための基準は、複数のデータソース間の相互運用性の実現に基づいています。

    • 注意すべき点の1つは、比較が仕様の成熟度を示していることです。 GraphQLの人気が高まっているにもかかわらず、広く採用されている成熟度、ベストプラクティス、およびツールを取り巻く問題は残っています。
    • APIのバージョン/メンテナンスの比較では、「いいえ」は悪いと思うかもしれませんが、実際には良いです。これはGraphQLの利点であり、後で紹介します。

  • チャート-2


    1411204-3dd84608714413d2.pngstandard-apis-table-2

    図2では、他のいくつかの標準の予備分析を完了しており、今後の記事でこれらの領域を拡張する予定です。

標準クエリ機能

  • チャート-3


    1411204-66561341a330678f.pngstandard-apis-table-3

    図3は、オープンスタンダードインターフェイスを介してデータにアクセスするための一般的な標準を示しています。

    • ODataは、これらすべてのクエリ機能を完全にサポートしています。 GraphQLとORDSを使用してこれらの操作の一部を実行できますが、標準化または文書化された方法で相互運用性を実装していません。
    • GraphQLは、Webサービスとの相互作用を定義する方法がRESTと非常に似ていますが、サービスの機能については説明していません。したがって、呼び出すことができる関数を作成することで、フィルタリング、並べ替え、関連付けなどを実行できますが、アプリケーション開発者は、これらの操作のセマンティック動作が何であるかを理解する必要があります。
    • ORDSを使用すると、集計と関連付けを行うことができますが、それは、呼び出すことができるカスタム関数を作成することによって行われます。アプリケーションに期待値を通知するためのメタデータや標準の動作定義はないため、アプリケーションは、結果の解釈方法を理解するために、これらの関数の役割を知っている必要があります。

メタデータを抽出する

  • チャート-4


    1411204-2fbb2b825800706a.pngstandard-apis-table-4

    図4は、メタデータの抽出を比較しています。メタデータは、相互運用可能な方法でパターンをプログラムでリバースエンジニアリングする必要がある分析およびデータ管理アプリケーションの中心です。

    • これらのAPIは、この問題を解決するために懸命に取り組んでいます。
    • ただし、GraphQLとORDSはデータのサイズと精度を通知しませんが、ODataは通知します。
    • GraphQLは主キーも通知せず、ORDSは無効性について通知しません。ただし、この情報は、アプリケーションが特定の各フィールドで何ができるかを知るために重要です。

APIのバージョン管理とメンテナンス

頭痛の種の1つは、古いバージョンのAPIを維持しながら、APIの変更中にアプリケーションの更新を処理することです。

  • REST APIの場合、これに関する最大の問題は、エンドポイントをクエリすると、すべてのフィールドが返されることです。 API開発者は、クライアントが特定のフィールドに依存しているかどうかを理解できません。また、クライアント開発者は、必要のないフィールドも含め、返されたすべてのフィールドを処理する必要があります。
  • GraphQLは、クライアントに必要なフィールドを正確に指定させることで、APIのバージョン管理とメンテナンスの問題を解決しました。 API開発者は、既知のフィールドコンシューマーに事前に連絡して、非推奨のフィールドを移行できます。
  • ODataは、リストを選択してアプリケーションに返されるフィールドの数を制限することにより、一種の機能を提供します。これにより、応答のサイズとアプリケーションの処理時間が短縮されますが、どのフィールドが非推奨になったかを示すメカニズムは提供されません。 ODataは、クエリを書き戻してすべてのフィールドを返すのが簡単であるため、より柔軟性があります。ODataは、問題を処理するためにスキーマバージョンを仕様に追加しています。

サンプル

これらのAPIの使用の違いを視覚的に説明するために、次の2つのサンプルコードは、GraphQLとODataで「並べ替え」を実行する方法を示しています。 1411204-c93d849a5a7610a5.pngGraphQLコード

GraphQLのすべてのOpportunity関数の呼び出し例では、その名前は少し明白です。ただし、GraphQLには、渡すことができるパラメーターと、パラメーターの値が関数の動作にどのように影響するかを示すものはありません。この動作は、基盤となる実装によって異なります。

1411204-52cdda07b9179548.pngODataコード

対照的に、ODataは、その動作が仕様の一部として定義されているため、orderByを使用してパラメーターをクエリするときにどのように機能するかを正確に示します。

提案する

standard-apis-table-5

GraphQLはプログラミング言語に似ているため、非常に柔軟性があります。これは強力ですが、アプリケーションが特定のGraphQLサービス実装とより緊密に結合されていることを意味します。それがどのように機能するかを一般的に説明する方法はありません。

Webサービスの処理に慣れている人にとって、GraphQLは少し厄介です。データをクエリするために、通常のREST Webサービスからデータを取得する方法からGET操作を実行するのではなく、POSTリクエストを実行するためです。正確に定義するフィールドや関数など、応答で取得するコンテンツ。

したがって、GraphQLを使用すると、メタデータから使用できるフィールドと関数を判別できますが、それらが意味的に何を意味するのかを必ずしも理解しているとは限りません。

この記事ではAPIコンシューマーに焦点を当てていますが、APIを開発する場合、GraphQLのしきい値は低くなります。簡単なプロジェクトを実行している場合は、GraphQLが方法かもしれませんが、アプリケーションとGraphQLの実装との緊密な結合には問題があります。

ODataは非常に強力ですが、多くの手間がかかります。標準のすべての動作に従う必要があるため、ODataと互換性がなければならない最小レベルの動作セットがあります。これは、サービス開発者に大きな障壁をもたらします。ただし、それに加えて、ODataサービスをすばやく簡単に起動して実行するのに役立つODataクライアントが多数あります。新しいアプリケーションの開発に役立つOData対応のアプリケーションマニフェストとODataクライアントライブラリがすでにあります。