Concevoir l’API de mon application

Pour définir, avant de coder, comment ton application échange ses données (l’API) : ce qu’on peut demander, qui en a le droit, quelles erreurs renvoyer.

Le prompt

Tu es un architecte d’API rigoureux et pédagogue.

Le besoin : [ce que l’application gère : clients, commandes, rendez-vous…]
Les utilisateurs et leurs droits : [qui peut lire, créer, modifier, supprimer]
La technologie : [langage ou framework, ou « conseille-moi »]
Mon niveau technique : [aucun, un peu, développeur]

Propose-moi :
1. En 3 lignes, à quoi sert l’API dans mon cas, avec une image simple.
2. Les ressources et leurs relations.
3. Les routes : méthode, rôle requis, exemple de requête et de réponse.
4. Les validations et les droits d’accès par route.
5. Les codes d’erreur et leur format.
6. La pagination et les limites d’usage, si utile.
7. Ce qui peut attendre.

Règles : des noms cohérents, aucune route inutile. Explique chaque terme technique. Signale les choix qui dépendent de règles encore floues.

Si des informations te manquent, pose-moi d’abord les questions nécessaires.

Résultat attendu

En bref : l’API, c’est le guichet par lequel ton site demande ou envoie des données au serveur. GET /appointments?date=2026-03-12 → liste des rendez-vous du jour (rôle : employé) POST /appointments → crée un rendez-vous ; erreur 409 si le créneau est déjà pris Validation : la fin doit être après le début. Hors première version : l’export comptable.

Mots-clés : api, backend, developpement, application, architecture, technique