Créez une note, puis retrouvez le même enregistrement

1. Réutilisez votre clé temporaire

Dans chaque commande, remplacez YOUR_API_KEY par la clé créée dans la section 3. La section Vue utilisera ensuite cette même clé.

Vérifiez d’abord que cet utilisateur peut créer une note dans Notes de formation → Notes. Une clé d’API ne lui accorde aucun droit supplémentaire : le POST utilise son droit perm_create.

2. Envoyez le POST valide

L’en-tête Content-Type: application/json annonce le format du corps. L’en-tête Authorization présente la clé Bearer.

curl --include \
  --request POST \
  --header "Authorization: Bearer YOUR_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{"title":"Note créée par l’API","body":"Même enregistrement, nouvelle porte d’entrée."}' \
  http://127.0.0.1:8069/training/api/notes

curl.exe --include --request POST --header "Authorization: Bearer YOUR_API_KEY" --header "Content-Type: application/json" --data '{"title":"Note créée par l’API","body":"Même enregistrement, nouvelle porte d’entrée."}' http://127.0.0.1:8069/training/api/notes

Résultat attendu : la première ligne contient exactement 201 Created. Le corps contient uniquement la clé racine note, puis uniquement id, title et body. Votre identifiant numérique dépend de votre base ; avec l’identifiant 4, la réponse exacte serait :

{
  "note": {
    "id": 4,
    "title": "Note créée par l’API",
    "body": "Même enregistrement, nouvelle porte d’entrée."
  }
}

Notez l’id réellement reçu. Une seule requête valide suffit : ne la rejouez pas, car chaque nouveau POST réussi créerait un autre enregistrement.

3. Refusez un titre manquant

Cette fois, le corps contient body, mais pas title. La clé reste valide : vous testez le contrat des données, pas l’authentification.

curl --include \
  --request POST \
  --header "Authorization: Bearer YOUR_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{"body":"Cette requête n’a pas de titre."}' \
  http://127.0.0.1:8069/training/api/notes

curl.exe --include --request POST --header "Authorization: Bearer YOUR_API_KEY" --header "Content-Type: application/json" --data '{"body":"Cette requête n’a pas de titre."}' http://127.0.0.1:8069/training/api/notes

Résultat attendu : la première ligne contient exactement 400 Bad Request, puis le corps JSON est exactement celui-ci :

{
  "error": {
    "code": "invalid_payload",
    "message": "Envoyez un objet JSON avec title (texte non vide) et body (texte, éventuellement vide)."
  }
}

Aucun enregistrement n’est créé. Vous obtiendriez le même refus avec un titre vide ou composé d’espaces, un title ou un body qui n’est pas une chaîne, une valeur racine qui n’est pas un objet, une clé supplémentaire ou un JSON mal formé.

4. Relisez la note avec le GET protégé

Envoyez maintenant la requête GET de la section 3 avec la même clé. Un GET n’a pas de corps JSON ; il garde donc l’en-tête Bearer, mais n’a pas besoin de Content-Type.

curl --include \
  --header "Authorization: Bearer YOUR_API_KEY" \
  http://127.0.0.1:8069/training/api/notes

curl.exe --include --header "Authorization: Bearer YOUR_API_KEY" http://127.0.0.1:8069/training/api/notes

Résultat attendu : la réponse contient 200 OK. Dans notes, retrouvez un objet dont l’id est celui noté après le POST, avec le titre Note créée par l’API et le même contenu. La valeur count a augmenté d’une unité par rapport à la lecture effectuée avant la création ; le POST refusé ne l’a pas augmentée.

5. Vérifiez le même enregistrement dans Odoo

1. Dans l’interface d’administration, ouvrez Notes de formation → Notes.
2. Ouvrez Note créée par l’API.
3. Vérifiez le titre et le contenu. Avec le mode développeur, vous pouvez aussi comparer l’identifiant de l’enregistrement à l’id renvoyé par le POST.

Il s’agit du même enregistrement training.note, écrit par l’ORM dans la même table training_note que les notes du jour 2. La réponse JSON n’est pas un fichier copié et ne constitue pas une seconde base de données : c’est seulement une représentation de l’enregistrement qu’Odoo vient de créer.

6. Gardez la clé pour le client Vue

Ne révoquez pas encore la clé et gardez cette variable dans le terminal. La section suivante la placera dans la configuration locale du serveur Vite, puis vous supprimerez cette configuration et la clé à la fin du Jour 4.