Conventions de nommage des SDKs
Ce que les SDKs renomment, ce qu'ils conservent et où se situe la limite.
L'API Wajub utilise le snake_case dans les échanges : created_at, authorization_url, per_page.
Chaque SDK doit déterminer dans quelle mesure adapter ces noms au langage hôte.
La réponse de Wajub est volontairement limitée. Les noms de méthodes suivent les conventions de votre langage, mais pas les noms de champs des payloads. Dans les sept SDKs, un champ conserve le nom donné par l'API.
Ce qui change et ce qui ne change pas
| Couche | Suit les conventions du langage | Exemple |
|---|---|---|
| Noms des clients, ressources et méthodes | Oui | wajub.payments.listRefunds(), client.Payments.ListRefunds() |
| Champs envoyés | Non | "authorization_url", "per_page", "decline_code" |
| Champs reçus | Non | payment.authorization_url, payment["created_at"] |
| Chemins HTTP et paramètres d'URL | Non | /webhooks, ?per_page=50 |
| Noms des en-têtes | Non | Idempotency-Key, X-Wajub-Signature |
| Valeurs d'énumération | Non | payment.succeeded, pending, XAF |
| Identifiants de ressources | Non | trx_…, cus_…, po_… |
Un champ s'écrit donc toujours de la même façon, quel que soit le SDK. Vous pouvez lire la référence API depuis n'importe lequel d'entre eux sans conversion mentale.
"authorization_url": "https://pay.wajub.com/test_xxxxx"En Ruby, utilisez payment.authorization_url, en Java payment.getAuthorizationUrl() et en C#
payment.AuthorizationUrl. Go, Java et C# exposent les champs principaux du paiement en champs
typés, nommés selon le langage ; leur Raw ne contient que l'objet transaction, où
authorization_url ne figure pas (l'API le renvoie à côté de la transaction) :
Raw["authorization_url"] ne trouve donc rien.
Noms de méthodes par langage
| SDK | Style | Exemple de méthode |
|---|---|---|
| Node.js | camelCase | wajub.webhookEndpoints.rotateSecret() |
| Python | snake_case | wajub.webhook_endpoints.rotate_secret() |
| PHP | camelCase | $wajub->webhookEndpoints->rotateSecret() |
| Go | PascalCase | client.WebhookEndpoints.RotateSecret() |
| Ruby | snake_case | client.webhook_endpoints.rotate_secret |
| Java | camelCase | client.webhookEndpoints().rotateSecret() |
| C# | PascalCase avec Async | client.WebhookEndpoints.RotateSecretAsync() |
Un nom a demandé une adaptation supplémentaire, car le choix évident était déjà réservé.
| Emplacement | Raison |
|---|---|
wajub.global_ en Python | global est un mot-clé. Tous les autres SDKs nomment l'accesseur global |
payments.initialize, un alias de create, ne reste que dans le SDK PHP. Les six autres l'ont
retiré, Node.js en 1.5.0 et Python, Go, Ruby, Java et C# en 1.2, où il s'appelait
initialize_payment en Ruby et InitializeAsync en C#. Appelez create partout.
Les langages typés décodent quelques champs
Go, Java et C# sont typés statiquement. Ils ne peuvent donc pas vous transmettre un ensemble arbitraire de champs dans lequel vous pourriez piocher. Ils décodent une petite structure et conservent tout le reste sous forme brute.
payment.id
payment.status
payment.amount
payment.currency
payment.authorization_url
payment.authorization_token
payment.reference // an index signature covers the restCe sont les seuls champs renommés dans toute l'interface. La conversion est mécanique :
authorization_url devient AuthorizationURL en Go, getAuthorizationUrl() en Java et
AuthorizationUrl en C#.
Le décodage typé pose problème pour amount
Go, Java et C# décodent tous amount comme un entier 64 bits. Les montants utilisent l'unité
principale, 12,50 GHS est donc tronqué à 12. Les devises sans décimales comme XAF et XOF ne
sont pas concernées. Pour les autres devises, lisez Raw["amount"], qui conserve la valeur envoyée par l'API.
Les SDKs mobiles ont fait deux fois le choix inverse
C'est le seul endroit où cette règle n'est pas cohérente.
| SDK | Style des champs | Exemple |
|---|---|---|
wajub_mobile (Flutter) | Renommés en camelCase | error.declineCode, transaction.amountTotal |
com.wajub:wajub-mobile-core (Android) | Renommés en camelCase | error.declineCode, channel.publishableKey |
WajubMobile (iOS) | Renommés en camelCase | error.declineCode, transaction.amountTotal |
@wajub/react-native | Conservés en snake_case | error.decline_code, channel.publishable_key |
Flutter, Android et iOS décodent les données dans des modèles typés et renomment les champs au passage. React Native conserve leur format d'échange. Le portage d'un handler entre React Native et Flutter impose donc de renommer chaque champ. Tenez-en compte avant de commencer.
Lire la référence API depuis n'importe quel SDK
La référence documente le format d'échange. Appliquez exactement une transformation.
| Dans la référence | Dans votre code |
|---|---|
POST /webhooks/{id}/rotate-secret | La méthode, selon les conventions de votre langage |
authorization_url dans le corps de la réponse | La même chaîne, inchangée |
per_page comme paramètre d'URL | La même chaîne, inchangée |
Sans SDK, tout utilise le snake_case
Un appel HTTP brut envoie et reçoit du snake_case dans les corps JSON et les paramètres d'URL.
Aucun endpoint n'accepte le camelCase.
Pages associées
- SDKsTous les packages et leur environnement.
- Démarrage rapide des SDKsLe même premier appel dans cinq langages présentés côte à côte.
- ErreursL'enveloppe d'erreur et tous les codes de statut.
- PaginationLa structure de liste qu'enveloppe chaque SDK.
- Vérification de signatureLes noms d'en-têtes, qui ne changent jamais.
- SDKs mobilesOù le nommage des champs diverge et pourquoi.