Je développe une application basée sur Zend Framework et je me suis retrouvé à écrire un squelette pour le module API. J'ai lu un peu sur le web et j'ai commencé à écrire le squelette basé sur Zend_Rest_Controller. Retiré ok, clé de connexion nécessaire pour utiliser l'API.API RESTful Zend Framework
Les questions ont commencé lorsqu'un collègue a commencé à implémenter le squelette dans une API appropriée pour l'une de nos applications. Il m'a dit qu'il pense qu'il serait mieux si nous avions seulement un Zend_Controller_Action étendu dans un contrôleur API et indexAction un Zend_Rest_Server qui gère l'objet.
Je suis un peu confus à ce sujet. De mon point de vue personnel, je voudrais avoir un contrôleur "plus grand que la moyenne" contenant chacune des 4 actions (obtenir, poster, mettre, supprimer) et un peu de logique dans chaque action plutôt qu'une action régie par Zend_Rest_Server.
Mon problème est que je ne peux pas déterminer laquelle des 2 solutions est la meilleure du point de vue de l'architecture; et bien sûr, le plus facilement maintenable au fil du temps.
Je vois. Cela devient intéressant ... Le problème mineur avec 'Zend_Rest_Controller' est que vous vous retrouverez avec un contrôleur plutôt gros, la deuxième solution étant la création d'un objet de service pour l'objet destiné à exposer via API. Et cela traduirait dans rest_controller-> object_service-> object-> object_model-> eventual_object_custom_abstraction ce qui je pense est assez difficile à maintenir dans une équipe sans étudier au préalable comment vous obtenez la représentation de l'objet final dans le contrôleur de repos –
Les détails de votre implémentation sont dépend vraiment de votre domaine, mais il semble que vous soyez sur la bonne voie, en général. Je ne sais pas exactement ce qu'il y a dans chacune de vos couches, mais lorsque je fais ce genre de choses, mes contrôleurs s'appuient sur une couche de service qui manipule les objets du domaine et gère le stockage/extraction via une couche de persistance quelconque. – timdev