Gérer les mises en sourdine

Gérer les mises en sourdine : standard v1.1 comparé à X API v2

Si vous avez utilisé les endpoints standard v1.1 POST mutes/users/create et POST mutes/users/destroy, l’objectif de ce guide est de vous aider à comprendre les similarités et les différences entre les endpoints de gestion des mises en sourdine du standard v1.1 et ceux de X API v2.

• Similarités
  • Contexte utilisateur OAuth 1.0a
• Différences
  • URL des endpoints
  • Exigences relatives aux App et aux Projets
  • Méthodes HTTP
  • Paramètres de requête

Similarités

Méthode d’authentification OAuth 1.0a User Context

Les deux versions de l’endpoint prennent en charge OAuth 1.0a User Context. Par conséquent, si vous utilisiez auparavant l’un des endpoints standard v1.1 dédiés à la gestion des masquages, vous pouvez continuer à utiliser la même méthode d’authentification si vous migrez vers la version X API v2.

Différences

URL d’endpoint

• Endpoints standard v1.1 :
  • POST https://api.x.com/1.1/mutes/users/create.json (mettre un utilisateur en sourdine)
  • POST https://api.x.com/1.1/mutes/users/destroy.json (annuler la mise en sourdine d’un utilisateur)
• Endpoint X API v2 :
  • POST https://api.x.com/2/users/:id/muting (mettre un utilisateur en sourdine)
  • DELETE https://api.x.com/2/users/:source_user_id/muting/:target_user_id (annuler la mise en sourdine d’un utilisateur)

Exigences pour les Apps et les Projets

Les endpoints X API v2 exigent que vous utilisiez des identifiants issus d’une App développeur qui est associée à un Project lors de l’authentification de vos requêtes. Tous les endpoints X API v1.1 standard peuvent utiliser des identifiants provenant d’Apps ou d’Apps associées à un Project.

Paramètres de requête

Les paramètres de requête standard v1.1 suivants ont des équivalents dans X API v2 :

Standard v1.1	X API v2
user_id	target_user_id
screen_name	Aucun équivalent

Veuillez noter que les paramètres standard v1.1 sont transmis en tant que paramètres de requête, tandis que les paramètres X API v2 sont transmis en tant que paramètres dans le corps de la requête (pour l’endpoint POST) ou en tant que paramètres de chemin (pour l’endpoint DELETE).

De plus, l’id de l’utilisateur qui met en sourdine un utilisateur cible n’est pas nécessaire lors de l’utilisation des endpoints standard v1.1, car les jetons d’accès transmis avec le contexte utilisateur OAuth 1.0a permettaient de déterminer quel utilisateur initiait l’action de mise en sourdine ou d’annulation de la mise en sourdine.

---

Exemples de code

Mettre un utilisateur en sourdine (v2)

cURL

shellscript

curl -X POST "https://api.x.com/2/users/123456789/muting" \
  -H "Authorization: OAuth ..." \
  -H "Content-Type: application/json" \
  -d '{"target_user_id": "2244994945"}'

Ne plus masquer un utilisateur (v2)

cURL

shellscript

curl -X DELETE "https://api.x.com/2/users/123456789/muting/2244994945" \
  -H "Authorization: OAuth ..."