Documentation

L'API des agents.

Version 1, 57 routes, huit rôles. Elle permet à un programme de construire et modifier un site JEIKO — pages, catalogue, menus, questionnaires, e-mails, identité visuelle.

Le premier appel

Le mode d'emploi vit à la racine de l'API. Il est généré depuis le code — les routes sont lues dans le routeur, les permissions sur les classes de vue, les options des blocs dans les constantes que le rendu applique. Il ne peut donc pas décrire une route qui n'existe pas, ni taire une permission.

GET https://votresite.fr/api/agent/v1/
Authorization: Bearer jk_ag__

{
  "version": { "numero": "1" },
  "points_d_entree": [ … 57 routes, chacune avec sa permission … ],
  "catalogue_des_blocs": { … 23 types de contenu … },
  "champs_de_page": { … },
  "interdits": [ … ]
}

Authentification

Un jeton porteur, et lui seul. Sept gardes s'empilent avant qu'un appel n'atteigne une vue.

• HTTPS obligatoire — un jeton ne circule pas en clair
• En-tête Authorization uniquement : jamais dans l'URL, où il finirait dans les journaux du serveur et l'historique du navigateur
• La session n'authentifie pas. Un administrateur connecté sans jeton est refusé comme un inconnu — c'est ce qui rend l'exemption CSRF de ces vues légitime au lieu d'être un trou
• Comparaison à temps constant, agent actif, expiration, liste d'adresses autorisées, plafond d'appels
• Le secret n'est jamais enregistré — seule son empreinte SHA-256 l'est. Une base lue ne livre aucun accès

Les refus ne s'expliquent pas : même message, même code, quelle que soit la cause. Le motif précis va au journal, qui est pour l'exploitant — le distinguer apprendrait à un appelant hostile où il en est.

Les routes

Chacune annonce la permission qu'elle exige : un agent sait avant d'appeler s'il en a le droit, plutôt que de le découvrir sur un refus.

Les huit rôles

Un mandat par domaine, accordé et retiré séparément. On ne donne pas à un agent qui rédige des pages le droit de lire les rendez-vous pris.

• Agent éditeur de pages — créer et modifier des pages. Jamais en supprimer
• Agent fiches et boutique — types de fiche, fiches, produits, types de produit
• Agent menus — navigation et affectation aux catégories, ce qui permet des sous-sites
• Agent design — couleurs et polices. Une erreur ici abîme toutes les pages à la fois : c'est un mandat à part
• Agent e-mails — sujet et corps des messages transactionnels. Aucun accès aux journaux d'envoi
• Agent questionnaires — construire un test. Aucun accès aux passages ni aux prospects
• Agent calendrier — types de rendez-vous et disponibilités
• Agent agenda (lecture) — lire les rendez-vous pris, nom et adresse compris. Rôle distinct, parce que ce sont des données personnelles

Ce que l'API refuse, et pourquoi

Les refus ne sont pas des précautions décoratives : chacun ferme un cas où la base aurait accepté quelque chose d'inexploitable.

• Aucune suppression de page. Ni route, ni permission — deux barrières, parce qu'une seule finit par céder
• Une clé inconnue est refusée, jamais ignorée. Un appelant ne peut pas se corriger si personne ne lui dit qu'il s'est trompé
• Rien n'est publié à la création — pages, fiches, produits, questionnaires naissent en brouillon
• Un jeton d'e-mail que l'événement ne fournit pas est refusé : il partirait en clair chez le destinataire
• Un poids vers le profil d'un autre questionnaire est refusé : le calcul deviendrait faux sans rien signaler

Voir la fonctionnalité