Exemple de modèles de données
Ce guide tente de décrire de façon succincte les données minimales nécessaires au bon fonctionnement d'AppScho. Cette liste représente un sous-ensemble des données qui peuvent être fournie par l'ERP d'un établissement, et peut donc être complétée en fonction du besoin.
Le format recommandé pour ces échanges est le JSON à travers HTTP. Pour une interface aussi "simple", nous préférerons une interface REST à un modèle complexe RPC tel que SOAP.
Authentification utilisateurs
Deux possibilités s'offrent à nous ici :
- Utiliser un système d'authentification géré par l'outil établissement.
Ici, l'utilisateur concerné est intrisèquement identifié par le token d'authentification généré et fourni par l'outil établissement. - Authentifier l'utilisateur côté AppScho et faire en sorte que l'outil établissement fasse confiance aux requêtes faites par AppScho.
Dans ce cas, les requêtes à l'API contiendrait l'identifiant de l'utilisateur concerné en paramètre.
Informations utilisateurs
Une fois l'utilisateur connecté, nous avons la possibilité de récupérer des informations sur sa personne et son profil au sein de l'établissement. Les données essentielles étant les suivantes :
- le prénom
- le nom
- la photo
D'autres données annexes et / ou composites peuvent être fournies dans cette réponse, par exemple :
- le programme d'inscription
- la promotion
- le nombre de crédits ECTS obtenus
- une liste de groupes desquels l'étudiant fait partie (cette liste de groupes est utilisée par les systèmes de push d'iOS et Android, de ce fait, ils doivent rester des ID simple (lettre, chiffres, et tirets)
- ...
Groupes
Résultats d'examens
Ici, nous devons récupérer une liste d'examens, possédant les attributs propres à cet examen, par exemple :
- le nom de la matière
- la date de l'examen
- la note obtenue
- le nombre de crédits ECTS en jeu
Ces examens peuvent être organisés en une hiérarchie permettant le classement en années, semestres, groupes, etc. Nous recommandons de limiter au possible la profondeur hiérarchique afin d'optimiser l'usage sur mobile (par exemple Année > Semestre > Matière > Examen).
Emploi du temps
L'emploi du temps une simple liste d'événements comprenant, au minimum, les informations suivantes :
- un ID unique pour l'événement
- le nom de l'événement
- la date et heure de début
- la date et heure de fin
L'ID unique à renvoyer avec l'événement nous est utile afin de déterminer si un événement a été modifié (nous comparons les champs pour les événements possédant le même ID). Il est donc important que cet ID ne change pas lorsqu'un événement est modifié.
Le format pour les dates renvoyées importe peu tant que celui-ci est précis (avec fuseau horaire).
Chaque événement peut aussi, si disponible, inclure les informations suivantes :
- le nom de la salle où se situe l'événement
- le nom du professeur
- une description plus complète de l'événement
- un lien vers une plateforme LMS
- ...
Absences
Une liste d'absences comprenant, au minimum, les données suivantes :
- le nom du cours concerné
- la date et l'heure de l'absence
- un booléan indiquant si l'absence est justifiée ou non
Optionnellement, une absence peut contenir les attributs suivantes :
- la justification de l'absence
- ...
Annuaire
L'annuaire peut avoir une ou deux interfaces différentes.
L'interface indispensable concerne la recherche. Un paramètre fournit la chaîne de caractères recherchée, encodée pour être contenue dans une URL (et donc pouvant contenir des espaces). Par exemple /directory/search?term=antoine%20popineau. Cet endpoint doit renvoyé une liste d'entités répondant au critère de recherche, par exemple :
Documents
La liste de documents doit être organisée de manière similaire aux notes, à savoir une hiérarchie de descripteurs de documents, qui sera répliquée dans l'application de l'utilisateur.
Chaque niveau peut contenir des enfants (dans ce cas, le niveau en question est un dossier). Si un noeud de l'arbre ne contient aucun enfant, il s'agit un document et doit donc contenir des information supplémentaires décrivant le document en question. Un point important est à noter : le document doit être téléchargeable à travers HTTPS directement par le terminal mobile, cela signifie une de deux choses : celui-ci est accessible publiquement, sans authentification, ou être authentifié directement à travers des paramètres fournis dans l'URL du document.