Gérer les mises en sourdine : standard v1.1 comparé à 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
Différences
- 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)
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
Ne plus masquer un utilisateur (v2)
cURL