4.5 KiB
status: hidden title: Python — Django isup slug: inuik9Ah-django-isup robots: noindex
Le nom du rendu est isup
, le protocole de rendu est
là.
Le nom du projet Django est libre, l'app Django doit s'appeler isup
.
Survol
Votre projet sera composé de :
- Au moins deux modèles :
Domain
etCheck
.- Un
Domain
est lié à undjango.contrib.auth.User
(son propriétaire) via unemodels.ForeignKey
. - Un
Domain
contient au minimum :name
oudomain
(le nom de domaine),is_up
(booléen à True si le site est accessible),since
qui indique depuis quand le site est up ou down.
- Un
Check
est lié à un domaine (un domaine peut avoir plusieurs checks). - Un
Check
contient au minimum :- La date de vérification,
- un booléen
is_up
- un message d'explication comme « HTTPS certificate expired », « Timeout », « Up », ...
- Un
- Au moins une vue Django pour la page d'accueil.
- De quoi créer un compte (via Django, pas forcément via l'API), car seuls les utilisateurs loggés peuvent créer des domaines (qui leur appartiendront).
djangorestframework
pour gérer la sérialisation des modèles, les permissions, les vues d'API, les routes d'API.
L'API
Je m'attends à pouvoir utiliser votre API de cette manière :
GET /api/domains/ # Lister tous les domaines connus et leurs état (avec de la pagination si nécessaire).
POST /api/domains/ -d '{"domain": "mdk.fr"}' # Pour ajouter un nom de domaine (qui appartient à celui qui fait le POST).
GET /api/domains/1/ # Afficher les informations du premier domaine.
PUT /api/domains/1/ # Modifier le domaine 1, seulement autorisé si j'en suis propriétaire.
DELETE /api/domains/1/ # Supprimer le domaine 1, seulement autorisé si j'en suis propriétaire.
GET /api/checks/ # Lister toutes les vérifications qui ont été effectuées.
GET /api/checks/?domain=1 # Lister toutes les vérifications effectuées pour le domaine 1.
GET /api/checks/1 # Afficher le check d'id 1.
Les checks sont en lecture seule, donc pas de POST
, PUT
, DELETE
dessus.
Si vous voulez que votre API soit REST, la représentation d'un domaine doit contenir un lien vers ses checks
:
{
"domain": "mdk.fr",
"is_up": true,
"checks_url": "http://localhost:8000/uptime/checks/?domain=1",
"url": "http://localhost:8000/uptime/domains/1/"
}
Vérification périodique des domaines connus.
Vous utiliserez une Management Command pour mettre à jour votre table, c'est là que votre script implémenté en cours sera utile.
La commande peut s'appeler check
par exemple. Sur un serveur de
prod, le serveur devra l'appeler périodiquement, par exemples toutes
les 5mn, via un
timer
ou un cron.
En dev vous pouvez simplement lancer python manage.py check
à la
main de temps en temps.
Cette commande doit lancer une nouvelle vérification de tous les
domaines connus, chaque résultat (up ou down) doit être documenté dans
le modèle Checks
.
La page d'accueil
La page d'accueil doit être la plus "Django-less" possible :
- Une simple route.
- Une simple vue d'une seule ligne avec
render
. - Un template avec au besoin du HTML, du JS, du CSS mais pas de templating Django (pas de
{{
, pas de{%
).
Vous êtes autorisés à stocker le JS et le CSS en statique, mais je n'ai rien contre tout mettre dans le même fichier vu que je suis dev back #sinvergüenza.
Quand je dis « Django-less » je veux dire que le front doit pouvoir fonctionner en dehors de Django, et que dans un vrai projet avec une équipe front et une équipe back j'aimerai que cette home, ce JS, et ce CSS puisse être géré dans un autre repo, sans qu'à aucun moment les devs front n'aient besoin de savoir que c'est du Django côté back.
Vous pouvez donc utiliser le framework front à la mode cette semaine.
Pour récupérer la liste des noms de domaines et leur état, le front devra donc utiliser l'API. Pas besoin d'être loggé pour ça, on ne modifie rien, on ne fait que consulter, keep it simple stupid.