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

DataSnap REST への移動

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

このフレームワークでは、表現形式として 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 関連の例外を隠すよう構築されています。クライアントは、「ハード」関係の例外、接続失敗、といったもののみ挙げます。新しい TNetHTTPClient 上で動作するフレームワークで、システム HTTP クライアントソケットをベースとしています。これにより、OS の能力を利用して、自動的に SSL/TLS/HTTPS を解決、やり取りします。

TRESTRequest

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

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

パラメータ

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

ヘッダーパラメータ

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

POST/GET パラメータ

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

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

本体パラメータ

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

URL セグメントパラメータ

これらのパラメータは、「キー=値」という形式で、値は要求のクエリ文字列に埋め込まれます。クエリ文字列には /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 つのプロジェクトにまとめられていて、コードは、Delphi の製品のサンプルディレクトリにあります。メインフォームには複数のタブシートが含まれており、各シートが 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 オブジェクトのプロパティは、通常、データセットの列になります。

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

目次

用語

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

TRESTClient

TRESTRequest

パラメータ

REST.Client.TRESTResponse

認証

TSimpleAuthenticator

THTTPBasicAuthenticator

TOAuth1Authenticator/TOAuth2Authenticator

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

その他のクラス

TRESTResponseDataSetAdapter

フィールドの事前定義

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

用途

例

単純な API へのアクセス

Twitter API へのアクセス

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

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

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

ステップ 3：状態更新（'ツイート'）を送信する

Google Tasks API へのアクセス

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

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

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

Facebook API へのアクセス

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

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

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

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

関連項目

案内メニュー

検索

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

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

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

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

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