L'API Yuno utilise le schéma de sécurité ApiKey pour authentifier les requêtes HTTP. Ces clés sont des identifiants d'accès composés de caractères alphanumériques qui autorisent l’utilisation de fonctionnalités spécifiques de notre API.
Les requêtes doivent inclure des en têtes d’autorisation tels que public-api-key, private-secret-key et X-idempotency-key. Vous pouvez retrouver vos identifiants, public-api-key et private-secret-key, dans la section développeurs du Tableau de bord du commerçant Yuno. D'autre part, le X-idempotency-key est composé de 64 caractères au maximum. Consultez la section Idempotency pour plus d'informations.
Veuillez consulter la description de chaque requête pour obtenir les détails spécifiques des en-têtes d’autorisation requis.
L'extrait de code suivant montre un exemple de requête, y compris les en-têtes d'authentification.
curl --request <Method> \
--url <URL> \
--header 'X-Idempotency-Key: <Your X-Idempotency-Key>' \
--header 'accept: application/json' \
--header 'content-type: application/json' \
--header 'private-secret-key: <Your private-secret-key>' \
--header 'public-api-key: <Your public-api-key>'
Gardez vos clés en sécuritéNe partagez jamais vos clés secrètes d’API dans des espaces publics comme Github, Bitbucket, etc., car cela pourrait permettre des appels malveillants à l’API.
Idempotency
Du point de vue d’un service RESTful, l’idempotence est la capacité d’effectuer plusieurs fois la même requête et de recevoir toujours la même réponse. Cette fonctionnalité est utile lorsqu’une requête échoue à cause d’un problème de communication sans réponse concluante : il suffit de relancer la requête en utilisant la même clé d’idempotence s’il y a un souci de connexion lors d’un appel spécifique. Notre API garantit que le second appel n’échouera pas.
Il est essentiel, pour l’idempotence, de transmettre un nonce dans la requête API concernée : le marchand doit donc générer un identifiant unique à inclure dans l’en-tête de la requête. Ce nonce peut également servir à identifier une transaction spécifique.
Le champ X-Idempotency-Key d’une transaction ainsi que le statut retourné pour la création de cette commande sont enregistrés par le système d’idempotence de Yuno. Pour garantir que les requêtes effectuées dans les 24 heures suivant la première commande ne soient pas créées deux fois, nous conservons ces données, quel que soit le résultat de la transaction (capturée, autorisée ou échouée). Ainsi, les réponses aux requêtes reçues avec la même clé correspondront à une seule transaction.
Requêtes avec la même cléIl est important de souligner que l’API ne générera qu’une seule demande, même si deux requêtes sont envoyées avec la même clé dans l’en-tête et des contenus différents dans le corps.
Dans certains cas, il est possible que plusieurs requêtes soient envoyées simultanément. Par conséquent, l’application peut recevoir une deuxième requête avant d’avoir répondu à la première. Lorsque cela se produit, la seconde requête sera rejetée avec le code 409 - Conflict, indiquant qu’un appel est déjà en cours pour la même X-Idempotency-Key.
L'API Yuno n'enregistre pas les clés en cas d’échec de la requête, quelle qu’en soit la raison. De plus, l’API fournit une erreur de type 400 indiquant qu’il y a un problème avec la requête, ce qui permet au marchand de corriger la demande et de la renvoyer. Il en va de même pour les cas où un code d’erreur 500 est retourné.