TP poem
Cartouche
| Champ | Valeur |
|---|---|
| Module | Programmation Générale en Rust 202 |
| Auteur·e·s | Élise Philippe |
| Édition | 2025-03-04 |
| Durée | 4~5 séances |
| Taille des équipes | 2~3 personnes |
| Rendu | via git, dépôt $YEAR_poem, droits en lecture à delivery_collector |
| Nom du crate | tp_poem |
Règlement
Prenez connaissance du règlement ici
L’intégralité de la bibliothèque standard est autorisée. Vous êtes encouragés à vous servir des outils qu’elle vous propose s’ils résolvent un de vos problèmes. Votre objectif c’est d’éviter de ré-inventer la roue quand ça n’est pas nécessaire.
Certains crates sont proposés dans le sujet. Vous avez le droit de vous servir de toutes leurs fonctionnalités.
Vous pouvez rechercher des alternatives à ces crates, voir des crates qui vous proposent des fonctionnalités complètement différentes. Si ces crates affectent l’écriture de votre algorithme ou l’architecture de votre programme, vous devez les faire valider en amont.
Barème
- 5 points conceptions REST (respect des principes, modélisation des cas d’utilisation, sous-routes, DTO)
- 7,5 points implémentation avec poem
- 7,5 points qualité du code (peu de répétitions, concision, respect des idiomes du RUST)
Consignes
Écrivez une API avec poem et SQLx pour le gestionnaire de tâches et de projets que vous avez modélisé dans TP SQLx.
Dans un fichier README.md vous devez décrire vos différentes routes, ainsi que les données qu’elles consomment et produisent, tout en respectant les principes d’une API REST. Pensez au fait que les jointures doivent être abstraites. Le consommateur de l’API ne doit pas avoir l’impression de se battre contre une base de données. Ainsi un requête sur une tâche fera systématiquement une jointure sur le nom de l’auteur et sur le nom du projet. Cela doit se refléter dans vos DTO.
Nous ferons plusieurs allées et venues sur la conception et la qualité du code de votre programme.