Estoy desarrollando una aplicación basada en Zend Framework y me encontré escribiendo un esqueleto para el módulo API. Leí un poco en la web y comencé a escribir el esqueleto basado en Zend_Rest_Controller. Resultó bien, se requiere el inicio de sesión clave para usar la API.RESTful Zend Framework API
Las preguntas comenzaron cuando un colega mío comenzó a implementar el esqueleto en una API adecuada para una de nuestras aplicaciones. Me dijo que cree que sería mejor si solo tuviéramos un Zend_Controller_Action extendido en un controlador API y en indexAction un Zend_Rest_Server que maneja el objeto.
Estoy un poco confundido acerca de esto. Desde mi punto de vista personal, me gustaría tener un controlador "más grande que el promedio" que contenga cada una de las 4 acciones (obtener, publicar, poner, eliminar) y un poco de lógica en cada acción en lugar de una acción gobernada por Zend_Rest_Server.
Mi problema es que no puedo entender cuál de las 2 soluciones es mejor desde el punto de vista de la arquitectura; y por supuesto, el más fácil de mantener con el tiempo.
veo. Esto se está poniendo interesante ... El problema menor con 'Zend_Rest_Controller' es que te encontrarás con un controlador bastante gordo, la segunda solución es la creación de un objeto de servicio para el objeto destinado a exponer a través de API. Y eso se traduciría en rest_controller-> object_service-> object-> object_model-> eventual_object_custom_abstraction que creo que es bastante difícil de mantener en un equipo sin estudiar de antemano cómo se obtiene la representación final del objeto en el resto del controlador –
Los detalles de su implementación son realmente depende de tu dominio, pero parece que estás en el camino correcto, en términos generales. No estoy seguro de qué es exactamente en cada una de sus capas, pero cuando hago este tipo de cosas, mis controladores confían en una capa de servicio que manipula los objetos de dominio y maneja el almacenamiento/recuperación a través de una capa de persistencia de algún tipo. – timdev