Publications de Florent JABY

Nous avons souvent dans nos modélisations, nos schémas, nos user stories, nos bases de données et nos APIs un petit champ nommé status, parce que l'anglais ça fait classe. Et bien je vous le dis tout de bon, ce petit champ qui stocke le statut de votre ressource, il sent mauvais et augure bien des périls, en particulier si vous pouvez le modifier. Il peut être révélateur d'une perte de richesse fonctionnelle de notre solution ainsi que de défauts de cohérences ou de résilience de la conception…

Si vous vivez dans le présent, voire un peu dans le passé, vous avez sûrement une application de type SPA réalisée avec le framework Angular. Vu que vous vivez dans le présent, vous avez sûrement envie de suivre un processus de développement et de livraison sain, avec promotion d'une même version d'un artefact à travers plusieurs environnements (test, intégration, recette, préproduction, production, etc.) Seulement voilà, Angular, à l'instar de beaucoup d'autres frameworks front-end, vous inflige de construire/compiler votre application une fois par environnement en collant la configuration…

La période de fêtes approchant à grands pas, nous vous proposons une “Quick Reference Card” sur le design des API dont l'objectif est de synthétiser les bonnes pratiques de conception et de design d'API REST. ➡ Télécharger l'API Design - Quick Reference Card ➡ "Vous aimez les API, le Web ?" : Rejoignez nous! Si vous avez plus de temps, le présent article reprend - point par point - les éléments de la "carte de référence", en étayant et justifiant les propositions. Bonne lecture!