Meilleures pratiques

Gestion des connexions

Ouvrez une seule connexion WebSocket et réutilisez-la pour chaque requête et abonnement, plutôt que d'ouvrir une connexion par appel. Multiplexez les requêtes sur le socket partagé et associez chaque réponse à sa requête à l'aide de req_id.

Lorsque la connexion est interrompue, reconnectez-vous avec un backoff exponentiel (par exemple 1s, 2s, 4s, 8s, plafonné) accompagné d'un léger jitter, plutôt que de réessayer en boucle serrée. Envoyez un ping périodique pour maintenir la connexion active et détecter rapidement les déconnexions silencieuses.

// keepalive: send a ping on an interval over the shared socket
setInterval(() => socket.send(JSON.stringify({ ping: 1 })), 30000);

Limitation du débit et contrôle des requêtes

Limitez le débit des requêtes sortantes pour rester dans les limites de débit de l'API. Mettez les appels en file d'attente et espacez-les au lieu d'envoyer de grandes rafales, et appliquez un anti-rebond aux actions déclenchées par l'utilisateur afin qu'une seule interaction ne génère pas une multitude de requêtes.

Si vous êtes soumis à une limitation de débit, attendez de manière exponentielle avant de réessayer, en augmentant le délai après chaque rejet. Privilégiez les abonnements au polling pour les données qui se mettent à jour en continu, afin que le serveur pousse les modifications plutôt que vous ne les redemandiez.

Lorsque vous réessayez une opération non idempotente telle qu'un achat ou un retrait, fournissez un identifiant de requête afin de pouvoir interroger son statut final et réconcilier le résultat, plutôt que de soumettre à nouveau aveuglément et de risquer un doublon.

Pour les chiffres eux-mêmes — les limites de requêtes par IP et par compte, ainsi que les budgets partagés sur lesquels s'appuient les groupes d'appels WebSocket — consultez Limites.

Authentification et hygiène des tokens

Authentifiez une connexion une seule fois en envoyant authorize avec un token valide avant d'effectuer des requêtes liées au compte. Utilisez des tokens avec les privilèges minimaux requis par la tâche en ne demandant que les portées dont vos points de terminaison ont besoin, comme trade ou account_manage ; un token ne disposant pas d'une portée requise est rejeté avec une erreur 403.

Pour les applications destinées aux utilisateurs, utilisez le flux Authorization Code OAuth 2.0 avec PKCE plutôt que d'intégrer des tokens. Effectuez toujours l'échange de tokens sur votre backend, et non dans le navigateur, et validez le paramètre state sur le callback avant d'utiliser le code d'autorisation. Les codes d'autorisation sont à usage unique et de courte durée ; échangez-les immédiatement et ne les stockez ni ne les consignez jamais. Générez un nouveau code_verifier et un nouveau state pour chaque requête, et effacez-les une fois l'échange réussi. Les tokens d'accès sont de courte durée, généralement une heure ; gérez leur expiration en actualisant le token ou en relançant le flux d'autorisation plutôt que de supposer qu'il reste valide. Consultez le guide OAuth 2.0 pour l'implémentation complète.

N'intégrez jamais de tokens API à longue durée de vie dans du code côté client, des dépôts publics ou des artefacts de build. Stockez les secrets côté serveur, renouvelez-les régulièrement et révoquez tout token susceptible d'avoir été exposé.

// authenticate the connection before account-scoped calls
socket.send(JSON.stringify({ authorize: "<your-token>" }));

Gestion des erreurs et nettoyage des abonnements

Inspectez toujours le champ error de chaque réponse avant d'utiliser ses données, et consignez le code et le message d'erreur dans vos propres journaux. Associez les réponses aux requêtes via req_id afin qu'un échec soit attribué au bon appel.

Libérez les abonnements dont vous n'avez plus besoin : utilisez forget avec un identifiant d'abonnement pour arrêter un flux unique, et forget_all par type de flux pour arrêter tous les flux de ce type. Le nettoyage évite les abonnements non libérés et le trafic inutile.

// stop a single stream by its subscription id
socket.send(JSON.stringify({ forget: subscriptionId }));
// stop every stream of a given type
socket.send(JSON.stringify({ forget_all: "ticks" }));

Cycle de vie du contrat

Un trade suit un cycle de vie court : demandez un prix avec proposal, exécutez-le avec buy, suivez la position ouverte avec proposal_open_contract, et clôturez-la avec sell ou laissez-la se régler à l'expiration. Achetez sur la base d'une nouvelle proposition plutôt que d'une cotation obsolète — les prix sont éphémères. Transmettez un prix maximum dans l'appel buy afin que les variations entre la cotation et l'exécution ne vous imposent pas un remplissage moins favorable.

Suivez chaque contrat ouvert en vous abonnant à proposal_open_contract plutôt qu'en interrogeant portfolio. L'abonnement envoie les mises à jour du cours au comptant et du profit, et bascule les indicateurs is_sold et is_expired dès que le contrat est réglé.

Lorsque is_sold devient vrai, appelez forget sur cet abonnement afin de libérer le flux et d'éviter les fuites d'abonnements au fil du temps. Si une réponse buy est perdue ou expire, effectuez un rapprochement en recherchant la position dans portfolio ou proposal_open_contract avant de réessayer, afin de ne pas acheter deux fois.

Avant de clôturer prématurément, vérifiez les indicateurs propres au contrat — utilisez sell uniquement lorsque is_valid_to_sell est vrai, et utilisez cancel uniquement dans la fenêtre d'annulation de transaction pour les trades pris en charge. Pour les types de contrats pris en charge, définissez le stop loss et le take profit avec contract_update afin que les sorties se fassent côté serveur plutôt que de surveiller le flux et de vendre manuellement.

// track an open contract, then release the stream once it settles
socket.send(JSON.stringify({
  proposal_open_contract: 1,
  contract_id: contractId,
  subscribe: 1,
}));

// on each update, when data.proposal_open_contract.is_sold is true:
//   socket.send(JSON.stringify({ forget: subscriptionId }));

Pagination

Pour les points de terminaison qui renvoient des listes, récupérez les données par pages plutôt que de tout charger d'un coup. Utilisez les paramètres limit et offset pour parcourir les résultats, et gardez des tailles de pages raisonnables afin de réduire la latence et la pression sur la mémoire.

Continuez à demander les pages suivantes jusqu'à ce qu'une page retourne moins de lignes que la limite que vous avez demandée, ce qui indique que vous avez atteint la fin du jeu de données.