Simon Renoult posts

Dans cet article, je vais vous raconter une petite histoire de diagnostic comme il nous - ingénieurs, développeurs et autres artisans du code - en arrive très souvent. C’est une histoire technique qui parle de base de données, de logs, d’ORM sûrement mal configuré et de MySQL qui fait ce qu’on lui dit. C’est surtout l’histoire de comment et pourquoi on a regardé au mauvais endroit en apprenant pleins de trucs au passage.

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…

Je dois vous avouer que je voue une passion secrète à JavaScript. Je trouve ce langage puissant, facile à prendre en main et très flexible. Cependant, certaines de ses fonctionnalités peuvent paraître compliquées voire inutiles.

I have been working with Node.js for almost 6 years now (started back in 2012 with 0.6.10). During these years, co-workers have been asking me the same question over and over again: "What does your application look like?". It is now time to answer this question (or at least try to) !

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!