Tout d'abord merci pour ces retours !
En plus des images j'ai remarqué un problème de forme au niveau des liste à puce (tout tien sur une ligne) ainsi que quelques boite d'informations non formatée.
J'ai uploadé toutes les images. Tu devrais normalement les voir.
Pourrais-tu me donner des extraits avec des listes à puces mal formatées ou des images manquantes ?
Concernant l'authentification j'ai été déçu que tu ne parle pas des "standard" en la matière, si quelqu'un fait une API à moins qu'il ne la fait que pour lui même les personnes développant les applications clientes ne pourront pas utiliser de framework pour gérer l'identification puisque c'est un code spécifique.
Je suis parti du principe que l'API est développée pour un usage 'interne'. Tu fais ton API et tu l'utilises pour ton site ou pour ton application web. Je prévois une partie pour le développement d'API publique où OAuth , la documentation (Swagger + Swagger UI + NelmioApiDocBundle) et d'autres thèmes seront abordés.
Dans ton chapitre Premiéres interactions avec les ressources - lire (le "- lire" à mon avis tu peux le virer) tu introduis en disant que l'un des problème est de savoir si tel élément est ou non une ressource… sauf que tu ne répond pas à cette problématique.
Juste après dans la partie Notre première ressource, j'ai rajouté une citation qui provient du tour d'horizon des concepts REST où je décris c'est quoi une ressource.
Une interface REST gravite autour de ressources. Du moment où vous devez interagir avec une entité de votre application, créer une entité, la modifier, la consulter ou que vous devez l'identifier de manière unique alors vous avez pour la plupart des cas une ressource.
Je vais effectivement virer le 'lire' du titre.
Par ailleurs je ne suis pas d'accord, à par les entités de liaison, toute entités est une ressource si on veut accéder complètement à l'application via une API.
Tu rejoins donc ma définition de ressource (cf la partie en gras). 
Tu peux parfaitement avoir des entités que tu ne veux pas exposer via ton API.
Tu parles des collections (manyTo) et la récupération de celles-ci mais tu omet la partie envoie. Lorsque l'on ajoute/modifie une entité ayant un lien vers une autre (oneTo ou manyTo*) il y a un traitement particulier à faire et ne pas en parler va poser des problèmes à beaucoup de personnes désireuse de se lancer dans la construction d'une API.
Pour moi une ressource manyTo* peut être créée de plusieurs façons. Pour le cas des lieux (dans le cours), il est tout a fait possible de modifier la méthode de création pour avoir un payload du type
1
2
3
4
5
6
7
8
9
10
11
12
13
14 | `{
"name": "Disneyland Paris",
"address": "77777 Marne-la-Vallée",
"prices": [
{
"type": "",
"value": 0
},
{
"type": "",
"value": 0
}
]
}
|
Le traitement d'un tel payload relève plus de ton formulaire Symfony que de REST.
Encore merci pour les retours !!!
