mdk.fr/content/pages/django_isup.md

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 .

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 et Check.
    • Un Domain est lié à un django.contrib.auth.User (son propriétaire) via une models.ForeignKey.
    • Un Domain contient au minimum :
      • name ou domain (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 », ...
  • 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.