Servicio MVC y RESTful API

MVC es bastante sencillo. Hay un modelo, un controlador y una vista. Cuando creamos un sitio web, todo se junta cuando el cliente envía la solicitud de palabra clave REST al servidor -> el servidor hace coincidir la URL solicitada con la acción del controlador -> que luego llama a los modelos para la recopilación / procesamiento de datos, obtiene el resultado -> y devuelve el resultado al cliente como una página HTML (vista) '.

¿Qué pasa si estamos hablando de un servicio web API RESTful puro? Luego, el flujo será algo así como 'el cliente envía una solicitud de palabra clave REST al servidor -> el servidor hace coincidir la URL solicitada con la acción del controlador -> que luego llama a los modelos para la recopilación / procesamiento de datos, obtiene el resultado -> y devuelve el resultado vuelve al cliente en JSON '. Igual que antes, pero no hay 'vista' ... o más bien, el JSON generado puede considerarse como una 'vista'. En cierto sentido, solo estamos utilizando la parte MC de MVC. ¿Es así como se debe hacer? ¿O hay otros patrones más adecuados para un servicio solo de API en lugar de MVC?

MVC es un paradigma del mundo Smalltalk preocupado por cómo los sistemas orientados a objetos podrían tener interfaces de usuario.

Los primeros marcos web tomaron la idea general (separar la lógica empresarial, la lógica de control y la lógica de vista) y aplicaron el principio de cómo estructuraban la aplicación web. Antes de esto, no era raro tener un desastre horrible de código de generación HTML dentro de objetos de dominio, o lógica de negocios dentro de plantillas HTML (piense en PHP muy temprano)

La cuestión es que el MVC original del mundo Smalltalk no es realmente lo que MVC es en la mayoría de los marcos web. Una salida HTML no es realmente una "vista" en el sentido de que Smalltalk entendió que era una pantalla UI.

Esa es la primera razón para no obsesionarse demasiado con si está siguiendo MVC correctamente. Casi nada lo es. Tómelo menos como una división estricta y más como una guía de Hey, ¿no sería bueno si nuestras plantillas HTML no estuvieran llenas de lógica empresarial?

En segundo lugar, MVC es solo una forma de estructurar el código del lado del servidor. Realmente no tiene nada que ver con REST / HTTP. REST se preocupa por cómo se comunican los clientes y servidores. No importa si la representación que el servidor envía al cliente está en una plantilla HTML que tardó mucho en construirse con un motor de plantillas o un objeto JSON que fue una llamada en el controlador.

Si no cree que su servidor necesita una capa de "vista", está bien. Aún obtendrá beneficios al separar su lógica comercial (es decir, el modelo) de los controladores que manejan una solicitud HTTP específica, incluso si todo el controlador llama a una llamada de análisis JSON en algún objeto y devuelve esos datos.

La vista es una capa responsable de mostrar información que puede ser interpretada por un usuario / cliente de su aplicación (no dice que el usuario deba ser una persona real). JSON es un formato completamente válido para una capa de vista, las computadoras lo entienden.

Siempre que la capa de vista publique información que un usuario pueda usar para afectar los modelos en su aplicación, no importa cómo se vea la vista, sigue siendo una vista, una capa que actúa como un middleware entre el usuario y el sistema .

MVC es bastante sencillo.

Martin Fowler, quizás, estaría en desacuerdo con esto :

Diferentes personas que leen sobre MVC en diferentes lugares toman diferentes ideas y las describen como 'MVC'.

Hacia adelante...

Cuando creamos un sitio web, todo se junta cuando el cliente envía la solicitud de palabra clave REST al servidor -> el servidor hace coincidir la URL solicitada con la acción del controlador -> que luego llama a los modelos para la recopilación / procesamiento de datos, obtiene el resultado -> y devuelve el resultado al cliente como una página HTML (vista) '.

OK, esto es un poco enredado

MVC, sea lo que sea, es una colección de ideas para implementar interfaces de usuario.

REST es una colección de restricciones arquitectónicas para construir aplicaciones a gran escala.

La web, de la que está hablando aquí, es una aplicación de gestión de documentos gigante creada utilizando la mayoría de esas mismas restricciones.

Las similitudes que está viendo entre los dos se atribuyen incorrectamente o son superficiales.

RESTafarians tienen una comprensión común de HATEOAS , "hipertexto como el motor del estado de la aplicación", y eso debería enviar alarmas sonando a través de su cabeza: ¿por qué una vista sería un motor de estado ? Si cuestionamos la premisa y buscamos evidencia adicional, también podríamos notar dos cosas extrañas.

Primero, que podemos sacar el servidor HTTP completamente de la ecuación cargando el HTML del disco. El navegador está perfectamente satisfecho con esto, excusando algunas variaciones menores en el comportamiento que pueden surgir del cambio en la URL base. Las vistas generalmente no continúan funcionando cuando se han desconectado completamente del modelo y el controlador de esa manera.

Segundo, si observamos cuidadosamente un navegador moderno, notaremos que hay múltiples vistas del HTML. Las vistas múltiples de una vista parecen una idea realmente extraña, pero efectivamente está la presentación principal, con un montón de marcado de texto que responde a los gestos del usuario, y luego está esta cosa de "Vista de origen" que muestra el HTML sin formato y también responde a gestos de usuario. ¡Son tortugas hasta el fondo!

La respuesta al enigma, por supuesto, es que el HTML no es la vista. La colección de widgets en el navegador es la vista, y están en comunicación con el Modelo de Objetos del Documento , que se inicializó leyendo el HTML.

En otras palabras, el HTML es una representación del estado, tal como prometió Roy T. Fielding .

¿Qué pasa si estamos hablando de un servicio web API RESTful puro ...? Igual que antes, pero no hay 'vista'

Más correctamente, igual que antes: no hay vista. El JSON, al igual que el HTML, es una representación del estado, adecuado para cruzar los límites del proceso.

Piense "DTO" o "Mensaje" y sus inferencias serán mucho menos propensas a desviarlo.

¿Es así como se debe hacer?

Pasar el JSON como una vista, o usarlo como un modelo de vista para construir la vista no viola el patrón.

Estoy usando la misma arquitectura en la aplicación actual en la que estoy trabajando y está funcionando muy bien. Junto con un buen marco JS, puede crear algunos diseños realmente receptivos.

¿O hay otros patrones más adecuados para un servicio solo de API en lugar de MVC?

Honestamente, no tengo idea. Pero creo que si usa MVC o no en una API no es tan importante. Use lo que encuentre conveniente. Cuando se habla de servicios web, hay muchos aspectos más importantes a considerar (que no están directamente relacionados con MVC), por ejemplo, seguridad, consistencia, disponibilidad, etc.