Qu'est-ce qu'une URL de rappel par rapport à une API?
J'ai parcouru le net et je n'arrive pas à comprendre l'idée d'une URL de rappel. Dans mon cas, j'ai quelques URL de rappel que je dois définir moi-même. Une "adresse de rappel par défaut" est une application populaire. Qu'est-ce que c'est exactement? Pouvez-vous donner un exemple en anglais simple?
Une URL de rappel sera invoquée par la méthode API que vous appelez une fois l'opération terminée. Donc si vous appelez
POST /api.example.com/foo?callbackURL=http://my.server.com/bar
Ensuite, lorsque /foo est terminé, il envoie une demande à http://my.server.com/bar. Le contenu et la méthode de cette demande vont varier. Consultez la documentation de l'API à laquelle vous accédez.
Pensez-y comme une lettre. Parfois, vous recevez une lettre, vous demandant de remplir un formulaire, puis de le renvoyer dans une enveloppe pré-adressée, qui se trouve dans l'enveloppe d'origine contenant le formulaire.
Une fois que vous avez terminé de remplir le formulaire, vous le mettez dans l’enveloppe de retour fournie et vous le renvoyez.
Le callbackUrl est comme cette enveloppe de retour. Vous dites essentiellement que je vous envoie ces données. Une fois que vous avez terminé, je suis sur ce callbackUrl en attente de votre réponse. L’API traitera donc les données que vous avez envoyées, puis examinera le rappel pour vous envoyer la réponse.
Ceci est utile car il peut parfois prendre beaucoup de temps pour traiter certaines données et il n’a aucun sens de demander à l’appelant d’attendre une réponse. Par exemple, supposons que votre API autorise les utilisateurs à lui envoyer des documents et à les analyser. Ensuite, vous envoyez un rapport après. Le scan pourrait prendre environ 3 minutes. L'utilisateur ne peut pas attendre 3 minutes. Ainsi, vous reconnaissez que vous avez obtenu le document et laissez l'appelant poursuivre les autres opérations pendant que vous effectuez l'analyse, puis utilisez callbackUrl lorsque vous avez terminé pour lui indiquer le résultat de l'analyse.
Si vous utilisez l'URL de rappel, l'API peut se connecter à l'URL de rappel et envoyer ou recevoir des données. Cela signifie que l'API peut se connecter à vous plus tard (après l'appel de l'API).
Exemple
- VOUS envoyez des données en utilisant une requête à API
- API envoie des données via la deuxième demande à YOU
La définition exacte devrait être dans la documentation de l'API.
C'est un mécanisme permettant d'invoquer une API de manière asynchrone. La séquence est la suivante
- votre application appelle l'URL, en passant en paramètre l'URL de rappel
- l'API répond avec un code http 20x (201 je suppose, mais référez-vous à la documentation de l'API)
- l'API fonctionne sur votre demande pendant un certain temps
- l'API appelle votre application pour vous donner les résultats, à l'adresse URL de rappel.
Vous pouvez donc appeler l’API et indiquer à votre utilisateur que la requête est en cours de «traitement» ou «acquise», puis mettre à jour le statut lorsque vous recevez la réponse de l’API.
J'espère que ça a du sens .- G
Un autre cas d'utilisation pourrait être quelque chose comme OAuth, il peut ne pas être appelé directement par l'API, mais l'URL de rappel sera appelée par le navigateur après la fin de l'authentification avec le fournisseur d'identité.
Normalement, après la clé de l'utilisateur final dans le mot de passe du nom d'utilisateur, le fournisseur de service d'identité déclenchera une redirection du navigateur vers votre URL de "rappel" avec le code d'authentification temporaire, par exemple.
https://example.com/callback?code=AUTHORIZATION_CODE
Ensuite, votre application pourrait utiliser ce code d'autorisation pour demander un jeton d'accès au fournisseur d'identité, dont la durée de vie est beaucoup plus longue.