WOA

Le style d'architecture REST proposé par Roy Fielding au début des années 2000 suggère de ne pas inventer de nouveaux protocoles afin d'exprimer les opérations appliquées aux ressources de nos systèmes. Au contraire, il propose de s'appuyer sur le protocole HTTP, protocole définissant un ensemble restreint de méthodes (ou verbes) permettant d'exprimer différentes manières d'interagir avec nos ressources. Une des opérations classiques de tout système est la modification de l'état d'une ressource. Et dans HTTP, cette mise à jour peut s'effectuer via trois méthodes distinctes…

Les entreprises proposant un service au travers d'une API et qui voient le nombre de consommateurs et de partenaires augmenter, sont confrontées à de nombreux challenges : Comment réduire le temps d'enrôlement des nouveaux consommateurs et partenaires ? Comment identifier les partenaires et gérer leurs consommations des APIs ? Comment mesurer la consommation du point de vue producteur et consommateur ? Comment gérer le cycle de vie de l'API ? Il s'agit alors, d'adresser ces problématiques de manière uniforme pour l’ensemble des APIs par l'intermédiaire…

Après avoir vu a vu les principes sous-jacents aux deux cadriciels hapi et express, leur histoire et environnement, regardons maintenant comment réaliser avec eux une belle API REST. Pour ce faire on s'appuiera sur un use case réel, et une API REST développée pour comparer les deux frameworks. Le code source est disponible ici, et l'API est en ligne là.

Dans mon précédent article j'exposais les raisons pouvant nous amener à opter pour la plateforme Node.js pour réaliser des API REST. Plutôt que de réimplémenter la roue au-dessus des fonctionnalités bas niveau du coeur de Node, le choix d'un framework s'impose. Au sein de l'écosystème Node, deux frameworks tiennent le haut du pavé pour la réalisation d'API: express et hapi. Dans cet article nous allons étudier leur architecture ainsi que leur histoire, leur dynamique et communauté.

Ces dernières années l'approche REST devient l'architecture incontournable des API en utilisant la puissance du protocole HTTP. Parallèlement on assiste à une reconfiguration du paysage côté serveur notamment avec la percée de Node.js Node s'est imposé comme une des principales piles techniques. S'il permet facilement de créer un petit serveur HTTP en une ligne de commande, qu'en est-il pour une API d'envergure?

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!