Discussion :

[dukoid]

Bonjour,

J'ai quelques questions philosophiques sur l'utilisation de l'api Rest et surtout comment le mettre en place.

Imaginons un gros site e commerce. Je veux utiliser Rest afin que plusieurs plateformes(mobiles, tablet, desktop..) puissent récupérer les données (articles,commandes...)

donc, il va falloir 2 projets Symfony : comme ça je peux installer ces 2 projets sur des serveurs séparés, c'est ce qu'il y a de mieux à faire, non ?
- un projet Symfony serveurRest : fournir les données (articles, commandes... ) au format json
- un projet Symfony eCommerce :

le projet serveurRest contiendra donc les entités avec les annotations Rest

mes questions sont les suivantes :
- comment je gère les entités dans serveurRest et eCommerce ?
- le backend doit être gérer à partir de eCommerce ?
- lors de la création d'une commande dans eCommerce, on utilise donc rest sur le serveurRest et non plus doctrine comme d'habitude ?

[Nico_F]

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.
++

[dukoid]

Merci,

est-ce que tu comptes API-fier ton BO ?

je n'ai pas compris

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

justement, je voudrais savoir ou il serait le plus judicieux d'implanter le BackOffice (coté serveur rest ou coté eCommerce)

[Nico_F]

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.

[tdutrion]

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.

[dukoid]

et bien voilà, je comprends mieux maintenant. tu as répondu à toutes mes questions. merci

pour ceux que ça intéresse, 2 applications séparés (pour les performances et la gestion)

- une application serveur Rest qui va permettre de fournir des données(produits...) mais aussi d'enregistrer d'autres (commandes...)
c'est cette appli qui va contenir les modèles

- une application frontEnd(eCommerce ) et le BackOffice.
on accède au serveur rest via une API client REST (pour récupérer des données ou en enregistrer)


ça me plait !




@theocrite

ça peut permettre au besoin de changer complètement ton front (par exemple tout passer en AngularJS

c'est l'idée, avoir plusieurs applications ou qu'ils soient et de pouvoir accéder aux données de l'api rest.