API === .. toctree:: :maxdepth: 2 :caption: Applications activity basic logs member note permission treasury wei La NoteKfet2020 dispose d'une API REST. Elle est accessible sur `/api/ `_. Elle supporte les requêtes GET, POST, HEAD, PUT, PATCH et DELETE (peut varier selon les pages). Pages de l'API -------------- Il suffit d'ajouter le préfixe ``/api/`` pour arriver sur ces pages. * `models `_ : liste des différents modèles enregistrés en base de données * `user `_ : liste des différent⋅es utilisateur⋅rices enregistrés * `members/profile `_ : liste des différents profils associés à des utilisateurs * `members/club `_ : liste des différents clubs enregistrés * `members/membership `_ : liste des adhésions enregistrées * `activity/activity `_ : liste des activités recensées * `activity/type `_ : liste des différents types d'activités : pots, soirées de club, ... * `activity/guest `_ : liste des personnes invitées lors d'une activité * `activity/entry `_ : liste des entrées effectuées lors des activités * `note/note `_ : liste des notes enregistrées * `note/alias `_ : liste des alias enregistrés * `note/consumer `_ : liste des alias enregistrés avec leur note associée * `note/transaction/category `_ : liste des différentes catégories de boutons : soft, alcool, ... * `note/transaction/transaction `_ : liste des transactions effectuées * `note/transaction/template `_ : liste des boutons enregistrés * `treasury/invoice `_ : liste des factures générées * `treasury/product `_ : liste des produits associés à des factures * `treasury/remittance_type `_ : liste des types de remises supportés : chèque * `treasury/remittance `_ : liste des différentes remises enregistrées * `treasury/remittance `_ : liste des crédits de la Société générale enregistrés * `permission/permission `_ : liste de toutes les permissions enregistrées * `permission/roles `_ : liste des permissions octroyées pour chacun des rôles * `logs `_ : liste des modifications enregistrées en base de données * `wei/club `_ : liste des WEI * `wei/bus `_ : liste des bus de tous les WEI * `wei/team `_ : liste des équipes de tous les WEI * `wei/role `_ : liste des rôles possibles pour le WEI * `wei/registration `_ : liste de toutes les inscriptions à un WEI * `wei/membership `_ : liste des adhésions compètes à un WEI Utilisation de l'API -------------------- La page ``/api//`` affiche la liste de tous les éléments enregistrés. La page ``/api///`` affiche les attributs d'un objet uniquement. L'affichage des données peut se faire sous deux formes : via une interface HTML propre ou directement en affichant le JSON brut. Le changement peut se faire en ajoutant en paramètre de l'URL ``format=json`` ou ``format=api``, ou bien en plaçant en en-tête de la requête ``Accept: application/json`` ou ``Accept: text/html``. L'API Web propose des formulaires facilitant l'ajout et la modification d'éléments. S'authentifier ~~~~~~~~~~~~~~ L'authentification peut se faire soit par session en se connectant via la page de connexion classique, soit via un jeton d'authentification. Le jeton peut se récupérer via la page de son propre compte, en cliquant sur le bouton « `Accès API `_ ». Il peut être révoqué et régénéré en un clic. Pour s'authentifier via ce jeton, il faut ajouter l'en-tête ``Authorization: Token `` aux paramètres HTTP. En s'authentifiant par cette méthode, les masques de droit sont ignorés, les droits maximaux sont accordés. GET ~~~ Une requête GET affiche un ou des éléments. Si on veut la liste de tous les éléments d'un modèle, la réponse est de cette forme : .. code:: json { "count": "", "next": "/api//?page=", "previous": "/api//?page=", "results": [ ] } Où ```` est le nombre d'éléments trouvés. La page n'affiche les informations que 20 par 20 pour ne pas augmenter inutilement la taille de la réponse. Les champs ``next`` et ``previous`` contiennent les URL des pages suivantes et précédentes (``null`` si première ou dernière page). Le champ ``results`` contient enfin l'ensemble des objets trouvés, au format JSON. Certaines pages disposent de filtres, permettant de sélectionner les objets recherchés. Par exemple, il est possible de chercher une note d'un certain type matchant avec un certain alias. Trois types de filtres sont implémentés : * Les filtres Django, permettant d'ajouter ``?key=value`` dans l'URL pour filtrer les objets ayant ``value`` comme valeur pour la clé ``key`` ; * Les filtres de recherche, permettant une recherche plus souple notamment par expressions régulières ou contenance, et permet aussi de chercher parmi plusieurs clés à partir d'un champ ``search`` dans l'URL ; * Les filtres de tri, qui ne filtrent pas réellement mais changent l'ordre. En ajoutant ``?ordering=key`` dans l'URL, on trie les résultats selon la clé ``key`` dans l'ordre croissant, et ``?ordering=-key`` trie dans l'ordre décroissant. Les filtres disponibles sont indiqués sur chacune des pages de documentation. Le résultat est déjà par défaut filtré par droits : seuls les éléments que l'utilisateur⋅rice a le droit de voir sont affichés. Cela est possible grâce à la structure des permissions, générant justement des filtres de requêtes de base de données. Une requête à l'adresse ``/api///`` affiche directement les informations du modèle demandé au format JSON. POST ~~~~ Une requête POST permet d'ajouter des éléments. Cette requête n'est possible que sur la page ``/api//``, la requête POST n'est pas supportée sur les pages de détails (car cette requête permet ... l'ajout). Des exceptions sont faites sur certaines pages : les pages de logs et de contenttypes sont en lecture uniquement. Les formats supportés sont multiples : ``application/json``, ``application/x-www-url-encoded``, ``multipart/form-data``. Cela facilite l'envoi de requêtes. Le module construit ensuite l'instance du modèle et le sauvegarde dans la base de données. L'application ``permission`` s'assure que l'utilisateur⋅rice a le droit de faire ce type de modification. La réponse renvoyée est l'objet enregistré au format JSON si l'ajout s'est bien déroulé, sinon un message d'erreur au format JSON. PATCH ~~~~~ Une requête PATCH permet de modifier un élément. Ce type de requête n'est disponible que sur la page de détails d'un élément : ``/api//pk/``. Comme pour la requête POST, les formats supportés sont multiples : ``application/json``, ``application/x-www-url-encoded``, ``multipart/form-data``. Il n'est pas utile d'indiquer tous les champs du modèle : seuls ceux qui sont à modifier suffisent. Attention : pour les modèles polymorphiques (``Note``, ``Transaction``), il faut toujours spécifier le type de modèle pour que l'API arrive à s'y retrouver. Par exemple, si on veut rendre la transaction n°42 non valide, on effectue une requête ``PATCH`` sur ``/api/note/transaction/transaction/42/`` avec les données suivantes : .. code:: json { "valid": false, "resourcetype": "RecurrentTransaction" } PUT ~~~ Une requête PUT permet de remplacer un élément. Ce type de requête n'est disponible que sur la page de détails d'un élément : ``/api//pk/``. Comme pour les requêtes POST ou PATCH, les formats supportés sont multiples : ``application/json``, ``application/x-www-url-encoded``, ``multipart/form-data``. Contrairement à la requête PATCH, l'intégralité du modèle est remplacé. L'ancien modèle est détruit, on en recrée un nouveau avec la même clé primaire. Le fonctionnement est similaire à une requête POST. DELETE ~~~~~~ Une requête de type DELETE permet de supprimer un élément. Ce type de requête n'est disponible que sur la page de détails d'un élément : ``/api//pk/``. Aucune donnée n'est nécessaire. Le module de permissions vérifiera que la suppression est possible. Une erreur est sinon renvoyée. OPTIONS ~~~~~~~ Une reqête OPTIONS affiche l'ensemble des opérations possibles sur un modèle ou une instance. Prototype d'une réponse : .. code:: json { "name": "", "description": "", "renders": [ "application/json", "text/html" ], "parses": [ "application/json", "application/x-www-form-urlencoded", "multipart/form-data" ], "actions": { "": { "": { "type": "", "required": "", "read_only": "", "label": "