¿Qué tiene de malo que un punto final devuelva HTML en lugar de datos JSON?

Cuando comencé a aprender PHP (hace unos 5 o 6 años) aprendí sobre Ajax y pasé por "las fases":

1. Tu servidor devuelve datos HTML y los pones dentro del innerHTML de un DOM
2. Aprenderá sobre los formatos de transferencia de datos como XML (y dirá "oooh, para eso ES para lo que se usa") y luego JSON.
3. Devuelve JSON y crea su interfaz de usuario utilizando el código JavaScript de vainilla
4. Te mudas a jQuery
5. Aprenderá sobre API, encabezados, códigos de estado HTTP, REST , CORS y Bootstrap
6. Aprende los marcos de SPA y frontend ( React , Vue.js y AngularJS ) y el estándar JSON API.
7. Recibe un código heredado de la empresa y, al inspeccionarlo, descubre que hacen lo que se describe en el paso 1.

Mientras trabajaba con esta base de código heredada, ni siquiera consideré que podría devolver HTML (quiero decir, somos profesionales ahora, ¿verdad?), Así que tuve dificultades para buscar el punto final JSON que devolvía los datos que las llamadas de Ajax pueblan. No fue hasta que le pregunté al "programador" que me dijo que estaba devolviendo HTML y que se estaba agregando directamente al DOM con innerHTML.

Por supuesto, esto fue difícil de aceptar. Comencé a pensar en formas de refactorizar esto en los puntos finales JSON, pensando en la prueba unitaria de los puntos finales, etc. Sin embargo, esta base de código no tiene pruebas. Ni uno solo. Y tiene más de 200 mil líneas. Por supuesto, una de mis tareas incluye proponer enfoques para probar todo, pero por el momento todavía no lo estamos abordando.

Así que no estoy en ninguna parte, en un rincón, preguntándome: si no tenemos pruebas de ningún tipo, entonces no tenemos una razón particular para crear este punto final JSON (ya que no es "reutilizable": literalmente devuelve datos que solo se ajustan a esa parte del aplicación, pero creo que esto ya estaba implícito ya que ... devuelve datos HTML).

¿Qué tiene de malo exactamente hacer esto?

¿Qué tiene de malo que un punto final devuelva HTML en lugar de datos JSON?

Nada en realidad. Cada aplicación tiene requisitos diferentes, y puede ser que su aplicación no esté diseñada para ser un SPA.

Puede ser que estos hermosos marcos que usted citó (Angular, Vue, React, etc.) no estuvieran disponibles en el momento del desarrollo, o no fueran cosas empresariales "aprobadas" para ser utilizadas en su organización.

Te diré esto: un punto final que devuelve HTML reduce tu dependencia de las bibliotecas de JavaScript y reduce la carga en el navegador del usuario ya que no necesitará interpretar / ejecutar código JS para crear objetos DOM: el HTML ya está allí, solo es cuestión de analizar los elementos y representarlos. Por supuesto, esto significa que estamos hablando de una cantidad razonable de datos. 10 megabytes de datos HTML no son razonables.

Pero dado que no hay nada de malo en devolver HTML, lo que está perdiendo al no usar JSON / XML es básicamente la posibilidad de usar su punto final como API. Y aquí está la pregunta más importante: ¿realmente necesita ser una API?

Relacionado: ¿Está bien devolver HTML desde una API JSON?

JSON y HTML cumplen dos propósitos semánticos diferentes.

Si está completando una página web con datos, use JSON. Si está creando una página web a partir de partes de páginas web, use HTML.

Puede parecer que son lo mismo, pero no lo son en absoluto. Por un lado, cuando está creando una parte de una página web utilizando HTML devuelto por el servidor, está trabajando en el lado del servidor. Cuando vincula datos a una página web, está trabajando en el lado del cliente.

Además, debe tener cuidado con HTML para no vincularse con una página específica. El objetivo de renderizar páginas parciales de esta manera es que los parciales sean reutilizables, y si hace que el parcial sea demasiado específico, no se compondrá en otras páginas. JSON no tiene este problema, porque son solo datos, no la estructura de la página web.

El principal problema es que une estrechamente el servidor con el cliente, que debe conocer la estructura HTML. También hace que los puntos finales sean más difíciles de reutilizar de nuevas formas o nuevas aplicaciones.

Devolver datos simples y dejar que el cliente los procese disminuye el acoplamiento y aumenta la flexibilidad y la capacidad de prueba: puede ejecutar pruebas unitarias en el cliente para obtener datos simulados y ejecutar pruebas unitarias en el servidor para probar los datos deseados.

Creo que lo tienes un poco al revés. Tu dices:

no tenemos ninguna prueba, por lo que no tenemos ninguna razón particular para crear este punto final JSON

Una razón para usar un punto final adecuado sería para que pueda probarlo. Yo diría que no tener exámenes es una muy buena razón para comenzar a escribir algunos. Es decir, si hay alguna lógica que sea adecuada para probar.

200k líneas de código es mucho para refactorizar y probablemente sean difíciles de mantener. Romper algunos puntos finales y probarlos podría ser un buen lugar para comenzar.

Otra razón podría ser separar el servidor del cliente. Si, en un futuro lejano, el diseño o el diseño de la aplicación cambia, es más fácil trabajar con un formato de datos adecuado que la salida HTML. En un mundo ideal, solo tendría que cambiar el cliente y no tocar el servidor en absoluto.

Hay 3 formas (¿al menos?) Para construir una página web:

• Genere todo el lado del servidor de páginas.
• Devuelva una página básica del servidor más código (JavaScript), y haga que la página obtenga sus datos y los procese en el lado del cliente HTML.
• Devuelva una página parcial más código, y haga que el código recupere los bloques de HTML previamente renderizados que puede colocar en la página.

El primero está bien. El segundo también está bien. Es el último el problema.

La razón es simple: ahora ha dividido la construcción de la página HTML en partes completamente desconectadas. El problema es de mantenimiento. Ahora tiene dos entidades separadas a cargo de administrar los detalles de la IU. Por lo tanto, debe mantener sincronizados CSS y otros detalles similares entre las dos piezas separadas. ¿Cambiaste el ancho de la barra lateral? Excelente. Ahora, el fragmento HTML que regresa causa desplazamiento horizontal porque sus supuestos sobre el ancho de la barra lateral ya no se mantienen. ¿Cambiaste el color de fondo para ese bloque? Genial, ahora el color de fuente de su fragmento HTML choca porque asumió un color de fondo diferente y alguien olvidó probar ese punto final.

El punto es que ahora ha dividido el conocimiento que debe centralizarse en un solo lugar (es decir, la lógica de presentación), y esto hace que sea más difícil asegurarse de que todas las piezas encajen correctamente. Al usar una API JSON, en su lugar, puede mantener toda esa lógica solo en el front-end, o puede mantenerlo todo en las plantillas del lado del servidor si, para empezar, procesa sus datos en HTML. Se trata de mantener el conocimiento / lógica de la presentación en un solo lugar, para que se pueda administrar de manera consistente y como parte de un solo proceso. HTML / CSS / JS es lo suficientemente difícil de mantener recto sin dividirlo en muchas piezas pequeñas.

Las API JSON también tienen el beneficio adicional de hacer que los datos estén disponibles de forma completamente independiente de la lógica de presentación. Esto permite que varios presentadores diferentes , como una aplicación móvil y una página web, consuman los mismos datos. En particular, permite consumir los datos sin un navegador (como aplicaciones móviles o trabajos cron nocturnos); Es posible que estos consumidores ni siquiera puedan analizar HTML. (Esto, por supuesto, se basa necesariamente en una situación en la que los datos son los mismos entre los diferentes consumidores, o uno puede usar un subconjunto del otro). Sin embargo, si necesita esta capacidad depende de los requisitos de su aplicación particular, mientras administra su presentación La lógica es necesaria independientemente. Sin embargo, diré que si lo implementa por adelantado, estará mejor preparado para el crecimiento futuro.

Diría que no hay nada de malo en que el servidor devuelva un fragmento HTML y la UI lo asigne a .innerHTML de algún elemento. Esta es, en mi opinión, la forma más fácil de desarrollar código JavaScript asincrónico. El beneficio es que se hace lo menos posible con JavaScript y se hace lo más posible en un entorno de fondo controlado. Recuerde que la compatibilidad con JavaScript en los navegadores varía, pero su back-end siempre tiene la misma versión de los componentes de back-end, lo que significa que hacer todo lo posible en el back-end significará la menor cantidad posible de incompatibilidades de versiones.

Ahora, a veces quieres más que solo un fragmento HTML. Por ejemplo, un código de estado y un fragmento HTML. Luego puede usar un objeto JSON que tiene dos miembros, statusCode y HTML, de los cuales el segundo puede asignarse a .innerHTML de algún elemento después de verificar el statusCode. Por lo tanto, el uso de JSON y el uso de innerHTML no son en modo alguno enfoques exclusivos alternativos; Se pueden usar juntos.

Al usar JSON, incluso puede tener múltiples fragmentos HTML en la misma respuesta que se asignan al .innerHTML de varios elementos.

En resumen: use .innerHTML. Hace que su código sea compatible con tantas versiones de navegador como sea posible. Si necesita más, use JSON y .innerHTML juntos. Evita XML.

No hay nada malo en principio . La pregunta es: ¿Qué quieres lograr?

JSON es perfecto para transmitir datos. Si envía HTML en su lugar y espera que el cliente extraiga los datos del HTML, eso es basura.

Por otro lado, si desea transmitir HMTL que se representará como HTML, envíelo como HTML, en lugar de empaquetar el HTML en una cadena, convertir la cadena en JSON, transmitir JSON, decodificarlo en el otro lado , obtener una cadena y extraer el HTML de la cadena.

Y ayer me encontré con un código que colocaba dos elementos en una matriz, convertía la matriz en JSON, ponía la JSON en una cadena, ponía la cadena dentro de una matriz, convertía toda la matriz en JSON, la enviaba al cliente, que decodificaba el JSON, obtuvo una matriz que contiene una cadena, tomó la cadena, extrajo el JSON de la cadena, decodificó el JSON y obtuvo una matriz con dos elementos. No hagas eso.

Todo esto depende del propósito de la API, pero en general lo que describe es una violación bastante fuerte de la separación de preocupaciones :

En una aplicación moderna, el código API debe ser responsable de los datos, y el código del cliente debe ser responsable de la presentación.

Cuando su API devuelve HTML, está estrechamente acoplando sus datos y presentación. Cuando la API devuelve HTML, lo único que puede hacer (fácilmente) con ese HTML es mostrarlo como parte de una página más grande. Desde un ángulo diferente, lo único para lo que la API es buena es proporcionarle a su página HTML. Además, ha extendido su HTML a través del código del cliente y del servidor. Esto puede hacer que el mantenimiento sea un dolor de cabeza.

Si su API devuelve JSON, o alguna otra forma de datos puros, se vuelve mucho más útil. La aplicación existente aún puede consumir esos datos y presentarlos adecuadamente. Ahora, sin embargo, otras cosas pueden usar la API para acceder a los mismos datos. Nuevamente, también, el mantenimiento es más fácil: todo el HTML reside en un solo lugar, por lo que si desea cambiar el estilo de todo el sitio, no necesita cambiar su API.

HTML está vinculado a un diseño y uso específicos.

Con HTML, si desea cambiar el diseño de la página, debe cambiar cómo se genera el html por la llamada al servidor. Por lo general, eso requiere un programador de fondo. Ahora tiene programadores back-end, que por definición no son sus mejores escritores html, manejando estas actualizaciones.

Con JSON, si el diseño de la página cambia, la llamada al servidor JSON existente no necesariamente tiene que cambiar en absoluto. En cambio, su desarrollador front-end, o incluso el diseñador, actualiza la plantilla para producir los diferentes HTML que desea a partir de los mismos datos básicos.

Además, el JSON puede convertirse en la base de otros servicios. Es posible que tenga diferentes roles que necesiten ver los mismos datos básicos de diferentes maneras. Por ejemplo, puede tener un sitio web del cliente que muestre datos sobre un producto en una página de pedido, y una página de ventas internas para representantes que muestre los mismos datos en un diseño muy diferente, tal vez junto con otra información no disponible para clientes generales. Con JSON, se puede usar la misma llamada al servidor en ambas vistas.

Finalmente, JSON puede escalar mejor. En los últimos años, nos hemos pasado de la raya con los marcos javascript del lado del cliente. Creo que es hora de dar un paso atrás y comenzar a pensar qué javascript estamos usando y cómo afecta el rendimiento del navegador ... especialmente en dispositivos móviles. Dicho esto, si está ejecutando un sitio lo suficientemente grande como para requerir una granja de servidores o un clúster, en lugar de un solo servidor, JSON puede escalar mejor. Los usuarios le darán tiempo de procesamiento en sus navegadores de forma gratuita, y si aprovecha esto, puede reducir la carga del servidor en una implementación grande. JSON también usa menos ancho de banda, así que de nuevo, si eres lo suficientemente grandey usarlo adecuadamente, JSON es mucho más barato. Por supuesto, también puede escalar peor, si termina alimentando bibliotecas de 40 KB para analizar 2 KB de datos en 7 KB de html, así que de nuevo: vale la pena estar al tanto de lo que está haciendo. Pero el potencial está ahí para que JSON mejore el rendimiento y los costos.

No hay nada de malo en tal punto final si cumple con sus requisitos. Si se requiere escupir html para que un consumidor conocido pueda analizarlo de manera efectiva, claro, ¿por qué no?

El problema es que, para el caso general, desea que sus puntos finales escupan una carga útil que esté bien formada y sea efectivamente analizable por un analizador estándar. Y por efectivamente analizable, quiero decir, analizable de manera declarativa.

Si su cliente se ve obligado a leer la carga útil y extraer bits de información abierta de él con bucles y sentencias if, entonces no es efectivamente analizable. Y HTML, siendo así, está muy perdonado al no requerir que esté bien formado.

Ahora, si te aseguras de que tu html es compatible con xml, entonces eres oro.

Dicho esto, tengo un problema importante con esto:

Te diré esto: un punto final que devuelve HTML reduce tu dependencia de las bibliotecas de JavaScript y reduce la carga en el navegador del usuario ya que no necesitará interpretar / ejecutar código JS para crear objetos DOM: el HTML ya está allí, solo es cuestión de analizar los elementos y representarlos. Por supuesto, esto significa que estamos hablando de una cantidad razonable de datos. 10 megabytes de datos HTML no son razonables.

Esa es una mala idea, no importa cómo la cortes. Décadas de experiencia industrial colectiva nos han demostrado que, en general, es una buena idea separar los datos (o modelo) de su visualización (o vista).

Aquí está combinando los dos con el fin de ejecutar rápidamente el código JS. Y eso es una micro optimización.

Nunca he visto esto como una buena idea, excepto en sistemas muy triviales.

Mi consejo? No lo hagas HC SVNT DRACONES , YMMV, etc.

JSON es solo una presentación textual de datos estructurados. Un cliente, naturalmente, necesita tener un analizador para procesar datos, pero prácticamente todos los idiomas tienen funciones de analizador JSON. Es mucho más eficiente usar el analizador JSON que usar el analizador HTML. Se necesita poca huella. No es así con un analizador HTML.

En PHP, solo usa json_encode($data)y depende del cliente del otro lado analizarlo. Y cuando obtiene datos JSON de un servicio web, simplemente usa $data=json_decode($response)y puede decidir cómo usar los datos como lo haría con las variables.

Supongamos que desarrolla una aplicación para un dispositivo móvil, ¿por qué necesita el formato HTML cuando las aplicaciones móviles rara vez usan el navegador web para analizar datos? Muchas aplicaciones móviles usan JSON (formato más común) para intercambiar datos.

Teniendo en cuenta que los móviles suelen estar en planes medidos, ¿por qué desea utilizar HTML que requiere mucho más ancho de banda que JSON?

¿Por qué usar HMTL cuando HTML tiene un vocabulario limitado y JSON puede definir datos? {"person_name":"Jeff Doe"}es más informativo de lo que HTML puede proporcionar sobre sus datos, ya que solo define la estructura de los analizadores HTML, no define los datos.

JSON no tiene nada que ver con HTTP. Puedes poner JSON en un archivo. Puede usarlo para configuraciones. Composer usa JSON. También puede usarlo para guardar variables simples en archivos.

Es difícil clasificar un bien o un mal. En mi opinión, las preguntas que haré son: "¿ debería " o " puede hacer con menos? ".

Cada punto final debe esforzarse por comunicarse con el menor contenido posible. La relación señal / ruido suele ser códigos HTTP <JSON <XHTML. En la mayoría de las situaciones, es bueno elegir el protocolo menos ruidoso.

Difiero en el punto sobre la carga del navegador del cliente por @machado, ya que con los navegadores modernos esto no es un problema. La mayoría de ellos están equipados para manejar códigos HTTP y respuestas JSON bastante bien. Y aunque no tiene pruebas en este momento, el mantenimiento a largo plazo de un protocolo menos ruidoso sería más barato que el anterior.