Evolution #163

Mise en place de webservices

Added by Grégory MARIGOT - TEICEE almost 4 years ago. Updated over 1 year ago.

Status:Résolu Start date:12/21/2016
Priority:Normal Due date:
Assignee:Grégory MARIGOT - TEICEE % Done:

100%

Category:-
Target version:ProxyEPN 2.5
Version ProxyEPN:2.4

Description

Ajouter une nouvelle interface à l'application sous la forme de webservice, permettant des interactions depuis des commandes exterieures (autres applications, autres interfaces clients, scripts...)
  • webservices de type REST (stateless)
  • authentification si besoin en HTTP Basic (HTTPS requis)
  • réponses formattées en objets JSON
Quelques exemples de type de requêtes :
  • liste des EPN
  • liste des sessions à venir
  • infos sur compte usager
  • pré-création de compte
  • ...

Associated revisions

Revision 803
Added by Grégory MARIGOT - TEICEE almost 4 years ago

NEW #163: mise en place de webservices

Revision 872
Added by Grégory MARIGOT - TEICEE over 1 year ago

NEW #163: gestion des filtres dans les requêtes des webservices (sur liste des epn et liste des sessions)

History

Updated by Grégory MARIGOT - TEICEE over 2 years ago

  • % Done changed from 0 to 80

Principe général

Les webservices sont utilisables via une API web en effectuant des requêtes sur le module /wsapi/.
Ils sont définis sur un modèle REST (stateless => pas de session).

Différentes actions peuvent être proposées en fonction du chemin de l'URL.
Les chemins devraient respecter une logique /"type"/"commande".
La partie "commande" est facultative, chaque "type" pouvant disposer d'une "commande" par défaut.

Permissions

Les webservices sont soumis aux mêmes règles d'accès que l'application classique avec son système de permissions.

Une authentification peut être effectuée à chaque requête sur l'API web, basée sur les usagers de l'application :
l'utiliser revient exactement au même que se connecter sur l'application avec son compte
(identifiant et mot de passe du compte usager, application du profil et des permissions).

L'authentification est facultative, ce qui à défaut revient à consulter l'application sans avoir de compte.
Note : La majorité des requêtes ne feront que retourner des données publiques pour lesquelles un accès anonyme sera suffisant.

Ainsi l'authentification ne sera utile que pour quelques commandes récupérant des informations personnelles
(informations sur son compte, liste des sessions incluant ses sessions libres non publiques...)
ou éventuellement des commandes devant effectuer des actions privilégiées (accès à des données masquées, mise à jour de données...).

Authentification

L'authentification repose sur les mécanismes standards fournis par le protocole HTTP avec la méthode "BASIC".

Pour info la méthode "DIGEST" qui permet l'authentification sans faire transiter le mot de passe sur le réseau
n'est pas envisageable car elle nécessite en contre partie que le serveur puisse connaitre les mots de passe.
Or par sécurité les mots de passe ne sont pas stockés en clair et le chiffrement utilisé est non-bijectif.

Enfin si la méthode "BASIC" transmet le mot de passe, cela n'est pas génant à condition de bien utiliser HTTPS
pour chiffrer la communication.

Requêtes

Les commandes actuellement en place sur l'API web sont les suivantes :
  • Liste des EPN : /wsapi/epn/list ( ou juste /wsapi/epn )
  • Liste des Sessions : /wsapi/session/list ( ou juste /wsapi/session )
  • Infos de l'usager : /wsapi/user/info ( ou juste /wsapi/user )

La dernière requête nécessite donc une authentification pour retourner le profil du l'usager authentifié.
Pour la seconde requête, seule la liste des sessions publiques sera retournée à défaut d'authentification.
La première requête quant à elle n'a aucun besoin d'authentification, les données transmises sont publiques.

Réponses

Toutes les commandes de l'API web fournissent des réponses similaires :
  • Content-type "application/json" avec encodage UTF-8
  • Contenu textuel représentant un objet au format JSON
  • L'objet contient toujours un premier champs "status" indiquant "OK" ou "ERROR"
  • L'ensemble des résultats (ou le message d'erreur) se trouve dans le second champs "data"

Updated by Grégory MARIGOT - TEICEE almost 2 years ago

  • Status changed from In Progress to Résolu
  • Target version changed from ProxyEPN 2.x to ProxyEPN 2.5
  • % Done changed from 80 to 100

Si les requêtes des webservices sont toujours amenées à s'aggrandir et à évoluer, il apparait toutefois que l'implémentation est correcte et fonctionnelle.

Par conséquent ce ticket concernant la mise en place est clos.

Updated by Grégory MARIGOT - TEICEE over 1 year ago

Des filtres peuvent être ajoutés sur les requêtes des webservices.

  • Liste des epn : 'structure_id', 'network_id', 'town_id', 'postcode', 'town', 'county', 'category_tag', 'category_tags'
  • Liste des sessions : 'type_id', 'room_id', 'departement', 'structure_cat', 'month', 'date_day', 'date_from', 'date_until', 'user_id', 'only_personal', 'limit'
Exemples :
  • /wsapi/epn/list?postcode=14&category_tags=label,antenne
  • /wsapi/session/list?type_id=4&structure_cat=label,antenne

Also available in: Atom PDF