Avalanche Francophone
  • Documentation du développeur
  • Apprendre
    • Aperçu de la plateforme
      • Staking
      • Frais de transaction
    • Les bases de la blockchain
    • FAQ
    • Forum
    • Communauté
  • Créer
  • Pour commencer: exécuter un nœud Avalanche
  • Notes de version
    • Alertes par email
    • Notes de mise à jour d'AvalancheGo
    • Notes de mise à jour d'Ortelius
  • Tutoriels
    • Plateforme
      • Créer une nouvelle blockchain
      • Créer un Réseau Local Testnet
      • Créer un sous-réseau (subnet)
      • Créer une Machine Virtuelle (VM)
      • Configurez votre Ledger Nano S avec Avalanche
      • Transférer de l'AVAX entre la X-Chain et la C-Chain
      • Transférer de l'AVAX entre la X-Chain et la P-Chain
    • Nœuds et mise en jeu
      • Ajouter un validateur
      • Maintenir un nœud Avalanche
      • Exécutez un nœud Avalanche et devenez validateur
      • Exécuter un nœud Avalanche avec Oracle VM VirtualBox
      • Exécutez un nœud Avalanche avec un Raspberry Pi 4
      • Exécutez un nœud Avalanche et faites une mise en jeu avec le portefeuille
      • Exécuter un nœud Avalanche avec OVH
      • Exécuter un nœud Avalanche avec Amazon Web Services (AWS)
      • Exécuter un nœud Avalanche avec Microsoft Azure
      • Exécuter un nœud Avalanche sous Linux à l'aide du script d'installation
      • Configuration du monitoring des nœuds
      • Mise en jeu d'AVAX, en validant ou délégant via le portefeuille Avalanche
      • Déléguer à un nœud
      • Sécurisation d'un serveur VPS
      • Mettez à niveau votre nœud AvalancheGo
    • Contrats intelligents
      • Déployer un contrat intelligent en utilisant Remix et MetaMask
      • Utilisation de Truffle avec la C-Chain d'Avalanche
    • Actifs Numériques Intelligents
      • Créer un token ERC-20
      • Créer un actif à capitalisation fixe
      • Créer un actif à capitalisation variable
      • Création d'un NFT - Partie 1
      • Créez des NFT avec le portefeuille Avalanche
      • Utilisez les Wrapped AVAX (WAVAX) sur Avalanche
  • AvalancheGo APIs
    • Émettre des appels d'API
    • Platform API (P-Chain)
    • EVM API (C-Chain)
    • AVM API (X-Chain)
    • Appels d'API obsolètes
    • API Admin
    • API Auth
    • API Health
    • API Info
    • API IPC
    • API Keystore
    • API Metrics
    • API Timestamp
  • Outils
    • AvalancheJS
      • Créer un actif sur la X-Chain
      • Management des clés sur la X-Chain
      • Envoyer un actif sur la X-Chain
      • API
    • Avash
    • Ortelius
  • Références
    • AVM Transaction Format
    • Command Line Interface
    • Coreth Atomic Transaction Format
    • Cryptographic Primitives
    • Network Protocol
    • Serialization Primitives
    • Platform Transaction Format
  • Papiers
Propulsé par GitBook
Sur cette page
  • Endpoint
  • JSON RPC Formatted APIs
  • Faire une requête JSON RPC
  • Réponse d'une requête JSON RPC (success)
  • Réponse d'une requête JSON RPC (error)
  • Autres formats d'API
  • Envoi et réception d'octets

Cet article vous a-t-il été utile ?

  1. AvalancheGo APIs

Émettre des appels d'API

Ce guide explique comment passer des appels aux API exposées par les nœuds Avalanche.

PrécédentAvalancheGo APIsSuivantPlatform API (P-Chain)

Dernière mise à jour il y a 4 ans

Cet article vous a-t-il été utile ?

Endpoint

Un appel d'API est effectué vers un endpoint, qui est une URL. La base de l'URL est toujours :

[node-ip]:[http-port]

où

  • node-ip est l'adresse IP du nœud auquel l'appel est destiné.

  • http-port est le port sur lequel le nœud écoute les appels HTTP. Ceci est spécifié par l'argument de ligne de commande http-port (valeur par défaut 9650).

Par exemple, l'URL de base pourrait ressembler à ceci: 127.0.0.1:9650.

La documentation de chaque API spécifie à quel endpoint un utilisateur doit effectuer des appels pour accéder aux méthodes de l'API.

JSON RPC Formatted APIs

Plusieurs API intégrées utilisent le format pour décrire leurs demandes et leurs réponses. Ces API incluent l'API Platform et l'API X-Chain.

Faire une requête JSON RPC

Supposons que nous voulions appeler la méthode getTxStatus de l'. La documentation de l'API X-Chain nous indique que le point de terminaison de cette API est /ext /bc /X.

Cela signifie que le endpoint auquel nous envoyons notre appel API est :

[node-ip]:[http-port]/ext/bc/X

La documentation de l'API X-Chain nous indique que la signature de getTxStatus est :

avm.getTxStatus(txID:bytes) -> (status:string)

où :

  • l'argument txID st l'ID de la transaction dont nous obtenons le statut.

  • La valeur retournée status est le statut de la transaction en question.

Pour appeler cette méthode :

curl -X POST --data '{
    "jsonrpc":"2.0",
    "id"     :4,
    "method" :"avm.getTxStatus",
    "params" :{
        "txID":"2QouvFWUbjuySRxeX5xMbNCuAaKWfbk5FeEa2JmoF85RKLk2dD"
    }
}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/bc/X
  • jsonrpc spécifie la version du protocole JSON RPC. (En pratique, c'est toujours 2.0)

  • method spécifie le service (avm) et la méthode (getTxStatus) que nous voulons appeler.

  • params spécifie les arguments de la méthode.

  • id est l'ID de cette demande. Les ID de demande doivent être uniques.

C'est tout !

Réponse d'une requête JSON RPC (success)

Si l'appel réussit, la réponse ressemblera à ceci :

{
    "jsonrpc": "2.0",
    "result": {
        "Status":"Success"
    },
    "id": 1
}
  • id est l'ID de la demande à laquelle cette réponse correspond.

  • result est les valeurs renvoyées de getTxStatus.

Réponse d'une requête JSON RPC (error)

Si la méthode API appelée renvoie une erreur, la réponse aura un champ error à la place deresult. En outre, il existe un champ supplémentaire, data, qui contient des informations supplémentaires sur l'erreur qui s'est produite.

Une telle réponse ressemblerait à :

{
    "jsonrpc": "2.0",
    "error": {
        "code": -32600,
        "message": "[Some error message here]",
        "data": [Object with additional information about the error]
    },
    "id": 1
}

Autres formats d'API

Certaines API, telles que l'API Admin, peuvent utiliser une norme autre que JSON RPC 2.0 pour formater leurs demandes et réponses. Une telle extension doit spécifier comment passer des appels et analyser les réponses dans leur documentation.

Envoi et réception d'octets

Sauf indication contraire, lorsque les octets sont envoyés dans un appel / réponse API, ils sont en représentation CB58, un encodage en base 58 avec une somme de contrôle.

JSON RPC 2.0
API X-Chain