Structuration des fonctionnalités de l’API
Je n’ai pas beaucoup d’expérience en matière de création d’API. J’ai fait une bonne partie du travail en ce qui concerne l’intégration de WordPress avec des API tierces, mais j’ai passé très peu de temps à créer un système qui a son API avec laquelle d’autres systèmes peuvent interagir.
En ce qui concerne ce dernier, je suis en train de le faire (et j’apprends beaucoup). L’essentiel du projet est qu’il existe une application iOS qui interagit avec WordPress via l’API REST de manière bidirectionnelle.
Je suis impatient de partager plus à ce sujet, mais je dois le faire lorsque le projet sera plus avancé.
Mais lorsqu’il s’agit de travailler avec des API tierces, puis de créer des composants d’un projet WordPress qui interagissent avec elles, deux des choses que je trouve toujours utiles sont :
- à l’aide d’une bibliothèque appropriée ,
- schématiser le système,
- séparer la fonctionnalité en parties.
Et les deux derniers points ci-dessus sont ce que je cherche à couvrir dans ce post.
Structuration des fonctionnalités de l’API
Aucun code n’est impliqué dans cet article, mais ce sera peut-être un guide sur la façon dont vous pouvez avancer dans votre travail en structurant les fonctionnalités de l’API ou en faisant quelque chose de similaire par vous-même.
Bibliothèques tierces
Je mentionne cela uniquement parce que je pense qu’il est utile de réutiliser des solutions éprouvées qui ont été testées (et donc utilisées) à tous les niveaux dans une variété de projets.
Guzzle est ma bibliothèque de choix. Oui, WordPress a des fonctions intégrées pour communiquer avec d’autres URL, mais vous pouvez faire plus avec Guzzle (en particulier en ce qui concerne les composants de la requête) qu’avec WordPress.
Certes, c’est mon opinion, mais j’aime travailler avec elle. Et la documentation est solide.
Schématiser le système
Lorsque vous travaillez suffisamment longtemps avec l’intégration d’API tierces, vous devez vous habituer au processus de configuration du fonctionnement du système. Habituellement, ça donne quelque chose comme ça :
- créer un client API pour se connecter à l’API,
- mettre en place les fonctions nécessaires pour effectuer les requêtes dont vous avez besoin,
- analyser la réponse,
- renvoyez-le à l’objet ou à la fonction d’origine qui a invoqué la requête.
C’est un peu simpliste (après tout, créer le client API peut être une tâche en soi), mais les points restent tous les mêmes (et peuvent ne pas faire une mauvaise série 🤔).
Quoi qu’il en soit, par-dessus tout, cela ne fait jamais de mal de schématiser le système. C’est quelque chose que je fais encore parce que cela m’aide, dans un sens, à articuler ce que je construis et à voir s’il y a des lacunes dans le flux de contrôle à travers l’application.
Voici pourquoi, s’il n’y a pas d’autre raison, c’est important : articuler ce que vous allez faire vous aide à comprendre ce que vous faites et expose souvent des lacunes dans votre réflexion que vous tenez pour acquises.
Donc, quand il s’agit de mettre en place un système, ne présumez pas que vous avez tout compris.
Séparer la fonctionnalité
Si vous avez lu ce blog pendant un certain temps, alors vous savez que je suis fan de suivre toutes les idées de développement de "séparation des préoccupations".
Cela est vrai pour de multiples raisons dont les moindres ne sont pas :
- être capable de tester unitairement un client API de manière isolée,
- garder le code pour communiquer avec le front-end et le back-end indépendants.
Lorsque vous avez une classe dédiée à l’exécution de la logique métier sur les valeurs, vous pouvez décharger une grande partie de la gestion des erreurs dans la classe intermédiaire.
Cela signifie que la classe principale responsable de la majorité de la logique métier doit avoir exactement ce dont elle a besoin pour faire son travail. Cela ne signifie pas qu’il n’y a pas de vérification des erreurs en place (division par zéro ou quelque chose, vous savez ?), mais cela signifie que les données peuvent être vérifiées avant même qu’elles n’atteignent la classe principale via la classe intermédiaire.
Et non seulement il peut vérifier les informations manquantes, mais il peut également signaler ces erreurs au serveur frontal.
Trois points à retenir
Si vous créez un système dépendant d’Ajax dans WordPress, l’intérêt de tout cela est triple :
- schématisez le système que vous créez,
- créer une classe interstitielle pour gérer les informations manquantes et signaler les erreurs,
- n’envoyez les informations complètes à la classe d’activité principale qu’après que toutes les informations ont été vérifiées.
Une fois que vous avez fait cela, l’objectif serait que la classe métier principale renvoie les valeurs demandées sans erreur car elles auront été interceptées avant même de l’atteindre.