api Rest et Symfony [2.x]

Hello,

Alors dans l'ordre : oui si tu veux s�parer l'API du frontal, il te faudra faire deux projets (Symfony ou non) : ton frontal (ecommerce) utilisera un service ou un sdk ou un client (peu importe comment tu l'appelles) pour appeler ton API.

Pour ce qui est du mod�le, � partir du moment ou les projets sont s�par�s il y a des chances pour qu'une petite partie du mod�le soit dupliqu�e. � toi de faire en sorte de mettre le maximum de traitement dans ton API pour ne pas avoir � traiter avec des objets du mod�le cot� frontal (dans un monde parfait si ton projet est "full-api" ton ecommerce n'aurait pas du tout besoin du mod�le).

Seulement ton backoffice va avoir besoin du mod�le : est-ce que tu comptes API-fier ton BO ? Si la r�ponse est oui, alors le fonctionnement est le m�me, sinon pr�pare toi � dupliquer tout ton mod�le si tu veux le mettre du cot� de l'ecommerce

Lorsque tu passes une commande, ton ecommerce aura par exemple une classe MyRESTClient � laquelle tu injecteras tous les credentials n�cessaires pour pouvoir faire des call API et tu n'auras qu'� faire quelque chose du genre $myRESTClient->createOrder($data);, cette m�thode ne fait que transformer les options pass�es en une requ�te ) ton API, c'est elle � ce moment qui fait le traitement donc c'est l'API qui a besoin de Doctrine.

Je tiens � dire que je n'ai pas mis en pratique le d�veloppement d'API, mais j'ai commenc� � faire quelques recherches pour aller dans ce sens et c'est comme �a que j'aborderais le probl�me.
++

Est-ce que ton backend poss�dera aussi une API ou est-ce que ces actions se trouveront cot� ecommerce ?

Pour moi il serait judicieux de commencer ton API par le backend puisque justement il ne s'agit globalement que de m�thodes CRUD et qu'elles sont relativement simples.
Si tu fais �a, tu peux regrouper le frontend et backend dans une seule app et aucune des deux n'a besoin du mod�le ou de doctrine : les deux utilisent l'API.

Bonjour,

D�j�, sache que tu pourrais tout faire dans le m�me projet (bundles diff�rents, mais dans le m�me projet), ou encore exposer les adresses � plusieurs formats (content negociation).

J'aime bien l'id�e de s�parer, �a peut permettre au besoin de changer compl�tement ton front (par exemple tout passer en AngularJS et utiliser un framework comme ionic pour g�rer tous les fronts avec les m�me composants - bower et diff�rents repositories pour chaque directive angular). Pour le backend, tu peux aussi faire des modules (packages) que tu charges via composer (en g�n�ral on mets la couche m�tier dans un package, comme �a si on en a besoin dans plusieurs sites on fait juste un composer require).

Pour moi tes objets m�tiers vont dans les deux projets. Dans le projet webservice, ils vont communiquer avec la base de donn�e (� l'aide d'un service qui fait le mapping avec tes entit�s doctrine), et en "front" tu les hydrates depuis le webservice.