最初の記事はこちらから。何?ODataは、データモデルの記述、およびそれらのモデルに従ったデータの編集および照会をサポートするプロトコル。特徴指定は、以下のような点があげられます。メタデータ:特定のデータプロバイダによって公開されるデータモデルの機械可読の記述。データ:データエンティティのセットとそれらの間の関係。クエリー:サービスがフィルタリングとデータへの変換を実行するよう要求し、結果を返す。編集:データの作成、更新、および削除。フォーマットを統一したことにあるでしょう。APIのデータリクエストを定型化することで、表形式データの取得アプローチを最適化しています。EDMと呼ばれるMetadataエンドポイントを備えているので、各種フィールドや型を確認できるのも強みですね。始めたためか、どちらかと言えばエンタープライズ寄りなサービスで提供されています。GraphAPI・Salesforceなどなど。提供していたりします。統一されたURIのクエリアプローチとメタデータ提供により、BI系やETL系などのツール、サービスなどによるエコシステムが強力です。データソースとしての接続先があったりします。エコシステムでのサポートは強力ですね。Olingo」があります。クライアントを構成します。プロトコルの特性をいかして実装します。https://app.swaggerhub.com/apis/sugimomoto/CDataNorthWindSample/1.0.0操作も同じように注文データ(orders)と注文明細データ(order_details)を取得して結合したものをコンソールで出力するというものです。利用するにあたってのポイントポイントはODataの特徴でも解説した通り、リクエストを実行する際のURI作成アプローチにあります。URIBuilderというクラスで対象のリソースの指定(ordersやorder_details)、取得件数の制御($top=10)、keyとなるidの指定を実施できるメソッドを備えています。ドキュメントを確認しながら、URIの構成を考える必要がありません。orderDetail.getDiscount());メタデータの取得ができるため、以下のようなカラムを全部持ってきて、繰り返し出力するような記述を行うことが可能です。生成することも可能みたいです。実装するほうが楽だったり)動的にカラムが可変するようなアプリケーションを実装する場合は特に楽になるのではないでしょうか。お送りしましたが、サーバーサイドの実装が重いこともあり、最近は下火になりつつあるかなという感じは否めません。いう認識があるだけでも、実装しやすくなるシチュエーションはまだまだあるのではないかと思います。プロトコルと勝手に呼んでいるGraphQLでお送りします。実装をお送りしました。APIがカバーできない2つの要因とその対策なんだか珍しく、あおり気味のタイトルにしてしまいました。(翻訳)Twitter@sugimomotoさんのツイートはてなブログをはじめよう!sugimomotoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。