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.
Deux possibilités s'offrent à nous ici :
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 :
D'autres données annexes et / ou composites peuvent être fournies dans cette réponse, par exemple :
Ici, nous devons récupérer une liste d'examens, possédant les attributs propres à cet examen, par exemple :
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).
L'emploi du temps une simple liste d'événements comprenant, au minimum, les informations suivantes :
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 :
Une liste d'absences comprenant, au minimum, les données suivantes :
Optionnellement, une absence peut contenir les attributs suivantes :
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 :
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.