¿Qué está realmente mal con un punto final que devuelve HTML en lugar de datos JSON?

  

¿Qué está realmente mal con un punto final que devuelve HTML en lugar de datos JSON?

Nada, de verdad. Cada aplicación tiene requisitos diferentes, y puede ser que su aplicación no haya sido 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 estuvieran "aprobados" para ser utilizados en su organización.

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

Pero como 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 una API. Y aquí radica la mayor pregunta: ¿es realmente necesario que sea una API?

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

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

Si está poblando una página web con datos, use JSON. Si está construyendo una página web a partir de porciones de páginas web, use HTML.

Es posible que suenen como si fueran la misma cosa, pero no lo son, en absoluto. Por un lado, cuando está creando una parte de una página web con el HTML devuelto por el servidor, está trabajando del lado del servidor. Cuando está vinculando datos a una página web, está trabajando < em> lado del cliente.

Además, debes tener cuidado con el HTML para no vincularlo a una página específica. El objetivo de representar 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 estructura de páginas web.

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

Devolver datos sin formato y dejar que el cliente los represente reduce el acoplamiento y aumenta la flexibilidad y la capacidad de prueba; puede ejecutar pruebas unitarias en el cliente para datos simulados y ejecutar pruebas unitarias en el servidor para probar los datos deseados.

Creo que lo tienes un poco al revés. Usted dice:

  

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

Una razón para utilizar 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. Desprender 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 con 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 crear una página web:

• Generar todo el lado del servidor de la página.
• Devuelva una página completa desde el servidor más el código (JavaScript), y haga que la página obtenga sus datos y los genere 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.

El motivo es simple: ahora ha dividido la construcción de la página HTML en partes completamente desconectadas. El problema es uno de mantenimiento. Ahora tiene dos entidades separadas a cargo de administrar los detalles de la interfaz de usuario. Por lo tanto, debe mantener CSS y otros detalles similares sincronizados entre las dos partes separadas. ¿Cambiaste el ancho de la barra lateral? Genial. Ahora, el fragmento HTML que se devuelve provoca el desplazamiento horizontal porque ya no se mantienen las suposiciones sobre el ancho de la barra lateral. ¿Cambiaste el color de fondo para ese bloque? Genial, ahora el color de la fuente de tu 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 debería estar centralizado en un solo lugar (a saber, la lógica de presentación), y esto hace que sea más difícil asegurarse de que todas las piezas encajen correctamente. Al utilizar una API JSON, puede mantener toda esa lógica solo en el extremo frontal, o puede guardarla en las plantillas del lado del servidor si, para empezar, presenta sus datos en HTML. Se trata de mantener el conocimiento / la lógica de la presentación en un solo lugar, por lo que se puede gestionar de forma coherente y como parte de un proceso único. HTML / CSS / JS es lo suficientemente difícil como para mantenerlo en línea recta sin dividirlo en muchos pedazos pequeños.

Las API de 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 cronales nocturnos); Es posible que estos consumidores ni siquiera puedan analizar HTML. (Por supuesto, esto depende necesariamente de tener una situación en la que los datos sean 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 en particular, mientras administra su presentación. La lógica es necesaria a pesar de todo. Sin embargo, diré que si lo implementas por adelantado, estarás mejor preparado para el crecimiento futuro.

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

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

Por otra parte, si quieres transmitir HMTL que se va a representar como HTML, entonces envíalo como HTML - en lugar de empaquetar el HTML en una cadena, convierte la cadena en JSON , transmitir JSON, descodificarlo en el otro lado, obtener una cadena y extraer el HTML de la cadena.

Y ayer mismo encontré un código que ponía dos elementos en una matriz, convertía la matriz en JSON, ponía el JSON en una cadena, ponía la cadena dentro de una matriz, convertía la matriz completa en JSON, la enviaba al cliente , que descodificó el JSON, obtuvo una matriz que contenía una cadena, tomó la cadena, extrajo el JSON de la cadena, descodificó el JSON y obtuvo una matriz con dos elementos. No hagas eso

Yo diría que no hay nada de malo en que el servidor devuelva un fragmento HTML y la IU 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 asíncrono. El beneficio es que se hace lo menos posible utilizando JavaScript y tanto como sea posible en un entorno de back-end controlado. Recuerde que el soporte de 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 versión.

Ahora, a veces desea algo más que 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, y 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, de ninguna manera, enfoques exclusivos alternativos; se pueden utilizar juntos.

Al utilizar JSON, incluso puede tener varios fragmentos de 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. Evitar XML.

Todo 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á uniendo sus datos y su 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, la única razón por la que la API es buena es proporcionar HTML a su página. 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 todavía puede consumir esos datos y presentarlos de manera adecuada. Ahora, sin embargo, otras cosas pueden usar la API para acceder a los mismos datos. Una vez más, 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ífico.

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

Con JSON, si el diseño de la página cambia, la llamada del servidor JSON existente no necesariamente tiene que cambiar en absoluto. En su lugar, su desarrollador de aplicaciones para usuario, o incluso el diseñador, actualiza la plantilla para producir el HTML diferente 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 para clientes 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 que no está disponible para los clientes en general. Con JSON, la misma llamada de servidor se puede utilizar en ambas vistas.

Finalmente, JSON puede escalar mejor. En los últimos años, hemos ido exagerando con los marcos de javascript del lado del cliente. Creo que es hora de dar un paso atrás y comenzar a pensar en 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 lo aprovechan, pueden reducir la carga del servidor en una gran implementación. JSON también usa menos ancho de banda, así que de nuevo, si eres lo suficientemente grande y lo usas adecuadamente, JSON es considerablemente más barato. Por supuesto, también puede escalar peor, si terminas alimentando bibliotecas de 40KB para analizar 2KB de datos en 7KB de html, nuevamente: vale la pena estar al tanto de lo que estás haciendo. Pero el potencial está allí para que JSON mejore el rendimiento y los costos.

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

El problema es que, en el caso general, usted desea que sus puntos finales generen una carga útil que esté bien formada y que un analizador estándar pueda analizar efectivamente. Y, efectivamente, con capacidad de análisis, quiero decir, con capacidad de declaración declarativa.

Si su cliente se ve forzado a leer la carga útil y separar los bits de información abiertos con bucles y declaraciones if, entonces no se puede analizar de manera efectiva. Y el HTML, siendo así, está muy perdonado al no exigirse estar bien formado.

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

Dicho esto, tengo un problema importante con esto:

  

Le diré esto: un punto final que devuelve HTML reduce su   Depende de las bibliotecas de JavaScript y reduce la carga del usuario.   navegador ya que no necesitará interpretar / ejecutar código JS para crear DOM   objetos - el HTML ya está allí, es solo una cuestión de analizar el   Elementos y representaciones. Por supuesto, esto significa que estamos hablando de   una cantidad razonable de datos. 10 megabytes de datos HTML no es   razonable.

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

Aquí está combinando los dos con el fin de acelerar la ejecución del 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. Naturalmente, un cliente 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 el analizador HTML. Se necesita poca huella. No es así con un analizador de HTML.

En PHP, solo usas json_encode($data) y depende del cliente en el 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 utilizan JSON (formato más común) para intercambiar datos.

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

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

JSON no tiene nada que ver con HTTP. Puedes poner JSON en un archivo. Puedes usarlo para configuraciones. El compositor usa JSON. Puedes usarlo para guardar variables simples en archivos también.

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

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

Diferencio 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 los códigos HTTP y las 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 que está arriba.