API REST #149
Labels
No Label
ABS
à confirmer
API
Apogée
bug
BUT
Dev
duplicate
enhancement
Entreprises
frontend
help wanted
invalid
Jury
PE
prio
question
RGPD
Users
wontfix
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: ScoDoc/ScoDoc#149
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
WIP : définition des points d'accés à l'API REST. Elle sera accessible à l'adresse https://scodoc.monsite.tld/ScoDoc/api/fonction
le transfert d'informations se fera au format JSON
liste des étudiants avec le code NIP donné triée par ordre d'inscription décroisant
"nom": "Mutis",
"sexe": "M.",
"email": "alvaro.mutis@example.com",
"prenom": "ALVARO",
"nomprenom": "M. Alvaro MUTIS",
"insemestre": [
{
"etat": "I",
"formsemestre_id": "SEM12781",
"date_fin": "2010-07-30",
"date_debut": "2010-01-25"
},
{
"etat": "I",
"formsemestre_id": "SEM8396",
"date_fin": "2009-01-16",
"date_debut": "2008-09-01"
}
],
"etudid": "EID8768",
"domicile": "2 Rue Madame",
"villedomicile": "Paris",
"telephonemobile": ""
}
sem_id
"titre": "DUT Génie Electrique et Informatique Industrielle",
"date_debut": "01/09/2021",
"date_fin": "02/02/2022",
"modalite": "FI",
"sem_id_txt": "S3",
"titre_num": "DUT Génie Electrique et Informatique Industrielle semestre 3",
"anneescolaire": "2021 - 2022",
"periode": 1,
"titreannee": "DUT Génie Electrique et Informatique Industrielle semestre 3 FI 2021-2022"
} ]
/api/photo/123/small
(en cours de modification)
acronyme
titre
...
/api/formation_list?dept=GEII
{ "id": 1,"dept_id": 1,"acronyme": "BUT GEII", "titre": "BUT G\u00e9nie Electrique et Informatique Industrielle", "titre_officiel": "BUT G\u00e9nie Electrique et Informatique Industrielle","version": 1,"formation_code": "FCOD1","type_parcours": 600,"code_specialite": "","formation_id": 1 }
titre
etat
annee
date_debut
partition_name
group_id
group_name
partition_name
group_id
group_name
module_name
eval_description
groupsLists
groupsToDelete
groupsToCreate
groupsLists est une liste d'etudid à inscrire dans le groupe
etudid
note
Merci à vous deux !
J'ai l'impression qu'on peut s'épargner la colonne "champs résultat", l'exemple (commenté au besoin) est suffisant.
Dans certains cas, on va essayer d'éviter les paramètres query_string, et s'orienter vers des URL, comme
/api/formsemestre_partition_list/1
(quand il y a plusieurs paramètres, quelles conventions on adopte ?)Pour en savoir plus sur le sujet, la 1ere réponse sur SO est pas mal je trouve https://stackoverflow.com/questions/4024271/rest-api-best-practices-where-to-put-parameters
etud_dept, etud_info Attention dans la version actuelle, un étudiant qui a changé de départment existe dans chacun des deux départements. il faudrait, soit donner la possibilité de retourner plusieurs étudiants (même pour un seul code_nip) ou décréter qu'on retourne celui qui a l'inscrition la plus tardive par exemple
sem_info il est spécifié un paramètre code_nip qui ne figure pas dans l'exemple. je suppose qu'on cherche les informations sur le semestre actuel d'un étudiant ?
+1 sur la remarque d'Emmanuel, par exemple pour les partitions, je serait plutôt partisan de
POST /api/partitions/partitionid/groups avec le nom du groupe à créer en données
DELETE /api/partitions/partitionid/groups/groupid pour supprimer un group
GET /api/partitions/partitionid/groups pour avoir la liste des groupes
J'ai vu passer des exemple ou on ajoutait dans le chemin le no de version de l api pour popuvoir changer de version d'API en conservant la compatibilité avec les clients existants
Très intéressant d'ajouter les paramètres (obligatoire) dans l'URL.
Pour fixer l'ordre, on a normalement un seul paramètre parmi :
dept_id / formation_id / semestre_id / module_id / evaluation_id
=> il n'y a donc pas vraiment d'ordre à fixer entre eux.
Cela me semble logique qu'il soit en premier.
En second obligatoire, il y a soit nip, soit etud_id, mais jamais les deux.
(D'ailleurs, est ce logique d'utiliser le etud_id en paramètre ?)
/api/etud_bul/12/12398712
pour/api/etud_bul?code_nip=12398712&id_sem=12
/api/eval_list/1
pour/api/eval_list?module_id=1
/api/etud_info/12398712
pour/api/etud_info?code_nip=12398712
Pour les autres paramètres (même obligatoire), difficile de faire une convention intuitive, non ?
/api/setNote/1312/213?note=ABS
pour/api/setNote?evaluation_id=1312&etudid=213¬e=ABS
Si on part sur des URL sans query string, ca veut dire qu'on ne peut appeler un étudiant QUE par son nip. On s'interdit de l'appeler par son INE ou son etud_id.
On ne peut appeler un semestre QUE par son id, pas par son étape apogée.
Je ne suis pas contre, je n'utilise pas les autres méthodes.
J'ai pris en compte vos remarques et mis les résultats escomptés. J'ai aussi rajouté le paramètre dept_id partout
Je n'ai pas encore intégré les autres requêtes de Pascal.
Comme tous les objets manipulés par l'application, un étudiant a toujours un id, nommé à l'extérieur etudid. Mais il n'a pas toujours un NIP ou un INE.
Sauf indication contraire, les id à utiliser sont donc ceux de scodoc (etudid, etc), pas le NIP ni l'INE.
La démarche devrait probablement être:
récupérer l'etudid, via une liste d'étudiant d'un groupe ou via une interrogation directe genre get_etud_dept (qui pourrait fournir les départements et ids). Cette (ou ces) requêtes pourraient effectuer des recherches par NIP, INE, nom, étape, ...
Utiliser l'etudid obtenu pour récupérer d'autres éléments (bulletins, absences, ....) ou manipuler l'étudiant (incriptions, ajout absences, ...).
+1 (et ça évite de se trimballer un departement en plus - car l etudid lui est unique sur tous les depts)
J'ai mis à jour. Mais comment etud_dept peut-il recevoir soit un NIP soit un INE soit un nom ? Il cherchera ce qu'on a mis dans code_nip dans tous les champs de la BDD ?
Ca complique peut être , mais pour etud_dept, peut-on envisager :
/api/etud_dept/123 : recherche par nip
/api/etud_dept/ine/123456789 : recherche par ine
/api/etud_dept/nom/dupont : recherche par nom ( plusieurs réponses possibles)
Et pour récupérer la photo d'un étudiant ce serait:
ou pour la version réduite:
Ok j'ai mis à jour, j'ai donc supprimé photo_url de etud_info
Bonjour à tous,
Suite à la réunion, voici les fonctions que j'utilise et qui ne sont pas prévus dans l'API (à moins qu'ils soient prévus avec un autre nom que je n'ai pas saisi) :
A bientôt,
Seb
est actuellement acessible à tous
groups_view n'est pas actuellement accessible en mode "scodoc7" dans ScoDoc9. Sera dans l'API, probablement sous un autre nom.
idem
idem
(si besoin urgent de ces fonctions en ScoDoc 9.0, me dire, on peut les rebrancher en attendant l'API)
#d2f41b6a21 avance un peu sur le sujet.
Oui tu m'avais déjà dit pour ces fonctions non accessibles, mais j'ai tout de même trouvé un moyen d'y accéder sur Scodoc 9 en utilisant une petite faille non critique du système :
Du coup j'ai accès à tout ce qu'il me faut.
Code exemple : https://github.com/SebL68/Scodoc_Notes/blob/main/includes/serverIO.php
Le problème risque de venir avec la nouvelle API, c'est pourquoi je parle tout de suite des besoins qui ne sont pas encore listé, pour ne pas les oublier.
Voir https://docs.google.com/spreadsheets/d/1k6VtENWuZRLyssjvmzE7_FZpB_VpJ4xrNdN_M_fWCXU/edit?usp=sharing