SDK Design Guide
IBEx.Fi API SDK - Guide de conception
Ce document présente les recommandations et conseils pour la création d'un SDK permettant d'utiliser l'API IBEx.Fi.
Vue d'ensemble de l'API
L'API IBEx.Fi est une API RESTful avec support WebSocket qui permet :
- Authentification passwordless via FIDO2/Passkeys (WebAuthn)
- Déploiement de wallets Safe sur plusieurs blockchains (EVM, Solana, Bitcoin)
- Opérations blockchain : transferts de tokens, signatures de messages, swaps
- Gestion de récupération de wallet
- Stockage de données utilisateur (IBEx Safe)
- Lecture de données blockchain (balances, transactions, pools)
- Mises à jour en temps réel via WebSocket
Versions de l'API
L'API supporte plusieurs versions :
- v1 : Version de base
- v1.1 : Extensions avec fallback automatique vers v1
- v1.2 : Extensions spécifiques (ex: recovery)
Authentification
- JWT : Token Bearer pour les endpoints authentifiés
- API_KEY : Pour certains endpoints système
- Passkey : Authentification WebAuthn pour signup/signin
Multi-tenant (rpId/CNAME)
L'API utilise le concept de rpId (relying party ID) extrait du hostname pour isoler les tenants. Les clients doivent configurer un CNAME pointant vers l'API.
Recommandations pour le SDK
1. Architecture générale
1.1 Structure modulaire
Le SDK devrait être organisé en modules correspondant aux domaines fonctionnels de l'API :
1.2 Langages ciblés
Priorité 1 : TypeScript/JavaScript (Node.js et navigateur)
- Support natif de WebAuthn dans les navigateurs
- Large adoption dans l'écosystème Web3
- Typage fort avec TypeScript
Priorité 2 : Python
- Popularité dans l'écosystème blockchain
- Support WebAuthn via bibliothèques tierces
Priorité 3 : Autres langages selon la demande (Rust, Go, etc.)
2. Configuration et initialisation
2.1 Configuration de base
2.2 Initialisation
3. Gestion de l'authentification
3.1 Flow Passkey (WebAuthn)
Le SDK doit abstraire le flow WebAuthn en deux étapes :
3.2 Gestion des tokens
Le SDK doit gérer automatiquement :
- Stockage sécurisé des tokens (localStorage, sessionStorage, ou storage personnalisé)
- Refresh automatique des tokens expirés
- Injection automatique du token Bearer dans les requĂŞtes
- Gestion de la déconnexion
4. Support multi-chaînes
4.1 Gestion des chainIds
Le SDK doit supporter :
- Header
X-Blockchain-Id(méthode préférée) - Query parameter
blockchainId(fallback) - Configuration par défaut via
defaultChainId
4.2 Support multi-blockchains
L'API supporte :
- EVM chains : Ethereum, Gnosis, Polygon, Arbitrum, Base, etc.
- Solana : Mainnet (chainId: 900), Devnet (chainId: 901)
- Bitcoin : Mainnet, Testnet
Le SDK doit abstraire les différences entre ces blockchains :
5. Opérations blockchain
5.1 Opérations Safe
5.2 Types d'opérations supportées
Le SDK doit supporter tous les types d'opérations :
TRANSFER_TOKEN: Transfert de tokens ERC20SIGN_MESSAGE: Signature de messagesENABLE_RECOVERY: Activation de la récupérationDISABLE_RECOVERY: Désactivation de la récupérationEXECUTE_RECOVERY: Exécution de la récupérationSWAP_TOKEN: Échange de tokens- Et autres...
6. BCReader (Lecture blockchain)
6.1 Balances
6.2 Transactions
6.3 Pools (AAVE)
7. Swap (Échange de tokens)
7.1 CoW Protocol
7.2 1inch
8. WebSocket (Mises à jour en temps réel)
9. Gestion des erreurs
9.1 Types d'erreurs
Le SDK doit définir des classes d'erreur spécifiques :
9.2 Gestion des erreurs API
L'API retourne des erreurs structurées. Le SDK doit les mapper :
10. Utilitaires et helpers
10.1 Conversion de montants
10.2 Validation d'adresses
10.3 Formatage
11. Gestion de la récupération
12. Stockage de données utilisateur (IBEx Safe)
13. Gestion des versions
13.1 Support des versions multiples
Le SDK doit supporter les différentes versions de l'API :
13.2 Migration entre versions
Le SDK doit faciliter la migration :
14. Tests et validation
14.1 Tests unitaires
Le SDK doit inclure des tests pour :
- Chaque module fonctionnel
- Gestion des erreurs
- Conversion de formats
- Validation des données
14.2 Tests d'intégration
Tests avec un environnement de test de l'API :
- Flow complet d'authentification
- Opérations blockchain end-to-end
- WebSocket en conditions réelles
14.3 Mocks et fixtures
Fournir des mocks pour faciliter les tests des applications utilisant le SDK :
15. Documentation
15.1 Documentation API
- JSDoc/TSDoc : Documentation inline pour toutes les méthodes
- README : Guide de démarrage rapide
- Guides : Tutoriels pour les cas d'usage courants
- Exemples : Exemples de code pour chaque fonctionnalité
15.2 Documentation de référence
- API Reference : Documentation complète de toutes les méthodes
- Types : Documentation des types TypeScript
- Erreurs : Liste complète des erreurs possibles
16. Performance et optimisation
16.1 Mise en cache
16.2 RequĂŞtes batch
16.3 Retry et backoff
Le SDK doit implémenter une stratégie de retry intelligente :
17. Sécurité
17.1 Stockage sécurisé des tokens
- Navigateur : Utiliser
sessionStorageoulocalStorageavec préfixe sécurisé - Node.js : Utiliser un système de stockage sécurisé (keychain, etc.)
- Support de storage personnalisé : Permettre aux utilisateurs de fournir leur propre storage
17.2 Validation côté client
Valider les données avant l'envoi à l'API :
17.3 Protection CSRF
Le SDK doit gérer automatiquement les tokens CSRF si nécessaire.
18. Intégration avec frameworks populaires
18.1 React
18.2 Vue.js
18.3 Next.js
19. Observabilité et logging
19.1 Logging
19.2 Métriques
Le SDK peut exposer des métriques :
20. Roadmap et évolutions futures
20.1 Fonctionnalités à considérer
- Support offline : Cache local pour fonctionnement hors ligne
- Synchronisation : Synchronisation automatique des données
- Plugins : Système de plugins pour étendre le SDK
- CLI : Outil en ligne de commande pour les développeurs
- DevTools : Extension navigateur pour le débogage
20.2 Compatibilité
- Rétrocompatibilité : Maintenir la compatibilité avec les versions précédentes
- Dépréciations : Gérer les dépréciations de manière claire
- Migration guides : Guides de migration entre versions majeures
Exemple d'utilisation complète
Conclusion
Ce SDK doit ĂŞtre :
- Simple à utiliser : API intuitive et bien documentée
- Type-safe : Support TypeScript complet
- Robuste : Gestion d'erreurs complète et retry automatique
- Performant : Mise en cache et optimisations
- Sécurisé : Gestion sécurisée des tokens et validation
- Extensible : Architecture modulaire permettant l'extension
- Bien documenté : Documentation complète avec exemples
Le SDK doit abstraire la complexité de l'API tout en restant flexible pour les cas d'usage avancés.