API Simplicité pour external Frontend integration

4.0
API Simplicité pour external Frontend integration
0.0 0
Tags: #<Tag:0x00007f8b6beb41e8>

#1

Bonjour,
Je me permets de vous écrire, car je travaille actuellement sur la mise en forme et mise en page de notre application afin de la rendre un peu plus accessible à un public moins avertis et expert. L’idée est donc de se défaire des layouts proposés par Simplicité, pour arriver sur qqch de plus conventionnel, sur une charte graphique que nous sommes entrain de définir et mettre en place, avec une expérience utilisateur retravaillée.

Pour cela, je m’étais initialement dirigé sur un redesign en interne de l’application Simplicité : appliqué un template sur l’affichage actuel. Mais si mes souvenirs sont bons, je sais qu’il n’est possible de modifier que le contenu même de la page, pas la présentation des menus et autres.

C’est une des raisons qui font que je me tourne aujourd’hui vers un design d’une app externe en se servant de l’API REST de Simplicité (s’il y en a une disponible évidemment - je préférais un REST API à un SOAP). L’idée est donc de travailler avec la librairie ReactJS ou le framework AngularJS (je dois avouer ma préférence pour ReactJS qui me faciliterait la tâche comparé à une intégration 100%JS et galèrerais sur la configuration de mes routes) et d’afficher les données en faisant appel à Simplicité via un REST API, avec les classiques GET, POST, PUT et DELETE. Utiliser cette méthode me permettrait donc d’avoir le design que je souhaite en affichant ce que je souhaite. Le problème est que je n’ai pas trouvé de doc expliquant clairement l’API de Simplicité (ou je n’ai pas correctement orienté ma recherche, le cas échant, j’en suis désolé) :

  • Oauth2 authentification + token et le garder pour la cession pendant la navigation (je travaille souvent avec le X-CSRToken)
  • le ReadMe classique pour les méthodes d’appel ainsi que les routes et le JSON (ou XML) de réponse comme on peut en trouver sur Github ou l’on peut voir : To get the list of all your propeties :
    GET : api/mydomain/properties/
    And the API endpoint for details :
    All methods : api/mydomain/properties/{id}/
  • Est-ce qu’il y a un moyen de modifier les réponses du Back pour n’afficher que quelques champs dans la réponse à la requête plutôt que les 150 champs de l’objet. Cela permettrait d’augmenter la sécurité car la réponse complète à la requête ne serait pas récupérable.

Je ne sais pas si j’ai étais clair dans ma demande, En attendant votre réponse, Bonne soirée à vous, Thomas


#2

Il y a plusieurs manière de faire des pages spécifiques avec Simplicité:

Ensuite en termes d’APIs il y a plusieurs niveaux sur lesquels vous pouvez taper dans vos pages spécifiques:

  1. L’API de haut niveau UI (cf. https://www.simplicite.io/resources/documentation/04-ui/responsive.md)
  2. L’API de niveau intermédiaire DATA (cf. https://www.simplicite.io/resources/documentation/03-apis/ajax-api.md), NB: les APIs niveau UI ci-dessus sont une surcouche de celles-ci
  3. L’API de bas niveau JSON/REST (cf. https://www.simplicite.io/resources/documentation/02-integration/rest-services.md), qui se décrit notamment en OpenAPI

Selon le type de UI spécifiques que vous envisagez de développer le choix doit se porter de préférence sur l’une ou l’autre histoire de ne pas “réinventer la poudre”.

  • dans un objet externe en zone authentifiée il faut clairement privilégier l’API 1
  • dans un objet externe en zone publique il faut privilégier l’API 1 ou 2
  • dans une UI frontend externe (ex: une appli mobile native iOS ou Android ou un site web spécifique basé sur tel ou tel framework à la mode) il faut privilégier l’API 3
    etc.

Et, bien entendu, toute l’intelligence métier (règles de gestion, calculs, …) de votre application doit exclusivement être développée du coté serveur (typiquement dans les hooks des objets métier). En effet, si vous mettez la moindre l’intelligence métier dans vos UI spécifique vous ne faites clairement pas les choses au bon endroit (pour d’évidentes raisons de mutualisation, homogénéité, sécurité, fiabilité, auditabilité, etc.): vos composants de présentation spécifique (qui appellent les APIs 1, 2 ou 3 ci-dessus) ne doivent faire que de la présentation.

Par exemple le fait de rendre accessibles et/ou modifiables tels ou tels attributs via les accès API relève de règles métier à implémenter coté serveur (il y a pour ça plusieurs approches : héritage, contraintes, hooks, …)


#3

Bonjour David et merci pour cette réponse.

Je pense que je vais partir sur l’API 3 car je m’oriente plus sur une UI frontend externe. Les designs sur lesquels on travaille sont facilement intégrables en ReactJS.

Evidemment, le front ne sera que de l’affichage, aucune règle de gestion, calculs et autres ne sera fait en front. On devrait être sur du ReadOnly pour une grande majorité des champs.

Je vais donc lire la doc 3 et faire des essais sur Postman. Si jamais je rencontre des difficultés, je reviendrais vers vous !

Bonne journée,

Thomas


#4

Oui tu peux faire des tests sur Postman sinon il y a le testeur d’API intégré à Simplicité sur /api, exemple d’usage sur cette video:


#5

Pour rendre accessible tes objets via API il faut créér un groupe de droits front avec les droits qui vont bien (read-only dans ton cas si je comprends bien), il faut créer un user technique (en statut “web services only”) habilité à ce groupe.

Sur la démo il y a le user website et son groupe DEMO_PUBLIC qui est configuré dans cette logique

Je recommanderais aussi de mettre en “forbidden” (via le hook postLoad) les attributs qui n’ont pas à être exposés publiquement (en checkant si le user est dans le groupe front) et/ou jouer sur l’héritage pour avoir des objets back habilités en back qui héritent d’objet front habilités en front plus restreints en termes de nombre d’attributs etc. Bref il faut bien réfléchir à ce qu’on expose en front*…


#6

Une dernière chose, l’authent via user/password est Ok pour un appel ponctuel mais pour une UI front qui fait de nombreux appels successifs il faut impérativement utiliser les tokens, cf. https://www.simplicite.io/resources/documentation/02-integration/services-auth.md