Skip to main content

​
Standard v1.1 comparé à X API v2

Si vous avez déjà travaillé avec les endpoints standard v1.1 GET users/show et GET users/lookup, l’objectif de ce guide est de vous aider à comprendre les points communs et les différences entre les endpoints standard v1.1 et les endpoints de recherche d’utilisateurs de X API v2.
  • Similarités
    • Contexte utilisateur OAuth 1.0a
    • Limites d’utilisateurs par requête
  • Différences
    • URL des endpoints
    • Exigences relatives aux App et aux projets
    • Format des données de réponse
    • Paramètres de requête

​
Similarités

Méthode d’authentification OAuth 1.0a en contexte utilisateur L’endpoint standard prend en charge OAuth 1.0a User Context, tandis que les nouveaux endpoints de recherche d’utilisateurs de la X API v2 prennent en charge à la fois OAuth 1.0a User Context et App only. Par conséquent, si vous utilisiez auparavant l’un des endpoints standard v1.1 de recherche d’utilisateurs, vous pouvez continuer à utiliser la même méthode d’authentification en migrant vers la version X API v2. Selon la bibliothèque ou le package d’authentification que vous utilisez, l’authentification App only est probablement le moyen le plus simple pour commencer et peut être configurée au moyen d’un simple en-tête de requête. Pour savoir comment générer un jeton d’accès App only, consultez ce guide App only. Limites d’utilisateurs par requête L’endpoint standard v1.1 GET users/lookup vous permet de spécifier 100 utilisateurs par requête. Il en va de même pour les endpoints GET /users et GET /users/by. Pour spécifier 100 utilisateurs, vous devez transmettre le paramètre ids (GET /users) ou le paramètre username (GET /users/by) en tant que paramètre de requête, et inclure la liste des id/noms d’utilisateur dans une liste séparée par des virgules.

​
Différences

URLs des endpoints Exigences relatives aux Apps et aux Projects Les endpoints X API v2 nécessitent l’utilisation d’identifiants provenant d’une developer App associée à un Project lors de l’authentification de vos requêtes. Tous les endpoints X API v1.1 peuvent utiliser des identifiants provenant d’Apps ou d’Apps associées à un Project. Format des données de réponse L’une des plus grandes différences entre les versions d’endpoint standard v1.1 et X API v2 concerne la façon dont vous sélectionnez les champs renvoyés dans votre payload. Pour les endpoints standard, vous recevez de nombreux champs de réponse par défaut, puis vous avez la possibilité d’utiliser des paramètres pour identifier quels champs ou ensembles de champs doivent être renvoyés dans le payload. La version X API v2 ne fournit que les champs user id, name et username par défaut. Pour demander des champs ou des objets supplémentaires, vous devrez utiliser les paramètres fields et expansions. Tous les champs user que vous demandez à partir de cet endpoint seront renvoyés dans l’objet user principal. Tout objet Publication étendu et ses champs seront renvoyés dans un objet includes au sein de votre réponse. Vous pouvez ensuite faire correspondre les objets étendus à l’objet user en faisant correspondre les id présents à la fois dans l’objet user et dans l’objet Publication étendu. Nous vous encourageons à en savoir plus sur ces nouveaux paramètres dans leurs guides respectifs, ou en lisant notre guide sur comment utiliser les fields et expansions. Nous avons également préparé un guide de migration du format de données qui peut vous aider à faire correspondre les champs standard v1.1 aux nouveaux champs v2. Ce guide vous fournira également le paramètre d’expansion et de champ spécifique que vous devrez transmettre avec votre requête v2 pour renvoyer des champs spécifiques. En plus des changements concernant la façon dont vous demandez certains champs, X API v2 introduit également de nouveaux modèles JSON pour les objets renvoyés par les API, y compris les objets Post et user.
  • Au niveau racine JSON, les endpoints standard renvoient des objets Publication dans un tableau statuses, tandis que X API v2 renvoie un tableau data.
  • Au lieu de faire référence aux « statuses » Retweeted et Quoted, le JSON de X API v2 fait référence aux Tweets Retweeted et Quoted. De nombreux champs hérités et obsolètes, tels que contributors et user.translator_type, sont supprimés.
  • Au lieu d’utiliser à la fois favorites (dans l’objet Publication) et favourites (dans l’objet user), X API v2 utilise le terme like.
  • X adopte la convention selon laquelle les valeurs JSON sans valeur (par exemple, null) ne sont pas écrites dans le payload. Les attributs de Publication et de user ne sont inclus que s’ils ont une valeur non nulle.
Nous avons également introduit un nouvel ensemble de champs dans l’objet Post, notamment :
  • Un champ conversation_id
  • Deux nouveaux champs annotations, dont context et entities
  • Plusieurs nouveaux champs metrics
  • Un nouveau champ reply_setting, qui indique qui peut répondre à une Publication donnée
Paramètres de requête Les paramètres de requête standard v1.1 suivants ont des équivalents dans X API v2 :
StandardX API v2
user_idids
screen_nameusername
Il existe également un ensemble de paramètres de requête standard pour la recherche d’utilisateurs non pris en charge dans X API v2 :
StandardCommentaire
include_entitiesCe paramètre est utilisé pour supprimer le nœud entities du payload de la Publication. Il a été remplacé par la fonctionnalité additive basée sur fields et expansions.

​
Exemples de code

Les exemples suivants montrent les endpoints standard de la v1.1 et leurs équivalents en v2. Recherche d’un seul utilisateur : v1.1 GET users/show → v2 GET /users/by/username/:username
cURL (v1.1)
curl --request GET \
  --url 'https://api.x.com/1.1/users/show.json?screen_name=XDevelopers' \
  --header 'Authorization: Bearer $ACCESS_TOKEN'
Recherche de plusieurs utilisateurs : v1.1 GET users/lookup → v2 GET /users/by
cURL (v1.1)
curl --request GET \
  --url 'https://api.x.com/1.1/users/lookup.json?screen_name=XDevelopers,X,XAPI' \
  --header 'Authorization: Bearer $ACCESS_TOKEN'