2.4 Principes de conception communs

Les éléments de conception communs au Front et au Back se situent tous au niveau de la conception des APIs.


2.4.1 - Conception depuis le besoin

Les APIs exposées aux démarches comme aux autre micro-services (et donc les services qui sont derrière) se conçoivent à partir du besoin (et de la faisabilité bien-sûr). Ceci comprend le choix des paramètres (et de leur type) et les données retournées.


2.4.2 - Format d’échange JSON

Toute donnée issue d’une API du socle doit être au format JSON. Même si cette donnée n’est qu’une simple chaîne de caractères (comme un identifiant dans BrouillonControlleur).


2.4.3 - Sémantique REST

Tous les services métiers développés dans les micro-services du socle ont pour objectif d’être utilisés depuis une application FRONT Angular ou depuis un autre micro-service. Ceci passe donc par une API REST. Ces APIs doivent respecter les règles de base de la sémantique REST (pas forcément l’ensemble de cette sémantique) :

  • Une URL doit désigner une ressource précise (à un instant donné en tout cas).
  • Tout service appelé via une API doit être stateless (plus généralement, tout service métier du socle doit être stateless).
  • Les méthodes HTTP doivent être correctement :
    • POST pour créer une donnée ou exécuter une recherche multi-critère
    • GET pour lire une ou plusieurs données
    • PUT pour mettre à jour tous les attributs d’une donnée existante
    • PATCH pour mettre à jour un ou plusieurs (pas tous) attributs d’une donnée existante
    • DELETE pour supprimer une donnée
  • Les types de média utilisables sur ce projet sont limités :
    • application/json pour tout échange de données (notamment pour les réponses retournant des données structurées) ;
    • multipart/formdata pour les télé-versements bruts de pièce jointe ;
    • tous les types de média associés au téléchargement d’un document comme application/pdf ou image/png, …

2.4.4 - Sécurisation des APIs REST

Toutes ces APIs (sauf certaines du projet socle-securite) sont protégées par des filtres vérifiant que la requête contient un jeton d’autorisation.

Ce jeton, dans le cas du socle, est un token JWT. Ce dernier est créé via un appel aux APIs du projet socle-securite (c’est pour ça que ces APIs ne sont pas toutes sécurisées) et il contiendra toutes les données de l’utilisateur connecté.

Fonctionnement, même dans le cas d’un usager d’une démarche non-connectée, un token sera créé. Ceci permet de limiter l’usage frauduleux des APIs (comme les APIs de référentiel) mais aussi de faire un suivi assez fin des appels via les access.log.

Information utile : le site jwt.io permet de lire la partie publique d’un token JWT.