
Une introduction sur ce cours et ce que nous allons y voir.
Dans cette session nous voyons quels sont les prérequis pour aborder ce cours, du point de théorique (HTTP, API, REST) mais aussi du point de vue technique : installation des outils et préparation de l'environnement de travail.
Ici, nous créons un projet from scratch, grâce à la commande "--api" de rails. Nous créons également notre premier endpoint pour vérifier que l'application fonctionne.
Ici nous ajoutons une API dans un projet Ruby on Rails existant, grâce au namespace. Nous créons également un endpoint pour vérifier que l'API fonctionne parallèlement à l'application existante.
Dans cette session nous créons un premier modèle, un premier contrôleur et une route pour lire une notre ressource, représentation naïve du modèle, grâce au verbe HTTP GET.
Dans cette session, après avoir discuté de ce qu'il faut tester, nous mettons en place des tests d'intégration / de requête, au moyen de Rspec.
A noter : la gem "FactoryGirl" a été renommée en "FactoryBot". FactoryGirl fonctionne toujours, et vous pouvez suivre le cours sans rien changer, mais si vous souhaitez supprimer l'alerte de déprécation, voici ce qu'il faut faire.
Mettre à jour le Gemfile en remplaçant :
gem "factory_girl_rails"
Par :
gem "factory_bot_rails"
(Pensez à rejouer le bundle install).
Puis dans le code, remplacer chaque occurrence de "FactoryGirl" par "FactoryBot".
Le code du projet est à jour sur le repository GitHub, pour référence: https://github.com/sebastiencarceles/sell_it
Ici nous ajoutons une route pour lire une collection de ressources, grâce au verbe HTTP GET.
Dans cette session nous mettons en place l'authentification sur notre API, au moyen du standard JWT (JSON Web Tokens), implémenté par la gem Knock.
Nous y voyons notamment comment avoir des routes qui nécessitent l'authentification et d'autres qui peuvent être appelées sans authentification.
Grâce à une nouvelle route appelée en POST, et à une nouvelle action, nous permettons la création d'une ressource au travers de l'API, en mode authentifié.
Ici, nous voyons la différence entre les verbes HTTP PUT et PATCH pour mettre à jour une ressource dans le cadre de l'API. Nous gérons les cas d'erreur, les contrôles d'accès et l'authentification.
Grâce au verbe HTTP DELETE, à l'authentification et au contrôle d'accès, nous voyons dans cette session comment supprimer une ressource.
Dans cette session nous refactorons notre code pour respecter les principes DRY (Don't Repeat Yourself) et améliorer le style.
Dans cette session nous voyons comment sérialiser les ressources conformément aux exigences de notre API. Grâce à la gem ActiveModelSerializers, nous représentons différemment les ressources selon le contexte.
Grâce à la gem api-pagination, nous voyons ici comment mettre en oeuvre facilement la pagination dans les ressources, afin de retourner une sous-collection (une page) à l'utilisateur de l'API.
Dans cette session, nous voyons comment gérer la problématique de la rétro compatibilité de l'API et des changements de version, notamment grâce au namespacing.
Ici, nous voyons comment passer des paramètres supplémentaires pour trier une collection de ressources.
Dans cette session, nous ajoutons des paramètres supplémentaires pour filtrer une collection de ressources ou effectuer une recherche sur celle-ci.
Nous discutons des différentes approches pour réaliser des opérations et traitements sur les ressources. Nous voyons comment considérer une opération comme une ressource pour rester conforme à REST.
Conclusion du cours.
De façon très pragmatique, étape par étape au travers d'un projet exemple, nous abordons dans ce cours tous les aspects de la création d'une API REST.
Grâce à Ruby on Rails, que ce soit au sein d'un projet existant ou pour un nouveau projet, nous développons facilement une API fonctionnelle, robuste et respectueuse des standards du web.