Qu'est-ce qui ne va vraiment pas avec un noeud final renvoyant du HTML plutôt que des données JSON?

Quand j'ai commencé à apprendre PHP (il y a 5 ou 6 ans), j'ai découvert Ajax et j'ai traversé "les phases":

1. Votre serveur renvoie les données HTML et vous les insérez dans un code innerHTML du DOM.
2. Vous en apprendrez plus sur les formats de transfert de données tels que XML (et dites «oooh, c’est pour cela qu’il est utilisé), puis JSON.
3. Vous renvoyez JSON et construisez votre interface utilisateur à l'aide de code JavaScript vanilla
4. Vous passez à jQuery
5. Vous en apprendrez plus sur les API, les en-têtes, les codes d’état HTTP, REST , CORS et Bootstrap
6. Vous apprendrez les structures SPA et frontend ( React , Vue.js et AngularJS ) et le standard JSON API.
7. Vous recevez un code d'entreprise hérité et constatez, lors de l'inspection, qu'il fait ce qui est décrit à l'étape 1.

Comme je travaillais avec cet ancien code, je ne pensais même pas qu'il pouvait renvoyer du HTML (je veux dire, nous sommes des professionnels maintenant, n'est-ce pas?), J'ai donc eu de la difficulté à rechercher le point de terminaison JSON qui renvoyait les données les appels Ajax peuplent. Ce n'est que lorsque j'ai demandé au "programmeur" qu'il m'a dit qu'il retournait du HTML et qu'il était ajouté directement au DOM avec innerHTML.

Bien sûr, c'était difficile à accepter. J'ai commencé à réfléchir à des moyens de reformuler cela dans les points de terminaison JSON, en pensant à l'unité qui testait les points de terminaison, etc. Cependant, cette base de code n'a aucun test. Pas un seul. Et c'est plus de 200 000 lignes. Bien sûr, l’une de mes tâches consiste à proposer des approches pour tester l’ensemble, mais pour le moment, nous ne sommes pas encore en train de nous y attaquer.

Je ne me demande donc pas, dans un coin, si nous n’avons aucun test, nous n’avons donc aucune raison particulière de créer ce point de terminaison JSON (car il n’est pas "réutilisable": il renvoie littéralement des données qui ne tiennent que sur cette partie de la application, mais je pense que cela était déjà implicite puisqu'il renvoie ... des données HTML).

Qu'est- ce qui ne va pas avec ça?

Qu'est-ce qui ne va vraiment pas avec un noeud final renvoyant du HTML plutôt que des données JSON?

Rien, vraiment. Chaque application a des exigences différentes et il se peut que votre application n'ait pas été conçue pour être un SPA.

Il se peut que ces superbes frameworks que vous avez cités (Angular, Vue, React, etc.) ne soient pas disponibles au moment du développement, ou n’étaient pas "approuvés" par votre entreprise.

Je vais vous dire ceci: un noeud final renvoyant du HTML réduit votre dépendance aux bibliothèques JavaScript et la charge du navigateur de l'utilisateur, car il n'a pas besoin d'interpréter / d'exécuter du code JS pour créer des objets DOM - le code HTML est déjà présent. il suffit d'analyser les éléments et de les rendre. Bien sûr, cela signifie que nous parlons d’une quantité raisonnable de données. 10 Mo de données HTML n'est pas raisonnable.

Toutefois, comme il n’ya rien de mal à renvoyer du code HTML, le fait de ne pas utiliser JSON / XML vous fait perdre la possibilité d’utiliser votre point de terminaison en tant qu’API. Et voici la plus grande question: faut-il vraiment une API?

Connexe: Est-il possible de renvoyer du HTML à partir d'une API JSON?

JSON et HTML remplissent deux objectifs sémantiques différents.

Si vous remplissez une page Web avec des données, utilisez JSON. Si vous construisez une page Web à partir de parties de pages Web, utilisez HTML.

Ils peuvent sembler être la même chose, mais ils ne le sont pas du tout. D'une part, lorsque vous créez une partie d'une page Web à l'aide du code HTML renvoyé par le serveur, vous travaillez côté serveur. Lorsque vous liez des données à une page Web, vous travaillez côté client.

En outre, vous devez faire attention avec HTML pour ne pas lier étroitement à une page spécifique. L'intérêt de rendre les pages partielles de cette manière est que les partiels soient réutilisables. Si vous rendez le partiel trop spécifique, il ne se composera pas d'autres pages. JSON n'a pas ce problème, car il ne s'agit que de données, pas de structure de page Web.

Le problème principal est qu’il couple étroitement le serveur au client, qui doit connaître la structure HTML. Cela rend également les points finaux plus difficiles à réutiliser de nouvelles manières ou de nouvelles applications.

Renvoyer des données en clair et laisser le client restituer le couplage réduit le couplage et augmente la flexibilité et la testabilité. Vous pouvez exécuter des tests unitaires sur le client pour des données fictives et des tests unitaires sur le serveur pour tester les données souhaitées.

Je pense que vous l'avez un peu en arrière. Vous dites:

nous n'avons aucun test, nous n'avons donc aucune raison particulière de créer ce noeud final JSON

Une raison d'utiliser un point de terminaison approprié serait pour que vous puissiez le tester. Je dirais que ne pas avoir de test est une très bonne raison pour commencer à en écrire. Autrement dit, s’il existe une logique à tester.

200 000 lignes de code représentent beaucoup de choses à refactoriser et sont probablement difficiles à maintenir. Décrire certains points de terminaison et les tester peut être un bon point de départ.

Une autre raison pourrait être de séparer le serveur du client. Si, dans un avenir lointain, la conception ou la présentation de l'application change, il est plus facile de travailler avec un format de données approprié que la sortie HTML. Dans un monde idéal, il vous suffirait de changer de client et de ne pas toucher le serveur du tout.

Il existe 3 façons (au moins?) De créer une page Web:

• Générez tout le côté serveur de pages.
• Renvoie une page nue du serveur plus du code (JavaScript), et demande à la page d'extraire ses données et de la restituer dans le côté client HTML.
• Renvoie une page partielle plus du code et demande au code d'extraire des blocs HTML préalablement rendus qu'il peut insérer dans la page.

Le premier va bien. Le deuxième est aussi bien. C'est le dernier problème qui pose problème.

La raison est simple: vous avez maintenant divisé la construction de la page HTML en parties totalement déconnectées. Le problème est celui de la maintenance. Vous avez maintenant deux entités distinctes chargées de gérer les détails de l'interface utilisateur. Il faut donc que le CSS et les autres détails similaires soient synchronisés entre les deux éléments distincts. Vous avez changé la largeur de la barre latérale? Génial. Maintenant, le fragment HTML qui revient provoque le défilement horizontal car ses hypothèses sur la largeur de la barre latérale ne tiennent plus. Vous avez changé la couleur de fond pour ce bloc? Parfait, la couleur de police de votre fragment HTML entre maintenant en conflit, car elle supposait une couleur d'arrière-plan différente et quelqu'un avait oublié de tester ce noeud final.

Le fait est que vous avez maintenant divisé les connaissances qui devraient être centralisées en un seul endroit (à savoir la logique de présentation), ce qui rend plus difficile de s'assurer que toutes les pièces s'emboîtent correctement. En utilisant une API JSON, vous pouvez conserver toute cette logique uniquement dans l'interface frontale ou dans vos modèles côté serveur si vous convertissez vos données au format HTML pour commencer. Il s'agit de conserver la connaissance / la logique de présentation dans un endroit unique, de sorte qu'elle puisse être gérée de manière cohérente et dans le cadre d'un processus unique. HTML / CSS / JS est assez difficile à maintenir sans diviser en minuscules morceaux.

Les API JSON présentent également l’avantage supplémentaire de rendre les données disponibles de manière totalement indépendante de la logique de présentation. Cela permet à plusieurs présentateurs différents , tels qu'une application mobile et une page Web, de consommer les mêmes données. Cela permet notamment de consommer les données sans navigateur (telles que les applications mobiles ou les tâches cron nocturnes); ces consommateurs peuvent même ne pas être capables d'analyser le HTML. (Bien entendu, cela suppose nécessairement que les données soient identiques entre les différents consommateurs, ou que l'on peut utiliser un sous-ensemble de l'autre.) Que vous ayez besoin de cette possibilité dépend des exigences de votre application, cependant, tout en gérant votre présentation. la logique est nécessaire malgré tout. Je dirai que si vous le mettez en œuvre dès le départ, vous serez mieux préparé à la croissance future.

Je dirais qu'il n'y a rien de mal à ce que le serveur renvoie un fragment HTML et que l'interface utilisateur l'affecte à .innerHTML d'un élément. À mon avis, c'est le moyen le plus simple de développer du code JavaScript asynchrone. L'avantage est que JavaScript est utilisé le moins possible et le plus possible dans un environnement back-end contrôlé. N'oubliez pas que la prise en charge de JavaScript dans les navigateurs varie, mais que votre back-end a toujours la même version des composants du back-end, ce qui signifie que faire autant que possible dans le back-end signifiera le moins d'incompatibilités possibles.

Maintenant, parfois, vous voulez plus qu'un simple fragment HTML. Par exemple, un code d'état et un fragment HTML. Vous pouvez ensuite utiliser un objet JSON ayant deux membres, statusCode et HTML, le deuxième pouvant être affecté à .innerHTML de certains éléments après avoir vérifié le statusCode. Ainsi, l'utilisation de JSON et de innerHTML ne sont en aucun cas des approches exclusives alternatives; ils peuvent être utilisés ensemble.

En utilisant JSON, vous pouvez même avoir plusieurs fragments HTML dans la même réponse, qui sont affectés au .innerHTML de plusieurs éléments.

En résumé: utilisez .innerHTML. Cela rend votre code compatible avec autant de versions de navigateur que possible. Si vous avez besoin de plus, utilisez JSON et .innerHTML ensemble. Évitez XML.

Il n'y a rien de mal en principe . La question est: Que voulez-vous réaliser?

JSON est parfait pour la transmission de données. Si vous envoyez plutôt du code HTML et que vous attendez du client qu'il extrait les données du code HTML, c'est nul.

D'autre part, si vous souhaitez transmettre un fichier HMTL qui sera rendu au format HTML, envoyez-le au format HTML - au lieu de compresser le code HTML en chaîne, convertissez la chaîne en JSON, transmettez le code JSON et décodez-le de l'autre côté. , obtenir une chaîne et extraire le code HTML de la chaîne.

Et hier encore, j’ai rencontré un code mettant deux éléments dans un tableau, convertissant le tableau en JSON, plaçant le JSON dans une chaîne, plaçant la chaîne dans un tableau, convertissant l’ensemble du tableau en JSON, l’envoyant au client, qui le décodait. le JSON, a obtenu un tableau contenant une chaîne, a pris la chaîne, a extrait le JSON de la chaîne, a décodé le JSON et a obtenu un tableau avec deux éléments. Ne fais pas ça.

Tout dépend de l'objectif de l'API, mais en général, ce que vous décrivez est une violation assez grave de la séparation des préoccupations :

Dans une application moderne, le code API devrait être responsable des données et le code client, de la présentation.

Lorsque votre API renvoie le code HTML, vous combinez étroitement vos données et votre présentation. Lorsque l'API renvoie du code HTML, la seule chose que vous pouvez faire (facilement) avec ce code HTML est de l'afficher dans une partie d'une page plus grande. Sous un angle différent, la seule chose pour laquelle l’API est bonne est de fournir du code HTML à votre page. De plus, vous avez réparti votre code HTML sur le code client et le code serveur. Cela peut rendre la maintenance un mal de tête.

Si votre API renvoie JSON ou une autre forme de données pures, cela devient beaucoup plus utile. L'application existante peut toujours utiliser ces données et les présenter de manière appropriée. Maintenant, cependant, l'API peut utiliser d'autres éléments pour accéder aux mêmes données. Là encore, la maintenance est plus simple: tout le code HTML réside en un seul endroit. Si vous souhaitez modifier le style de l'ensemble du site, vous n'avez pas besoin de modifier votre API.

HTML est lié à une conception et à une utilisation spécifiques.

Avec HTML, si vous souhaitez modifier la mise en page, vous devez modifier la façon dont le code HTML est généré par l'appel du serveur. Habituellement, cela nécessite un programmeur back-end. Maintenant, vous avez des programmeurs back-end, qui par définition ne sont pas vos meilleurs rédacteurs HTML, qui gèrent ces mises à jour.

Avec JSON, si la présentation de la page change, l'appel du serveur JSON existant ne doit pas nécessairement changer du tout. Au lieu de cela, votre développeur front-end, ou même le concepteur, met à jour le modèle pour générer le code HTML différent à partir des mêmes données de base.

De plus, le JSON peut devenir la base d'autres services. Vous pouvez avoir différents rôles nécessitant d'afficher les mêmes données de base de différentes manières. Par exemple, vous pouvez avoir un site Web client contenant des données sur un produit dans une page de commande et une page de vente interne pour les représentants affichant les mêmes données dans une présentation très différente, peut-être à côté d’autres informations non disponibles pour les clients généraux. Avec JSON, le même appel de serveur peut être utilisé dans les deux vues.

Enfin, JSON peut mieux évoluer. Ces dernières années, nous avons en quelque sorte dépassé les limites avec les frameworks javascript côté client. Je pense qu'il est temps de prendre du recul et de commencer à réfléchir à ce que nous utilisons javascript et à son incidence sur les performances du navigateur ... en particulier sur les appareils mobiles. Cela dit, si vous exécutez un site suffisamment grand pour nécessiter une batterie de serveurs ou un cluster, au lieu d'un seul serveur, JSON peut évoluer plus efficacement. Les utilisateurs vous donneront gratuitement le temps de traitement dans leur navigateur. Si vous en profitez, vous pouvez réduire la charge du serveur lors d'un déploiement de grande envergure. JSON utilise également moins de bande passante, donc encore une fois, si vous êtes assez grandet utilisez-le à bon escient, JSON est nettement moins cher. Bien sûr, cela peut aussi empirer si vous finissez par alimenter des bibliothèques de 40 Ko pour analyser 2 Ko de données dans 7 Ko de code HTML, donc encore une fois: il est bon de savoir ce que vous faites. Mais JSON a le potentiel d’améliorer ses performances et ses coûts.

Un tel point final n'a rien d'anormal s'il répond à ses exigences. S'il est nécessaire de cracher du code HTML qu'un consommateur connu peut analyser efficacement, bien sûr, pourquoi pas?

Le problème est que, dans le cas général, vous voulez que vos points de terminaison crachent une charge utile bien formée et analysable efficacement par un analyseur syntaxique standard. Et par effectivement analysable, je veux dire, analysable de manière déclarative.

Si votre client est obligé de lire la charge utile et d'en extraire des éléments d'information ouverts avec des boucles et des instructions if, alors l'analyse n'est pas analysable. Et HTML, étant la manière dont il est, il est très pardonné de ne pas se faire bien former.

Maintenant, si vous vous assurez que votre code HTML est compatible XML, alors vous êtes en or.

Cela dit, j'ai un problème important avec ceci:

Je vais vous dire ceci: un noeud final renvoyant du HTML réduit votre dépendance aux bibliothèques JavaScript et la charge sur le navigateur de l'utilisateur, car il n'a pas besoin d'interpréter / d'exécuter du code JS pour créer des objets DOM - le code HTML est déjà présent. il suffit d'analyser les éléments et de les rendre. Bien sûr, cela signifie que nous parlons d’une quantité raisonnable de données. 10 Mo de données HTML n'est pas raisonnable.

C'est une mauvaise idée, peu importe comment vous le coupez. Des décennies d'expérience industrielle collective nous ont montré qu'en général, il est judicieux de séparer les données (ou le modèle) de leur affichage (ou de leur vue).

Ici, vous fusionnez les deux pour une exécution rapide du code JS. Et c'est une micro optimisation.

Je n'ai jamais vu cela comme une bonne idée, sauf dans des systèmes très triviaux.

Mon conseil? Ne le fais pas. DR SVON HC SVNT , YMMV, etc.

JSON est juste une présentation textuelle de données structurées. Un client a naturellement besoin d'un analyseur pour traiter les données, mais pratiquement toutes les langues disposent de fonctions d'analyse JSON. Il est beaucoup plus efficace d'utiliser un analyseur JSON que d'utiliser un analyseur HTML. Cela prend peu d'empreinte. Ce n'est pas le cas avec un analyseur HTML.

En PHP, vous utilisez simplement json_encode($data)et c'est au client de l'autre côté de l'analyser. Et lorsque vous récupérez des données JSON à partir d'un service Web, vous utilisez simplement $data=json_decode($response)et vous pouvez décider comment utiliser les données comme vous le feriez avec des variables.

Supposons que vous développiez une application pour un appareil mobile. Pourquoi avez-vous besoin du format HTML alors que les applications mobiles utilisent rarement le navigateur Web pour analyser des données? De nombreuses applications mobiles utilisent JSON (format le plus courant) pour échanger des données.

Étant donné que les mobiles utilisent souvent des forfaits avec compteur, pourquoi voulez-vous utiliser du HTML qui nécessite beaucoup plus de bande passante que JSON?

Pourquoi utiliser HMTL lorsque le vocabulaire HTML est limité et que JSON peut définir des données? {"person_name":"Jeff Doe"}est plus informatif que ce que HTML peut fournir sur ses données car il définit uniquement la structure des analyseurs HTML, pas les données.

JSON n'a rien à voir avec HTTP. Vous pouvez mettre JSON dans un fichier. Vous pouvez l'utiliser pour des configurations. Le compositeur utilise JSON. Vous pouvez également l'utiliser pour enregistrer des variables simples dans des fichiers.

Il est difficile de classer un bien ou un mal. OMI, les questions que je poserai sont: " devrait-il ", ou " peut-il faire avec moins? ".

Chaque terminal doit s'efforcer de communiquer avec le moins de contenu possible. Le rapport signal sur bruit est généralement constitué de codes HTTP <JSON <XHTML. Dans la plupart des situations, il est bon de choisir le protocole le moins bruyant.

Je suis différent sur le point concernant la charge du navigateur client par @machado, car avec les navigateurs modernes, cela n’est pas un problème. La plupart d'entre eux sont assez bien équipés pour gérer les codes HTTP et les réponses JSON. Et bien que vous ne disposiez pas de tests pour le moment, la maintenance à long terme d'un protocole moins bruyant serait moins coûteuse que celle qui le précède.