GraphQL API
La GraphQL API de Jahia (l’API GraphQL) est l’interface de programmation recommandée pour travailler avec le CMS. Elle permet à une application de demander en une seule requête typée exactement les contenus dont elle a besoin. Elle interroge directement le référentiel (Content Repository), en précisant l’espace de travail visé, celui des contenus en cours d’édition ou celui des contenus publiés.
Définition et fonctionnement
GraphQL est un langage de requête pour les API. Au lieu d’appeler plusieurs adresses qui renvoient chacune un bloc de données figé, l’application cliente décrit dans une seule requête les champs exacts dont elle a besoin. Elle reçoit une réponse de même forme. Le schéma, typé, documente ce qu’il est possible de demander.
Pour une organisation, l’enjeu est de servir les mêmes contenus à plusieurs interfaces (site, application mobile, intranet, bornes) sans dupliquer la saisie. Les équipes front-end travaillent avec un outillage qu’elles connaissent. Chaque écran ne charge que ce qu’il affiche. C’est la base d’un usage en CMS headless (contenus servis par API à des interfaces séparées) ou en CMS hybride.
Les développeurs peuvent étendre le schéma avec leurs propres types et requêtes, déployés avec leur module. L’accès reste soumis aux permissions de Jahia et peut être protégé par des jetons. Un outil, GraphQL Playground, accessible depuis l’administration de Jahia (Developer Tools) aux utilisateurs qui en ont le droit, sert à écrire et tester les requêtes.
Documentation Academy : interroger Jahia avec GraphQL
Termes liés : Content as a service · CMS headless · Content Repository · CMS hybride · Système de gestion de contenu (CMS) · Intranet
Ressources sur ce terme
- CMS headless ou traditionnel : comment bien choisir
- Personnalisation avec un CMS headless : comment délivrer des expériences réellement adaptatives
- Qu'est-ce que le contenu en tant que service (CaaS) ?
- Qu’est-ce qu’un CMS Headless ? La vraie définition
- 10 astuces pour réussir avec un CMS headless
- Avantages du CMS Headless Enterprise pour le multisite
L’API GraphQL et le CMS headless : les différences
GraphQL est un moyen d’accès, pas une architecture. Un CMS headless ou une approche content as a service désignent la façon dont on organise la diffusion des contenus. L’API GraphQL est l’un des outils qui la rendent possible.
| Notion | Ce qui la distingue |
|---|---|
| CMS headless | Un système de gestion de contenu sans couche de présentation intégrée, qui distribue ses contenus par API. Jahia peut être utilisé ainsi, ou rendre lui-même les pages. |
| Content as a service | Un modèle où les contenus sont exposés comme un service consommé par différentes interfaces. L’API en est le canal. |
| Content Repository | Le référentiel stocke les contenus et leurs relations. L’API GraphQL l’interroge sans le remplacer. |
L’API GraphQL en pratique
Une organisation publie ses fiches d’offre sur son site et dans son application mobile. Les contributeurs saisissent une seule fois dans Jahia. Le site affiche la fiche complète. L’application, via l’API GraphQL, ne demande que le titre, l’accroche et l’image, dans la langue de l’utilisateur et depuis l’espace de travail des contenus publiés.
Une requête qui fonctionne avec un compte de développement ne prouve pas que le contenu est accessible au public. Le test se fait avec les droits réels de l’application.
Questions fréquentes
Faut-il passer en headless pour profiter de l’API GraphQL de Jahia ?
Non. L’API GraphQL peut alimenter une application ou un front-end séparé tout en laissant Jahia rendre lui-même les pages du site principal. Les deux usages se combinent, avec des pages gérées dans Jahia pour le site et des contenus servis par API à une application mobile ou à un autre canal. Le choix dépend de vos équipes front-end et de vos canaux.
L’API GraphQL contourne-t-elle les droits définis sur les contenus ?
Non. Les requêtes restent soumises aux permissions de Jahia. Une application n’obtient que ce que l’identité utilisée a le droit de lire, dans l’espace de travail demandé. L’accès peut être protégé par des jetons. C’est à l’équipe technique de définir l’identité avec laquelle chaque application interroge l’API et de limiter ses droits au strict nécessaire.
Peut-on exposer des données métier spécifiques par l’API GraphQL ?
Oui, par extension. La documentation Academy décrit la possibilité de définir ses propres types et requêtes dans le langage de schéma de GraphQL, puis de les déployer avec un module. Une équipe peut ainsi offrir à ses applications une requête adaptée à son métier plutôt que de leur faire parcourir le référentiel. C’est un développement à cadrer et à maintenir.