表示: Object Pascal C++
表示設定

REST クライアント ライブラリ

提供: Appmethod Topics
移動先: 案内, 検索

REST の概要 への移動

Embarcadero REST ライブラリは、REST を使用した Web サービスにアクセスするためのフレームワークです(REST は Representational State Transfer の略語)。このライブラリは、Object Pascal でサポートされているすべてのプラットフォームで使用できます。

このフレームワークでは、表現形式として JSON を使用します。XML は明示的にサポートされていません。



用語

用語 定義

REST

REpresentational State Transfer。Roy Fielding, 2000 で定義されたもの。

サービス

REST を使用した Web サービス。

クライアント

TRESTClient コンポーネントのインスタンス。

要求

TRESTRequest コンポーネントのインスタンス。

応答

TRESTResponse コンポーネントのインスタンス。

主なコンポーネントとクラス

REST コンポーネントの概念は、3 つの主要コンポーネント、要求、クライアント、応答を中心に構築されています。これらはすべて、サービスからデータを取得するワークフローに不可欠です。

TRESTClient

REST.Client.TRESTClient は、サービスに対する要求を実際に実行するコンポーネントです。TRESTClient は、サービスに対する HTTP 接続を管理し、HTTP ヘッダーおよびプロキシ サーバーを処理し、応答データを受け取ります。認証クラス(後で説明します)をクライアントに添付することで、要求に認証を手軽に追加することができます。

クライアントの非常に重要なプロパティに BaseURL があります。この基底 URL は、サービス プロバイダの第一のエンドポイントで、通常はそのプロバイダに対するすべての要求において変わりません。要求はすべてこのエンドポイントに送信されるため、基底 URL は要求 URL 全体の '前半' となります。'後半' は 'リソース' です。これは要求コンポーネントによって設定されます。 サービス プロバイダのドキュメントには、通常、この URL 構造についての情報が記述されています。

TRESTClient は、標準の HTTP コードで表現できる HTTP 関連の例外を隠すよう構築されています。 クライアントが送出するのは、TLS/SSL 接続のクライアント ライブラリがない、接続が失敗したなどの、'ハード' な例外だけです。 このフレームワークは有名な Indy(Internet Direct)コンポーネント上で動作するため、TLS/SSL 接続のためのクライアント ライブラリのインストール手順については、「Indy ネットワーク接続のセキュリティ保護、必要な準備」を参照してください。

TRESTRequest

要求(REST.Client.TRESTRequest)は、サービスに対する実際の HTTP 要求を形成するパラメータや設定をすべて保持します。これは、クライアント コンポーネントに接続すると実行することができます(設計時であっても)。要求の非常に重要なプロパティに 'Resource' があります。この値は、先ほど述べた要求 URL 全体の '後半' を構成するもので、サービス上で実行される実際のアクションを定義します。要求では、実行に使用する HTTP メソッド('GET'、'POST'、'PUT'、'DELETE')も定義されます。

通常、要求には以下のようなパラメータが含まれます。

パラメータ

TRESTRequest コンポーネントではいくつかの種類のパラメータをサポートしており、そのいずれにも独自の使い方のパターンがあります。

これらのパラメータは、「キー=値」という形式で、要求の HTTP ヘッダーに埋め込まれます。

これらのパラメータは、「キー=値」という形式で、要求への統合の仕方は要求メソッドによって異なります。

  • HTTP POST 要求の場合、パラメータは要求の本体に埋め込まれます。
  • HTTP GET 要求の場合、パラメータはクエリ文字列の一部として URL に埋め込まれます。

これらのパラメータは値だけで構成され、要求本体の中に統合されます。HTTP GET 要求や HTTP DELETE 要求には本体がないため、これらの要求で本体パラメータを使用することはできません。

これらのパラメータは、「キー=値」という形式で、値は要求のクエリ文字列に埋め込まれます。クエリ文字列には /customer/{ID}/details のようなプレースホルダ(この {ID} は対応するパラメータの値に置き換えられます)を含めることができます。

これらのパラメータは、BaseURL および Request に入力された値を基に自動的に作成することができます。この動作は、AutoCreateParams プロパティを使って制御できます。

これらのパラメータは、「キー=値」という形式で、クッキー値として送信されます。

パラメータはすべて、デフォルトで、有効な HTTP 要求の要件に合わせて自動的にエンコードされます。パラメータの値が既にエンコードされていて再びエンコードする必要がない場合があるかもしれません。そのときには、パラメータのオプションの 'poDoNotEncode' フラグを設定します。そうすると、パラメータ値がそのまま要求に取り込まれます。

REST.Client.TRESTResponse

応答には、サービスから返されたすべてのデータが保持されます。このデータには、HTTP ステータス コードやエラー メッセージ(あれば)、そしてもちろん、返された JSON データが含まれます。応答オブジェクトは、要求の実行中にクライアントがその場で作成することもできますし、事前に作成して要求の実行前にクライアントに接続することも可能です。

応答データには、'Content'、'JSONValue'、'RawBytes' のいずれかのプロパティを使ってアクセスすることができます。

認証

ほとんどのサービスでは、使用前に認証が必要です。認証クラスを使用して、REST サービスで要求される具体的な認証方法を適用します。1 つの認証クラスがクライアントに添付され、実行対象の要求ごとに自動的に実行されます。認証クラスのプロパティを構成した後は、何も変更しなくても、必要なだけの数の要求に使用することができます。通常、認証クラスは、要求に対してヘッダーなどのパラメータを追加する Decorator の役割を果たします。 既存の認証方法は多種多様なため、認証クラスは 1 つだけでは不十分です。その代わりに柔軟なフレームワークが作成され、さまざまな方法の認証が行えるようになっています。

コンポーネント群にはいくつかの標準的な認証クラスが含まれており、カスタム認証クラスも簡単に統合できるようになっています(後のセクションを参照)。

TSimpleAuthenticator

この単純な認証クラスでは、ユーザー名とパスワード用にそれぞれ入力フィールドを持つ HTML フォームのような基本的な認証方法をまねたものです。データは「キー=値」というタプルとして転送されますが、ここではユーザー名、それからパスワードの値を先に指定します。ユーザー名およびパスワード自体の後には、キーの名前も必要です。ユーザー名の値は、'user' や 'username' や単に 'u' のように簡単に転送することができます。これらのキーの名前は、UserNameKey プロパティおよび PasswordKey プロパティに指定することができます。

データの転送方法は要求のメソッドによって異なります。GET 要求(非セキュア)の場合には URL 内で、POST 要求の場合には本体内で転送されます。

THTTPBasicAuthenticator

この基本認証クラスでは、HTTP 基本認証を扱います。ユーザー名とパスワードを含む値が要求の HTTP ヘッダーに埋め込まれます。RFC2617 で定義されているとおり、ユーザー名とパスワードは base64 でエンコードされます。ヘッダーは各要求に埋め込まれます。

TOAuth1Authenticator/TOAuth2Authenticator

この OAuth1 用認証クラスは、'OAuth 1.0a' 方式を使った認証をサポートするためのものです。

OAuth1 はユーザーとのやり取りを含むワークフローであることに注意してください。つまり、OAuth1 認証をサポートすると、認証クラスをプラグインする以上の作業が必要になります。OAuth では、アプリケーションでユーザー向けに Web ビューを開き、サービス プロバイダ(たとえば Twitter など)のログイン ページを表示します。アプリケーション自体がユーザーのユーザー名やパスワードにアクセスすることはなく、サービス プロバイダからトークンを受け取るだけです。そのトークンはアプリケーションがサービスを利用する際に必要になります。

一部のサービス(Twitter や Google など。OAuth2 を参照)では、これらのアクセス トークンを格納しておいて後で再利用することができ、ユーザーが明示的に認証をやり直す必要がありません。ただし、この動作はサービスによってまったく異なります。サービスの中には、短時間でトークンが破棄されるものもあります。

サービス プロバイダによって動作が大きく異なるため、このような汎用コンポーネントでは、部分的なサポートと、サービス プロバイダのワークフローに沿ったインフラストラクチャしか提供することができません。このクラスを継承して、サービス プロバイダに固有の認証クラスを作成するとよいでしょう。

この認証クラスの例は、「」を参照してください。Twitter、Google Tasks、Facebook が該当します。

カスタム認証クラスの作成

特定のサービス向けに既存の認証クラスのどれもうまく動作しない場合には、カスタム認証クラスを作成することができます。最初に、TCustomAuthenticator を継承した新しいクラスを作成し、DoAuthenticate メソッドを上書きします。このメソッドは 2 つのパラメータを受け取ります。現在の要求を実行しているクライアントの参照と、要求自体の参照です。

必要に応じて要求にパラメータを追加することができます。

その他のクラス

要求、クライアント、応答という主要コンポーネントの他に、ライブラリには JSON 形式の応答をデータセットの下位クラスに転送するためのデータセット アダプタも含まれています。

TRESTResponseDataSetAdapter

REST サービス応答が JSON 形式の場合、RESTResponseDataSetAdapter で応答の内容を解析し、そのデータを TDataSet に転送することができます。

すべての JSON データをデータセット構造に変換できるわけではないことに注意してください。パーサーでは、JSON オブジェクトや JSON オブジェクトの配列を探します。パーサーは、JSON オブジェクトのキー値のコレクションを探してデータセットの列を作成します。JSON データの性質により、パーサーは応答全体を反復処理して、データセットの列の情報を収集します。こうすれば、データセットは常に完全な状態になります。

このアダプタはデータの表示にのみ使われます。データを編集してサーバーへ送り返せるようにするには、独自のアダプタを作成する必要があります。

フィールドの事前定義

データベース関連のデータセットと同様に、このデータセット アダプタにもフィールド定義を含めることができます。応答のデータすべてをデータセットに転送するわけでない場合には、フィールドを事前に定義することができます。この場合、パーサーはフィールドの検索をスキップし、JSON オブジェクトのキー名とフィールド名が一致する場合にのみデータの転送を行います。フィールドを事前に定義すると、フィールドの検索が不要になるため、処理を高速化できます。

ルート オブジェクトの定義

サービスの中には、いくらかのメタ情報も含まれるエンベロープにデータを含めた応答を作成するものがあります。

データセットに対して、興味のあるデータがどこで見つかるかのヒント、つまりルート オブジェクトを示すことができます。その値は、アダプタのデータが含まれる JSON エンティティの名前を含んだ文字列です。複数の名前を指定する場合には、ドットで連結してパスの形にします。

用途

この認証クラスの例は、「」を参照してください。Google Tasks、Facebook が該当します。

ここで紹介する例は、RESTDemos という 1 つのプロジェクトにまとめられていて、コードは、Object Pascal製品のサンプル ディレクトリにあります。メイン フォームには複数のタブ シートが含まれており、各シートが REST ライブラリの 1 つの例を表します。このチュートリアルでは、どの例もコンポーネントの使い方をソース レベルで示しています。もちろん、コンポーネントをフォーム上に配置し、適切に接続しても、同じ結果が得られます。

単純な API へのアクセス

最初の単純な例では、アーティストと歌に関する情報を含むオンライン音楽データベースである Songsterr サービス(www.songsterr.com)を使用します。登録や承認といった前提条件なしに基本のクエリを実行することができます。

プロジェクトを新規作成し、次の 3 つのコンポーネントをフォームにドロップします。

  • TRESTRequest
  • TRESTClient
  • TRESTResponse

最初に RESTClient を、それから RESTRequest を、最後に RESTResponse をドロップすると、コンポーネントどうしが自動的に接続されることがわかります。

SongsTerr の API の説明は、同社の Web サイト http://www.songsterr.com/ にあります。すべての種類の要求のドキュメントおよび説明が含まれています。

RESTClient コンポーネントには、BaseURL プロパティを設定する必要があります。これは API にアクセスするためのメイン エントリ ポイントです。この場合、BaseURL は「http://www.songsterr.com/a/ra/」に設定します。このサービスに対する要求はすべて、この URL を基底 URL として使用しなければなりません。クライアント コンポーネントについては、これ以上の構成は必要ありません。

次に、RESTRequest コンポーネントのプロパティを設定します。このコンポーネントの Resource プロパティには、実際のクエリ文字列が含まれます。この例では、歌の基本情報をパターンで問い合わせたいため、ドキュメントを参考に、クエリ文字列を 'songs.json' のように設定します('songs.xml' や 'songs.plist' と指定して、応答を xml 形式や plist 形式で受け取ることも可能です)。パターンを入力するには、pattern パラメータを TRESTRequest に追加します。<pattern> には、「Madonna」など好きなものを入力できます。

それだけです。これで、IDE で RESTRequest コンポーネントを右クリックし、コンテキスト メニューから[実行...]を選択して、要求を実行することができます。しばらくすると、RESTResponse のプロパティ 'Content' がサービスから返されたデータで更新されます。LiveBinding を使ってこのプロパティを TMemo や TEdit といったコンポーネントに接続することができます。

ただし、注意点が 1 つあります。ここでは 'GET 要求' を実行する必要があり、パターンが URL の一部になります。HTTP 標準では、この値の中にスペースなどの '特殊な' 文字が含まれている場合には、値を 'URL エンコード' しなければなりません。これは、自分で独自に行うこともできますし、'URL セグメント' の要求パラメータを使用することもできます。

さて、RESTRequest のパラメータに戻って、pattern パラメータを 'Rolling Stones' に変更します。ここで再び要求を実行すると、バンド名に含まれるスペースを気にしなくてよいことがわかります。スペースが自動的にエンコードされるためです。

単純な API サービスにアクセスする方法の詳細とサンプル プロジェクトについては、「チュートリアル:REST クライアント ライブラリを使用して REST ベースの Web サービスにアクセスする」を参照してください。

Twitter API へのアクセス

Twitter の例では、認証メカニズムに OAuth1 を使用して Twitter API に接続する方法を説明します。OAuth1 のワークフローは、https://dev.twitter.com/docs/auth/oauth のリンク先でも説明されています。

認証処理は 2 つのステップから構成されます。まず、認証コードを要求しなければなりません。このステップでは、パスワードを入力するというユーザーのアクションが必要になります。2 番目のステップは、アクセス トークンを要求するためのもので、これはユーザーに意識させずに行うことができます。

前提条件:アプリケーションの登録

独自のクライアントを使って Twitter API にアクセスするには、Twitter の 'デベロッパ コンソール' でそのクライアントをアプリケーションとして登録する必要があります。これは https://dev.twitter.com/apps のページで行うことができます。

アプリケーションを登録したら、後で認証に使用する 'コンシューマ キー' と 'コンシューマ シークレット' が手に入ります。



ステップ 1:要求トークンと認証コードを取得する

これが OAuth1 ワークフローの最初の部分です。コンシューマ キーとコンシューマ シークレットを Twitter の要求トークン エンドポイントに送信します。すぐに応答があり、'要求トークン' と '要求トークン シークレット' を入手できます。どちらの値も後で必要になります。ここで要求トークンを Twitter に送り返しますが、今回はアクセス トークン エンドポイントを使用します。この処理は、ユーザーとのやり取りが必要なので、Web ビューを使って行わなければなりません (メモ:Twitter では、Web ビューが必要ない "x-auth" というメソッドも提供していますが、これを使用できるのは公式 Twitter クライアントなどの権限のあるアプリケーションだけです)。

Twitter によって、Web ビューに 6 桁の検証コードが表示されます。このビューは非常に制約が多く、このコードを選択してクリップボードにコピーすることができません。この番号は手動で書き写す必要があります。

ステップ 2:アクセス トークンを取得する

ステップ 1 の検証コードを使ってアクセス トークン エンドポイントに要求を行い、アクセス トークンとアクセス トークン シークレットを取得します。これにより、ステップ 1 の要求トークンと要求トークン シークレットが無効になるため、値をクリアしなければなりません。再利用はできません。

ステップ 3:状態更新('ツイート')を送信する

これで OAuth1 認証クラスが Twitter API に対する要求に署名するのに必要なデータがすべて揃ったため、最初の状態更新('ツイート')を送信することができます。

Google Tasks API へのアクセス

Google の例では、認証メカニズムに OAuth2 を使用して Google API にアクセスする方法を説明します。OAuth2 のワークフローは、https://developers.google.com/accounts/docs/OAuth2InstalledApp?hl=de のリンク先でも説明されています。

認証処理は 2 つのステップから構成されます。まず、認証コードを要求しなければなりません。このステップでは、パスワードを入力するというユーザーのアクションが必要になります。2 番目のステップは、アクセス トークンを要求するためのもので、これはユーザーに意識させずに行うことができます。



前提条件:アプリケーションの登録

独自のクライアントを使って Google API にアクセスするには、Google Code の 'API コンソール' でそのクライアントをアプリケーションとして登録する必要があります。これは https://code.google.com/apis/console?hl=en#access のページで行うことができます。

アプリケーションの登録時に、アクセスしたい API を選択する必要があります。この例では、'Tasks API' を選択してアクティブ化します。そのアプリケーション向けにアクティブ化しなかった API に後でアクセスすることはできませんので注意してください。アプリケーションを登録したら、後で認証に使用する 'クライアント ID' と 'クライアント シークレット' が手に入ります。



ステップ 1:認証コードを要求する

このワークフローの最初のステップでは、認証コードを取得します。それには、特別な Google URL の Web ビューを開きます。この URL には次のパラメータが必要です。

  • response_type=code
    ネイティブ アプリケーションの場合、Google ではこのパラメータの値を "code" にしなければなりません。
  • client_id={クライアント ID}
    ここには、アプリケーションを登録した後で受け取った自分のクライアント ID を指定する必要があります。
  • redirect_uri=urn:ietf:wg:oauth:2.0:oob
    ここでは、Google から指定された固定の URI を使用します。ネイティブ クライアントを使用しているため、Web アプリケーションの場合と異なり、ユーザーに対して開くページがないからです。
  • scope=https://www.googleapis.com/auth/tasks
    アプリケーションが要求する Google API アクセスを示します。1 つの要求に複数のスコープを含めることができます。指定できるスコープの一覧はこちら https://developers.google.com/gdata/faq#AuthScopes で確認できます。ここでアクセスを要求するには、アプリケーションをスコープに登録しておく必要があることに注意してください。
  • login_hint=user@example.com(オプション)
    ユーザーがワークフローを理解しやすくするために、Google ではログイン ヒントを表示できるようになっています。ここにユーザーの電子メール アドレスを指定してそれをログイン フィールドに自動的に挿入し、ユーザーがパスワードだけを入力すればいいようにすることができます。

この例の完全 URL は、次のように組み立てられます。

 LURL := ' https://accounts.google.com/o/oauth2/auth ';
 + '?response_type=' + URIEncode('code');
 + '&client_id=' + URIEncode( 'INSERT_YOUR_OWN_CLIENT_ID_HERE' );
 + '&redirect_uri=' + URIEncode('urn:ietf:wg:oauth:2.0:oob');
 + '&scope=' + URIEncode(' https://www.googleapis.com/auth/tasks ');
 + '&login_hint=' + URIEncode('user@example.com'); // optional

ステップ 2:アクセス トークンを要求する

このステップでは、TRESTClient と TRESTRequest が必要です。

  LClient := TRESTClient.Create(' https://accounts.google.com/ ');

次に、要求オブジェクトを作成して構成します。Google から要求される次のパラメータを含めます。

  • code={ステップ 1 の認証コード}
  • client_id={クライアント ID}
    API コンソールに表示されたアプリケーションのクライアント ID です。
  • client_secret={クライアント シークレット}
    API コンソールに表示されたアプリケーションのクライアント シークレットです。
  • redirect_uri=urn:ietf:wg:oauth:2.0:oob
    ここでは、Google から指定された固定の URI を使用します。ネイティブ クライアントを使用しているため、Web アプリケーションの場合と異なり、ユーザーに対して開くページがないからです。
  • grant_type=authorization_code
    OAuth 2.0 仕様で定義されているように、このフィールドには "authorization_code" という値を含める必要があります。

コードでは、このアクセス要求は次のようになります。

  LRequest := TRESTRequest.Create(nil);
  LRequest.Method := TRESTRequestMethod.rmPOST;
  LRequest.Resource := 'o/oauth2/token';
  // required parameters
  LRequest.AddParameter('code', 'AUTHCODE_FROM_STEP#1', TRESTRequestParameterKind.pkGETorPOST);
  LRequest.AddParameter('client_id', 'YOUR_CLIENTID', TRESTRequestParameterKind.pkGETorPOST);
  LRequest.AddParameter('client_secret', 'YOUR_CLIENT_SECRET', TRESTRequestParameterKind.pkGETorPOST);
  LRequest.AddParameter('redirect_uri', 'urn:ietf:wg:oauth:2.0:oob', TRESTRequestParameterKind.pkGETorPOST);
  LRequest.AddParameter('grant_type', 'authorization_code', TRESTRequestParameterKind.pkGETorPOST);

要求オブジェクトの準備が済んだら、クライアントを使って実行します。

  LClient.Execute(LRequest);

要求の実行が成功したら、応答の内容としてアクセス トークンが送られてきます。応答オブジェクトに問い合わせると、この値を取り出すことができます。

  LClient.Response.TryGetSimpleValue('access_token', LToken);

アクセス トークンの値は、この後 Google API に要求を送るたびに必要になるため、保存しておく必要があります。

Facebook API へのアクセス

Facebook の例では、OAuth2 を使用して Facebook の Graph API にアクセスする方法を説明します。最初のステップでは 'アクセス トークン' を入手します。このアクセス トークンは、後で Graph API を使用するために必要です。後で API に問い合わせをするときに、このアクセス トークンを使って認証を行います。

前提条件:アプリケーションの登録

独自のクライアントを使って Facebook API にアクセスするには、Facebook にそのクライアントをアプリケーションとして登録する必要があります。これは https://developers.facebook.com/apps のページで行うことができます。

アプリケーションを登録したら、'アプリケーション ID' が手に入ります。これは後で認証に使用します。この 'アプリケーション ID' を 'クライアント ID' と呼ぶこともあります。



ステップ 1:アクセス トークンを要求する

Facebook では、複数の方法でアクセス トークンを要求することができます。Facebook で提供されている SDK を使用するわけではないため、'Web 用のログイン フロー(JavaScript SDK を使用しない)' を選択します。ドキュメントは Web サイト https://developers.facebook.com/docs/facebook-login/login-flow-for-web-no-jssdk/ にあります。

Facebook URL の Web ビューを開いてアクセス トークンを要求します。基底 URL は https://www.facebook.com/dialog/oauth です。パラメータはいくつかありますが、必須なのは最初の 2 つだけです。ただし、残りの 2 つも非常に役立ちます。

  • client_id={クライアント ID}
    ここには、アプリケーションを登録した後で受け取った自分のクライアント ID を指定する必要があります。'アプリケーション ID' として記載されています。
  • redirect_uri=https://www.facebook.com/connect/login_success.html
    ここでは、Facebook から指定された固定の URI を使用します。ネイティブ クライアントを使用しているため、Web アプリケーションの場合と異なり、ユーザーに対して開くページがないからです。
  • response_type=token
    Facebook では、ネイティブ アプリケーションの場合、'response_type' の値に 'token' を指定する必要があります。これを指定すると、ログイン メカニズムにより、リダイレクト URI の一部としてアクセス トークンが追加で渡されます。
  • scope={必要なスコープ}
    scope パラメータには取得する権限のリストを含めます。この例では "user_about_me,user_birthday" を指定します。権限の完全なリストについては、Web サイト https://developers.facebook.com/docs/facebook-login/permissions/ を参照してください。

この例の完全 URL は、次のように組み立てられます。

  LURL := 'https://www.facebook.com/dialog/oauth'
   + '?client_id=' + URIEncode( 'INSERT_YOUR_OWN_CLIENT_ID_HERE' )
   + '&response_type=token'
   + '&scope=' + URIEncode('user_about_me,user_birthday')
   + '&redirect_uri=' + URIEncode(' https://www.facebook.com/connect/login_success.html ');

このアクセス トークンが有効なのは 2 時間ほどです。ただし、バックグラウンドで更新できるため、ユーザーが認証をし直す必要はありません。詳細については、https://developers.facebook.com/docs/facebook-login/access-tokens/#extending を参照してください。

ステップ 2:ユーザー情報を取得する

ここで、TRESTCient、TRESTRequest、TRESTResponse、TOAuth2Authenticator の各コンポーネントが必要になります。

ここでもまず、クライアントと認証クラスを作成し、接続します。

 LClient := TRESTClient.Create(' https://graph.facebook.com/ ');

 LOAuth2 := TOAuth2Authenticator.Create(self);
 with (LOAuth2 AS TOAuth2Authenticator) do
 begin
   AccessToken := 'YOUR_OWN_ACCESS-TOKEN_FROM_STEP#1';
 end;
 LClient.Authenticator := LOAuth2;

次に、要求の準備をする必要があります。リソース URI は、Facebook の Graph Explorer を使って生成したものです。この URI からは、自分の名前と、誕生日(忘れているといけないので…)、最初の 10 件のコンタクト('友達')の名前が返されます。Graph Explorer は Web サイト https://developers.facebook.com/tools/explorer にあります。

 LRequest := TRESTRequest.Create(nil);
 LRequest.Method := TRESTRequestMethod.rmGET;
 LRequest.Resource := 'me?fields=name,birthday,friends.limit(10).fields(name)';

これで終わります。クライアントを使って要求を実行することができます。

  LClient.Execute(LRequest);

JSON エンコードされた内容が、クライアントの応答オブジェクトに含まれています。応答オブジェクトはこちらから渡さなかったため、この応答オブジェクトはクライアントがその場で作成したものです。

  memo_ResponseData.Lines.Text := LClient.Response.Content;

応答のデータセットへの変換

サービスから返された JSON 形式の応答は、TDataSet の任意の下位クラスに変換することができます。それにはもちろん、データがデータセットに変換可能な形式である必要があります。つまり、JSON オブジェクトまたは JSON オブジェクトの配列です。各オブジェクトはデータセット内の新しいレコードになります。JSON オブジェクトのプロパティは、通常、データセットの列になります。

関連項目

個人用ツール
他言語版