Créez une API REST avec Symfony 3

Tout au long de ce cours, nous allons apprendre à mettre en œuvre les principes de REST pour concevoir et développer une API web avec Symfony 3.

a marqué ce sujet comme résolu.
Auteur du sujet

Tout le monde se secoue ! :D

J'ai commencé (il y a 2 heures) la rédaction d'un tutoriel au doux nom de « Créez une API REST avec Symfony 3 » et j'ai dans l'objectif de proposer en validation un texte aux petits oignons. Je fais donc appel à votre bonté sans limite pour dénicher le moindre pépin, que ce soit à propos du fond ou de la forme. Vous pourrez consulter la bêta à votre guise à l'adresse suivante :

Il manque un seul chapitre pour une partie pratique et les images que je n'ai pas encore uploadées. Sinon le cours est théoriquement complet. Il pourrait y avoir deux ou trois chapitres en plus sur le moyen termes.

Merci !

Édité par BestCoder

Auteur du sujet

salut la source, Il n'y a pas eu de réponses mais j'ai vu quelques +1. Je suppose donc qu'il faut un peu de temps pour lire le contenu qui est assez conséquent avant de commenter. J'attends donc tes retours avec impatience !

Édité par BestCoder

J'ai procédé à une première lecture et je suis content, j'ai appris des choses que j'ignorais.

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.

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 pense que dans un deuxième temps il serait très intéréssant d'ajouter un partie authentification AOuth2.

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.

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.

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.

Ce qui serai bien aussi c'est ne fusse que d'introduire quelque par la possibilité de générer automatique la documentation de l'API avec (par exemple) nelmio/NelmioApiDocBundle

Voilà pour une réaction à chaud ;)

#JeSuisArius

+0 -0
Auteur du sujet

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 !!!

Édité par BestCoder

Auteur du sujet

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l'adresse suivante :

Le chapitre TP vient d'être rajouté. Je proposerai donc le cours à la validation dans la semaine.

Merci d'avance pour vos commentaires.

Édité par BestCoder

Salut,

Je ne pas encore lu ta mise à jour, cependant j'ai globalement suivit ton tuto (j'ai fais un mix avec les choses que je ne connaissais pas et les choses que j'ai pu apprendre par-ci par-là et j'ai un problème avec les tests fonctionnel.

Je vois que tu n'en parle pas dans ton tuto, même s'il est vrai que ce n'est pas directement lié… il y a finalement peu de tuto qui en parle et c'est bien dommage car sa augmente la fiabilité dans le temps de l'application.

Ceci étant, je me permets de linker mon problème au cas où tu aurai une idée ^^

Ha, pour peut-être complété ton tuto, pour ma part pour éviter de devoir mettre des annotation View partout (même s'il faut en mettre pour les code http retour autre que 200) j'utilise l'annotation RouteResource.

Par ailleurs pour éviter de devoir pour chaque controller m'amusé à chaque fois recoder exactement la même chose au niveau des actions de base, j'ai créé une classe RestController dont hérite mes "vrai" controller, au niveau des convention de nommage il y a une version raccourcie qui permet de matcher automatiquement tel que cgetAction, getAction, postAction, putAction

#JeSuisArius

+0 -0
Auteur du sujet

Salut,

Le tutoriel est passé en validation.

Ha, pour peut-être complété ton tuto, pour ma part pour éviter de devoir mettre des annotation View partout (même s'il faut en mettre pour les code http retour autre que 200) j'utilise l'annotation RouteResource.

Cette annotation est plutôt utile si tu veux décorréler le nom de la ressource et celui du contrôleur.

Par ailleurs pour éviter de devoir pour chaque controller m'amusé à chaque fois recoder exactement la même chose au niveau des actions de base, j'ai créé une classe RestController dont hérite mes "vrai" controller, au niveau des convention de nommage il y a une version raccourcie qui permet de matcher automatiquement tel que cgetAction, getAction, postAction, putAction

La source

J'ai fait le choix de ne pas utiliser le système de routage automatique car cela peut rapidement avoir des limitations. (Code de retour à personnaliser, nom d'url à personnaliser, etc.)

En tout cas merci pour les retours.

Um… j'ai implémenté la partie sécurité aujourd'hui sur mon propre projet en me basant sur ton tuto.

J'ai vu ici et là des petits points qui manquais encore tel des blocks infos mal formaté ou bien dans le code l'absence des attributs (je pense ici à la classe AuthTokenUserProvider).

En tout cas c'est un tuto que j'apprécie fortement ^^ et je dirai qu'il est tombé à point nommé pour moi :p

#JeSuisArius

+0 -0
Auteur du sujet

Merci du retour. J'ai rajouté les attributs et corrigé le bloc info qui ne s'affichait pas. (sans les attributs, PHP considère qu'ils sont en visibilité public ^^)

Merci d'avance pour vos commentaires.

Édité par BestCoder

Ce sujet est verrouillé.