Disponibilité
Principes de conception
- Accès public en lecture seule aux données publiques de la blockchain.
- Aucune opération d'écriture, de signature ou de gestion de wallet.
- Aucune exposition directe du RPC du nœud.
- Réponses mises en cache et limitation de débit pour protéger l'infrastructure.
- Indisponibilité de l'API sans impact sur la consultation du site.
- Documentation des schémas, des codes d'erreur et des limites avant mise en service.
Ressources envisagées
- État du service
- Disponibilité de l'API, hauteur de chaîne publique et informations générales du réseau.
- Blocs
- Liste paginée des blocs et consultation d'un bloc par hauteur ou identifiant public.
- Transactions
- Consultation d'une transaction publique par son identifiant.
- Adresses
- Historique public d'une adresse, sans aucune donnée privée de wallet.
- Réseau
- Informations publiques sur les pairs et l'état de synchronisation, agrégées et non sensibles.
Les chemins, formats de réponse, paramètres de pagination et limites de débit seront fixés dans une spécification versionnée publiée avant l'ouverture de l'API.
Intégration côté site
Le site est conçu pour rester autonome. Toute future intégration passera par une couche d'accès dédiée, côté serveur, avec délai d'attente, validation des réponses et état d'indisponibilité explicite.
- Aucune donnée de démonstration ne doit être affichée en production.
- Une réponse indisponible doit produire un état vide clairement identifié.
- Les erreurs de l'API ne doivent pas révéler d'information d'infrastructure.
- Le site ne doit jamais dépendre de l'API pour afficher ses pages statiques.