Bibliothèque client REST

De Appmethod Topics
Aller à : navigation, rechercher

Remonter à Présentation de REST

La bibliothèque Embarcadero REST (Embarcadero REST Library) est un framework d'accès aux services Web basés sur REST (REST est l'acronyme de Representational State Transfer). Cette bibliothèque est disponible pour toutes les plates-formes supportées par Object Pascal.

Le framework est principalement basé sur le format de représentation JSON. Le format XML n'est pas explicitement pris en charge.


Terminologie

Terme Définition

REST

REpresentational State Transfer - tel que défini par Roy Fielding, 2000

Service

Service Web basé sur REST

Client

Instance du composant TRESTClient

Requête

Instance du composant TRESTRequest

Réponse

Instance du composant TRESTResponse

Principaux composants et classes

Le concept des composants REST tourne autour de trois composants principaux : la requête, le client et la réponse. Tous font partie du flux de travail d'extraction des données à partir d'un service.

TRESTClient

REST.Client.TRESTClient est le composant qui exécute une requête adressée à un service. TRESTClient gère la connexion HTTP au service, traite les en-têtes HTTP et les serveurs proxy et reçoit les données de réponse. Les authentificateurs (décrits ultérieurement) peuvent être attachés au client pour ajouter facilement l'authentification à une requête.

L'une des propriétés les plus importantes du client est BaseURL (l'URL de base). L'URL de base est le point de terminaison primaire d'un fournisseur de services. Elle reste généralement constante pour toutes les requêtes adressées à ce fournisseur. Toutes les requêtes sont dirigées vers ce point de terminaison, de sorte que l'URL de base est la 'première moitié' de l'URL de requête complète. La 'seconde moitié' est la 'ressource'. Elle est fournie par le composant requête. La documentation du fournisseur de services contient généralement des informations sur la structure de l'URL.

TRESTClient est construit pour masquer toutes les exceptions en rapport avec HTTP tant que ces exceptions peuvent être représentées par un code HTTP standard. Le client déclenche uniquement des exceptions 'définitives', telles que l'absence de bibliothèques client pour une connexion TLS/SSL, des pannes de connexion, et ainsi de suite. Le framework opère sur les composants Indy connus. Pour des instructions sur l'installation des bibliothèques client pour les connexions TLS/SSL, vous devez donc consulter la rubrique , Prérequis..

TRESTRequest

La requête (REST.Client.TRESTRequest) contient tous les paramètres et les réglages qui composent la requête HTTP réelle adressée au service. Elle peut être exécutée lorsqu'elle est connectée à un composant client (y compris à la conception). L'une des propriétés les plus importantes de la requête est 'Resource' (la ressource). Cette valeur forme la 'seconde moitié' de l'URL de requête complète mentionnée plus haut et définit l'action réelle exécutée sur le service. La requête définit également les méthodes HTTP ('get', 'post', 'put', 'delete') utilisées pour son exécution.

Généralement, une requête contient des paramètres tels que les suivants :

Paramètres

Le composant TRESTRequest prend en charge plusieurs types de paramètres différents, qui ont tous leur propre mode d'utilisation.

Ces paramètres prennent la forme key=value et sont intégrés dans l'en-tête HTTP de la requête.

Ces paramètres prennent la forme key=value, et leur intégration dans la requête dépend de la méthode de requête.

  • Pour les requêtes HTTP POST, les paramètres sont intégrés dans le corps de la requête.
  • Pour les requêtes HTTP GET, les paramètres sont intégrés dans l'URL en tant que partie de la chaîne de requête.

Ces paramètres ne comportent qu'une valeur et sont intégrés dans le corps de la requête. Ils ne peuvent pas être utilisés pour les requêtes HTTP GET ou HTTP DELETE car ils n'ont pas de corps.

Ces paramètres prennent la forme key=value, et leurs valeurs sont intégrées dans la chaîne de la requête. La chaîne de requête peut contenir des espaces réservés comme /customer/{ID}/details, où {ID} est remplacé par la valeur du paramètre correspondant.

Ces paramètres peuvent être créés automatiquement en fonction de la valeur entrée pour BaseURL et Request. Vous pouvez utiliser la propriété AutoCreateParams pour contrôler ce comportement.

Ces paramètres prennent la forme key=value, et sont envoyés comme valeurs de cookie.

Tous les paramètres sont encodés automatiquement pour correspondre aux exigences d'une requête HTTP valide par défaut. Dans certains cas, il se peut que la valeur du paramètre soit déjà encodée et n'ait pas besoin de l'être à nouveau. Vous devez alors définir l'indicateur 'poDoNotEncode' dans les options du paramètre pour forcer la requête à accepter la valeur du paramètre en l'état.

REST.Client.TRESTResponse

La réponse contient toutes les données retournées par le service. Ces données incluent le code d'état HTTP, les messages d'erreur (s'il en existe), et bien sûr les données JSON retournées. Un objet réponse peut être créé à la volée par le client pendant l'exécution de la requête, ou créé à l'avance, puis être connecté à un client avant d'exécuter une requête.

Les données réponse peuvent être consultées en utilisant l'une des propriétés 'Content', 'JSONValue' ou 'RAWbytes'.

Authentification

La plupart des services requièrent une authentification avant de pouvoir être utilisés. Les classes de l'authentificateur sont utilisées pour appliquer les méthodes d'authentification spécifiques requises par le service REST. Un authentificateur est attaché au client et est automatiquement exécuté sur chaque requête exécutée. Une fois la propriété configurée, elle peut être utilisée pour autant de requêtes que nécessaire, sans plus jamais la modifier. Généralement, l'authentificateur fonctionne comme un Decorator pour la requête, en lui ajoutant des en-têtes et d'autres paramètres. En raison de la variété des méthodes d'authentification existantes, la fourniture d'un seul authentificateur ne peut pas suffire. Un framework flexible a donc été créé à la place, autorisant l'authentification par le biais de nombreuses méthodes différentes.

Quelques authentificateurs standard sont inclus dans le jeu de composants, mais il est possible d'intégrer facilement des authentificateurs personnalisés (voir ci-dessous).

TSimpleAuthenticator

L'authentificateur simple reproduit une authentification de base comme une fiche HTML contenant un champ pour la saisie du nom d'utilisateur et un autre pour la saisie du mot de passe. Les données sont transmises sous la forme d'un tuple de key=value où la valeur est indiquée en premier, suivie du nom d'utilisateur, puis du mot de passe. Outre le nom d'utilisateur et le mot de passe, l'authentificateur requiert également les noms des clés. La valeur d'un nom d'utilisateur peut être transmise en tant que 'user', 'username', ou parfois en tant que simple 'u'. Ces noms de clés peuvent être spécifiés dans les propriétés UserNameKey et PasswordKey.

En fonction de la méthode de la requête, les données sont transmises dans l'URL pour une requête GET (non sécurisé) ou dans le corps pour une requête POST.

THTTPBasicAuthenticator

L'authentificateur de base se charge de l'authentification HTTP basique. Il intègre une valeur contenant le nom d'utilisateur et le mot de passe dans l'en-tête HTTP de la requête. Selon la spécification RFC2617, le nom d'utilisateur et le mot de passe sont encodés en base64. L'en-tête est intégré pour chaque requête.

TOAuth1Authenticator/ TOAuth2Authenticator

L'authentificateur OAuth1 prend en charge l'authentification en utilisant la méthode 'OAuth 1.0a'.

Notez que OAuth1 est un flux de travail qui inclut l'interaction utilisateur. Cela signifie que le support de l'authentification OAuth1 exige bien plus qu'une simple intégration de l'authentificateur. En effet, avec OAuth, l'application présente une vue Web à l'utilisateur. Cette vue affiche la page de connexion du fournisseur de services (comme Twitter, par exemple). L'application en elle-même n'accède jamais au nom d'utilisateur ou au mot de passe de l'utilisateur ; elle reçoit simplement des tokens du fournisseur de services, et doit utiliser ces tokens pour accéder au service.

Certains services (comme Twitter ou Google, voir OAuth2) autorisent le stockage de ces tokens d'accès afin de les réutiliser ultérieurement. Cela évite à l'utilisateur toute autorisation explicite supplémentaire. Toutefois, ce comportement dépend entièrement du service. D'autres services peuvent supprimer les tokens après une courte période.

En raison des fortes dépendances vis-à-vis des fournisseurs de services, un composant générique tel que celui-ci ne peut fournir qu'un support limité et l'infrastructure nécessaire pour suivre le flux de travail du fournisseur de services. Vous pouvez, si vous le souhaitez, utiliser l'héritage de cette classe pour créer une classe d'authentificateur spécifique à un fournisseur de services.

Vous pouvez voir un exemple de cet authentificateur dans la section Exemples : Twitter, Google Tasks, Facebook.

Création d'authentificateurs personnalisés

Si aucun des authentificateurs existants ne fonctionne pour un service spécial, vous pouvez créer des authentificateurs personnalisés. La première étape consiste à créer une nouvelle classe, héritant de TCustomAuthenticator, et à redéfinir la méthode DoAuthenticate. Cette méthode prend en compte deux paramètres : une référence au client exécutant la requête en cours et une référence à la requête elle-même.

Il est possible d'ajouter des paramètres à la requête en fonction des besoins.

Classes supplémentaires

Outre les principaux composants requête, client et réponse, la bibliothèque contient également un adaptateur d'ensemble de données autorisant à transférer une réponse au format JSON dans une classe descendante d'ensemble de données.

TRESTResponseDataSetAdapter

Lorsqu'une réponse de service REST est au format JSON, une classe RESTResponseDataSetAdapter peut analyser le contenu de la réponse et transférer les données dans un composant TDataSet.

Notez que toutes les données JSON ne peuvent pas être transformées en structure DataSet. L'analyseur recherche un objet JSON ou un tableau d'objets JSON. Il recherche les collections de valeurs clés des objets JSON pour créer les colonnes de l'ensemble de données. En raison de la nature des données JSON, l'analyseur itère à travers la réponse entière et collecte les informations pour les colonnes de l'ensemble de données. De cette manière, l'ensemble de données est toujours complet.

L'adaptateur sert uniquement à afficher les données. Pour autoriser la modification des données et les renvoyer vers le serveur, vous devez créer votre propre adaptateur.

Champs prédéfinis

Cet adaptateur d'ensemble de données, qui est similaire à un ensemble de données associé à une base de données, contient des définitions de champs. Si toutes les données de la réponse ne sont pas supposées être transférées vers l'ensemble de données, il est possible de prédéfinir les champs. Dans ce cas, l'analyseur ignore la recherche des champs et transfère simplement les données lorsque le nom de clé de l'objet JSON et le nom de champ correspondent. La prédéfinition des champs peut accélérer le processus, étant donné que la recherche des champs n'est pas nécessaire.

Définition d'un objet Root

Certains services peuvent former une réponse couvrant les données dans une enveloppe contenant également certaines informations de métadonnées.

Vous pouvez fournir à l'ensemble de données un moyen de trouver les données d'intérêt : l'objet Root. Sa valeur est une chaîne, contenant le nom ou les noms des entités JSON qui contiennent les données pour l'adaptateur. Si vous souhaitez spécifier plusieurs noms ou si vous devez le faire, concaténez-les à l'aide de points pour former un chemin.

Usage

Vous pouvez voir un exemple de cet authentificateur dans la section Exemples : Google Tasks, Facebook.

Exemples

Les exemples sont regroupés dans un seul projet - RESTDemos. Vous trouverez le code des exemples dans votre répertoire des exemples du produit Object Pascal. La principale fiche contient plusieurs feuilles à onglets. Chacune d'elles représente un exemple de la bibliothèque REST. Dans ce tutoriel, tous les exemples montrent l'utilisation des composants au niveau source. Il est bien sûr possible de produire les mêmes résultats en plaçant les composants sur une fiche et en les connectant de manière appropriée.

Accès à une API simple

Pour ce premier exemple simple, utilisez le service Songsterr (www.songsterr.com). Cette base de données musicale en ligne contient des informations sur les artistes et leurs titres. Il est possible d'y effectuer des requêtes de base sans conditions préalables comme un enregistrement ou une autorisation.

Créez un nouveau projet et déposez trois composants sur la fiche :

  • TRESTRequest
  • TRESTClient
  • TRESTResponse

Si vous commencez par RESTClient, suivi de RESTRequest, puis de RESTResponse, vous pouvez voir comment les composants se connectent automatiquement les uns aux autres.

L'API de SongsTerr est décrite sur son site Web : http://www.songsterr.com/. Tous les types de requêtes sont documentés et expliqués.

Pour le composant RESTClient, vous devez définir la propriété BaseURL, qui est le point d'entrée primaire d'accès à une API. Dans ce cas, la valeur de BaseURL est définie sur http://www.songsterr.com/a/ra/. Toutes les requêtes adressées à ce service doivent utiliser cette URL de base. Aucune autre configuration n'est nécessaire pour le composant client.

Vous définissez ensuite les propriétés du composant RESTRequest. La propriété Resource de ce composant contient la chaîne requête réelle. Dans cet exemple, nous souhaitons effectuer des requêtes simples sur des chansons en utilisant un modèle. Selon la documentation, notre chaîne de requête doit être du type 'songs.json' (il est aussi possible d'utiliser les formats 'songs.xml' et 'songs.plist' pour obtenir des réponses dans les formats xml et plist, respectivement). Pour entrer un modèle, vous devez ajouter un paramètre pattern à TRESTRequest. Pour le <pattern>, vous pouvez par exemple insérer Madonna ou tout autre chanteur de votre choix.

Et voilà ! Vous pouvez maintenant exécuter la requête dans l'EDI en cliquant avec le bouton droit sur le composant RESTRequest et en sélectionnant Exécuter dans le menu contextuel. Après un moment, vous pouvez constater que la propriété 'content' du composant RESTResponse a été mise à jour avec les données provenant du service. Vous pouvez utiliser LiveBindings pour connecter cette propriété à un composant TMemo ou TEdit.

Notez que : vous devez faire une requête GET et le modèle fait partie de l'URL. Selon les normes HTTP, cette valeur doit être encodée au format URL si elle contient des espaces ou d'autres caractères spéciaux. Vous pouvez le faire vous-même ou simplement utiliser un paramètre de requête de type 'segment URL'.

Revenons maintenant aux paramètres RESTRequest. Changez le paramètre pattern par 'Rolling Stones'. Ensuite, exécutez à nouveau la requête. Vous verrez que vous n'avez pas à vous soucier de l'espace dans le nom du groupe. Celui-ci est automatiquement encodé.

De plus amples informations ainsi qu'un projet exemple illustrant l'accès à un service API simple sont disponibles dans Tutoriel : Utilisation de la bibliothèque client REST pour accéder aux services Web basés sur REST

Accès à l'API de Twitter

L'exemple Twitter montre comment établir une connexion à l'API de Twitter en utilisant OAuth1 comme mécanisme d'authentification. Le flux de travail de l'authentificateur OAuth1 est également décrit sur la page suivante : https://dev.twitter.com/docs/auth/oauth.

Le processus d'authentification se décompose en deux étapes : vous devez d'abord demander un code d'authentification. Cette étape requiert l'action de l'utilisateur, qui doit saisir son mot de passe. La seconde étape consiste à demander le token d'accès et se fait en toute transparence pour l'utilisateur.

Prérequis : Enregistrement d'une application

Avant d'accéder à l'API de Twitter en utilisant votre propre client, vous devez enregistrer ce client en tant qu'application sur la console développeurs Twitter. Pour cela, vous pouvez accéder à la page suivante : https://dev.twitter.com/apps.

Après avoir enregistré l'application, vous obtenez une clé 'consumer-key' et un secret 'consumer-secret' que vous utiliserez ultérieurement pour l'authentification.


Etape n°1 : Obtenir un token requête et un code d'authentification

C'est la première partie du flux de travail de l'authentificateur OAuth1. Vous envoyez votre consumer-key et votre consumer-secret au point d'entrée des tokens requête de Twitter. En réponse, vous obtenez immédiatement le token requête et le secret du token requête. Ces deux valeurs vous seront utiles ultérieurement. Renvoyez alors le token requête à Twitter, en utilisant cette fois le point de terminaison des tokens requête. Vous devez pour cela utiliser une vue Web, car l'interaction utilisateur est requise à ce stade. (Remarque : Twitter propose également une méthode appelée “x-auth” qui ne nécessite pas la vue Web, mais cela concerne uniquement les applications autorisées, comme le client Twitter officiel.)

Dans la vue Web, Twitter affiche un code de vérification à six chiffres. Cette vue est très restrictive : le code ne peut pas être sélectionné et copié dans le presse-papiers - vous devez transférer les chiffres manuellement.

Etape n°2 : Obtenir un token d'accès

En utilisant le code de vérification de l'étape n 1, adressez une requête au point de terminaison des tokens requête. Vous obtenez en retour un token d'accès et un secret de token d'accès. A présent, le token requête et le secret associé (issus de l'étape n 1) ne sont plus valides et leurs valeurs doivent être effacées - elles ne peuvent tout simplement pas être réutilisées.

Etape n°3 : Envoyer une mise à jour de statut ('Tweet')

L'authentificateur OAuth1 a désormais toutes les données nécessaires pour transmettre une requête à l'API de Twitter. Vous pouvez donc envoyer votre première mise à jour de statut ('Tweet').

Accès à l'API de Google Tasks

L'exemple Google montre comment accéder à l'API de Google en utilisant OAuth2 comme mécanisme d'authentification. Le flux de travail de l'authentificateur OAuth2 est également décrit sur la page suivante : https://developers.google.com/accounts/docs/OAuth2InstalledApp?hl=de.

Le processus d'authentification se décompose en deux étapes : vous devez d'abord demander un code d'authentification. Cette étape requiert l'action de l'utilisateur, qui doit saisir son mot de passe. La seconde étape consiste à demander le token d'accès et se fait en toute transparence pour l'utilisateur.


Prérequis : Enregistrement d'une application

Avant d'accéder à l'API de Google en utilisant votre propre client, vous devez enregistrer ce client en tant qu'application sur la console API de code Google. Pour cela, vous pouvez accéder à la page suivante : https://code.google.com/apis/console?hl=en#access.

Lorsque vous enregistrez l'app, vous devez choisir les API auxquelles vous souhaitez accéder. Dans cet exemple, vous sélectionnez et activez simplement 'Tasks API'. N'oubliez pas que vous ne pourrez pas ensuite accéder à une API qui n'a pas été activée pour votre application. Après avoir enregistré l'application, vous obtenez un identifiant 'client-id' et un secret 'client-secret' que vous utiliserez ultérieurement pour l'authentification.


Etape n°1 : Demander un code d'authentification

La première étape de ce flux de travail consiste à obtenir un code d'authentification. Pour cela, ouvrez une vue Web sur une URL spécifique à Google. Cela permet les opérations suivantes :

  • response_type=code
    Pour les apps natives, Google exige que ce paramètre ait une valeur de “code”.
  • client_id={CLIENTID}
    A cet endroit, nous devons inclure l'ID client reçu après l'enregistrement de notre application.
  • redirect_uri=urn:ietf:wg:oauth:2.0:oob
    A cet endroit, vous utilisez l'URI constant fourni par Google car vous utilisez un client natif et qu'il n'existe - contrairement aux applications Web - aucune page de lancement vers laquelle l'utilisateur peut être redirigé.
  • login_hint=user@example.com (facultatif)
    Pour que le flux de travail soit plus simple pour l'utilisateur, Google vous autorise à fournir une aide à la connexion. Cela peut être l'adresse email de l'utilisateur automatiquement insérée dans le champ d'identification pour que l'utilisateur n'ait plus qu'à entrer son mot de passe.

Pour cet exemple, votre URL complète est donc construite ainsi :

 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

Etape n°2 : Demander un token d'accès

Pour cette étape, vous avez besoin d'un composant TRESTClient et d'un composant TRESTRequest :

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

Ensuite, vous créez et configurez l'objet requête. Il contient les paramètres suivants requis par Google :

  • code={AUTHCODE_FROM_STEP#1}
  • client_id={CLIENTID}
    ID client de votre application, tel qu'indiqué dans la console API.
  • client_secret={CLIENTSECRET}
    Secret client de votre application, tel qu'indiqué dans la console API.
  • redirect_uri=urn:ietf:wg:oauth:2.0:oob
    A cet endroit, nous utilisons l'URI constant fourni par Google car nous utilisons un client natif et qu'il n'existe - contrairement aux applications Web - aucune page de lancement vers laquelle l'utilisateur peut être redirigé.
  • grant_type=authorization_code
    Comme défini dans la spécification OAuth 2.0, ce champ doit contenir une valeur de “authorization_code”.

Dans le code, la requête d'accès doit ressembler à ceci :

  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);

Une fois l'objet requête préparé, vous pouvez l'exécuter en utilisant le client :

  LClient.Execute(LRequest);

Une fois la requête exécutée correctement, vous pouvez obtenir un token d'accès fourni dans le contenu de la réponse. Vous pouvez extraire cette valeur en interrogeant l'objet réponse :

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

Vous devez enregistrer la valeur du token d'accès car elle vous sera nécessaire pour toutes les requêtes consécutives adressées à l'API de Google.

Accès à l'API de Facebook

L'exemple Facebook montre comment accéder à l'API Graph de Facebook en utilisant OAuth2. La première étape consiste à obtenir le token d'accès. Ce token d'accès sera la clé qui vous permettra ensuite d'accéder à l'API Graph. Puis, lorsque vous interrogerez l'API, vous n'aurez qu'à utiliser ce token d'accès pour l'authentification.

Prérequis : Enregistrement d'une application

Avant d'accéder à l'API de Facebook en utilisant votre propre client, vous devez enregistrer ce client en tant qu'application sur Facebook. Pour cela, vous pouvez accéder à la page suivante : https://developers.facebook.com/apps.

Après avoir enregistré l'application, vous obtenez un identifiant 'app ID', que vous utiliserez ultérieurement pour l'authentification. Notez que cet identifiant 'app ID' est parfois appelé 'client ID'.


Etape n°1 : Demander un token d'accès

Facebook fournit différents moyens de demander un token d'accès. Etant donné que vous n'utilisez pas l'un des SDK fournis par Facebook, nous vous recommandons de choisir la méthode 'Login Flow for Web (without JavaScript SDK)'. La documentation est accessible à la page Web suivante : https://developers.facebook.com/docs/facebook-login/login-flow-for-web-no-jssdk/.

Pour demander votre token d'accès, vous devez ouvrir une vue Web sur une URL Facebook. L'URL de base est https://www.facebook.com/dialog/oauth. Vous devez ajouter plusieurs paramètres, mais seuls les deux premiers sont obligatoires. Toutefois, les deux autres sont très utiles :

  • client_id={CLIENTID}
    A cet endroit, vous devez inclure l'ID client reçu après l'enregistrement de votre application. Il est appelé 'App-ID'.
  • redirect_uri=https://www.facebook.com/connect/login_success.html
    A cet endroit, vous utilisez l'URI constant fourni par Facebook car vous utilisez un client natif et qu'il n'existe - contrairement aux applications Web - aucune page de lancement vers laquelle l'utilisateur peut être redirigé.
  • response_type=token
    Facebook exige que les applications natives utilisent 'token' comme valeur de 'response type'. Cela force le mécanisme de connexion à fournir le token d'accès en tant que partie additionnelle de l'URI de redirection.

Pour cet exemple, notre URL complète est donc construite ainsi :

  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 ');

Le token d'accès est valide pendant environ deux heures. Il peut être actualisé en arrière plan sans demander à l'utilisateur de s'authentifier à nouveau. Pour de plus amples informations, voir https://developers.facebook.com/docs/facebook-login/access-tokens/#extending.

Etape n°2 : Extraire les informations relatives à l'utilisateur

Vous avez besoin des composants suivants : TRESTCient, TRESTRequest, TRESTResponse et un authentificateur TOAuth2Authenticator.

Là encore, la première étape consiste à créer le client et l'authentificateur et à les connecter :

 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;

Ensuite, vous devez préparer la requête. L'URI de ressource a été généré en utilisant le Graph Explorer de Facebook. Cet URI renvoie votre nom, votre date d'anniversaire (au cas où vous ne vous en rappeliez pas...) ainsi que les noms de vos dix premiers contacts ('amis'). Vous pouvez accéder au Graph Explorer sur la page Web suivante : 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)';

Et voilà ! Vous pouvez maintenant utiliser le client pour exécuter la requête :

  LClient.Execute(LRequest);

Vous pouvez maintenant trouver le contenu encodé au format JSON dans l'objet réponse du client. Notez que cet objet réponse a été créé à la volée par le client parce que vous n'en avez pas fourni.

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

Transformation d'une réponse dans un ensemble de données

La réponse au format JSON d'un service peut être transformée en classe descendante de TDataSet. Pour cela, les données doivent bien entendu être dans un format pouvant être transféré vers un ensemble de données. Il peut s'agir d'un objet JSON ou d'un tableau d'objets JSON. Chaque objet est un nouvel enregistrement dans l'ensemble de données. Les propriétés des objets JSON forment généralement les colonnes de l'ensemble de données.

Voir aussi