Pourquoi est-il une mauvaise pratique de renvoyer du code HTML généré au lieu de JSON? Ou est-ce?

Il est assez facile de charger du contenu HTML à partir de vos URL / services Web personnalisés à l'aide de JQuery ou de tout autre cadre similaire. J'ai utilisé cette approche plusieurs fois et jusqu'à présent et j'ai trouvé les performances satisfaisantes.

Mais tous les livres, tous les experts essaient de me faire utiliser JSON au lieu de HTML généré. Comment est-il beaucoup plus supérieur que HTML?

Est-ce beaucoup plus rapide?
La charge sur le serveur est-elle bien moindre?

De l'autre côté, j'ai quelques raisons d'utiliser le HTML généré.

1. C'est un balisage simple et souvent tout aussi compact ou même plus compact que JSON.
2. C'est moins sujet aux erreurs car tout ce que vous obtenez est du balisage et pas de code.
3. La programmation sera plus rapide dans la plupart des cas, car vous n'aurez pas à écrire de code séparément pour le client.

De quel côté êtes-vous et pourquoi?

Je suis un peu des deux côtés, en fait:

• Lorsque ce dont j'ai besoin du côté javascript, ce sont des données , j'utilise JSON
• Lorsque ce dont j'ai besoin du côté javascript est une présentation sur laquelle je ne ferai aucun calcul, j'utilise généralement du HTML

Le principal avantage de l'utilisation de HTML est lorsque vous souhaitez remplacer une partie complète de votre page par ce qui revient de la demande Ajax:

• Reconstruire une partie de la page dans JS est (assez) difficile
• Vous avez probablement déjà un moteur de template côté serveur, qui a été utilisé pour générer la page en premier lieu ... Pourquoi ne pas la réutiliser?

En général, je ne prends pas vraiment en compte le côté "performance" des choses, du moins sur le serveur:

• Sur le serveur, la génération d'une partie de HTML ou de JSON ne fera probablement pas beaucoup de différence
• À propos de la taille des éléments qui transitent par le réseau: eh bien, vous n'utilisez probablement pas des centaines de Ko de données / html ... L'utilisation de gzip sur tout ce que vous transférez est ce qui va faire la plus grande différence (ne pas choisir entre HTML et JSON)
• Une chose qui pourrait être prise en considération, cependant, est de quelles ressources vous aurez besoin sur le client pour recréer le HTML (ou la structure DOM) à partir des données JSON ... comparez cela à pousser une partie de HTML dans la page; -)

Enfin, une chose qui compte vraiment:

• Combien de temps cela vous prendra-t-il pour développer un nouveau système qui enverra des données sous forme de code JSON + le JS requis pour l'injecter en HTML dans la page?
• Combien de temps faut-il pour renvoyer simplement du HTML? Et combien de temps si vous pouvez réutiliser une partie de votre code côté serveur déjà existant?

Et pour répondre à une autre réponse: si vous devez mettre à jour plus d'une partie de la page, il y a toujours la solution / hack d'envoyer toutes ces parties dans une grande chaîne qui regroupe plusieurs parties HTML et d'extraire les parties pertinentes dans JS.

Par exemple, vous pouvez renvoyer une chaîne qui ressemble à ceci:

<!-- MARKER_BEGIN_PART1 -->
here goes the html
code for part 1
<!-- MARKER_END_PART1 -->
<!-- MARKER_BEGIN_PART2 -->
here goes the html
code for part 2
<!-- MARKER_END_PART2 -->
<!-- MARKER_BEGIN_PART3 -->
here goes the json data
that will be used to build part 3
from the JS code
<!-- MARKER_END_PART3 -->

Cela n'a pas l'air vraiment bien, mais c'est vraiment utile (je l'ai utilisé plusieurs fois, surtout lorsque les données HTML étaient trop grandes pour être encapsulées dans JSON) : vous envoyez du HTML pour les parties de la page qui besoin de présentation, et vous envoyez JSON pour la situation dont vous avez besoin de données ...

... Et pour les extraire, la méthode de sous-chaîne JS fera l'affaire, je suppose ;-)

Je suis principalement d'accord avec les opinions exprimées ici. Je voulais juste les résumer comme suit:

• Il est déconseillé d'envoyer du HTML si vous finissez par l'analyser côté client pour effectuer des calculs par-dessus.

• C'est une mauvaise pratique d'envoyer du JSON si tout ce que vous finirez par faire est de l'incorporer dans l'arborescence DOM de la page.

Bien,

Je fais partie de ces rares personnes qui aiment séparer les choses de cette façon: - Le serveur est responsable de la livraison des données (modèle); - Le client est responsable de l'affichage (vue) et de la manipulation des données (modèle);

Ainsi, le serveur doit se concentrer sur la livraison du modèle (dans ce cas, JSON est meilleur). De cette façon, vous obtenez une approche flexible. Si vous voulez changer la vue de votre modèle, vous gardez le serveur envoyant les mêmes données et changez simplement le client, les composants javascript, qui changent ces données en vue. Imaginez, vous disposez d'un serveur fournissant des données aux appareils mobiles ainsi qu'aux applications de bureau.

De plus, cette approche augmente la productivité, car le code du serveur et du client peuvent être construits en même temps, sans jamais perdre le focus, ce qui se passe lorsque vous passez de js à PHP / JAVA / etc.

En général, je pense que la plupart des gens préfèrent en faire autant que possible côté serveur car ils ne maîtrisent pas js, ils essaient donc de l'éviter autant que possible.

Fondamentalement, j'ai la même opinion que les gars qui travaillent sur Angular. À mon avis, c'est l'avenir des applications Web.

J'ai quelque chose d'intéressant que je pensais pouvoir ajouter. J'ai développé une application qui n'a chargé qu'une seule fois une vue complète. À partir de ce moment-là, il n'a communiqué avec le serveur qu'avec ajax. Il n'a jamais eu besoin de charger qu'une seule page (ma raison en est sans importance ici). La partie intéressante vient du fait que j'avais un besoin particulier de retourner certaines données à exploiter dans le javascript ET une vue partielle à afficher. J'aurais pu diviser cela en deux appels à deux méthodes d'action distinctes mais j'ai décidé d'aller avec quelque chose d'un peu plus amusant.

Vérifiez-le:

public JsonResult MyJsonObject(string someData)
{
     return Json(new { SomeData = someData, PartialView = RenderPartialViewToString("JsonPartialView", null) }, JsonRequestBehavior.AllowGet);
}

Qu'est-ce que RenderPartialViewToString () vous pourriez demander? C'est cette petite pépite de fraîcheur ici:

protected string RenderPartialViewToString(string viewName, object model)
{
     ViewData.Model = model;

     using (StringWriter sw = new StringWriter())
     {
          ViewEngineResult viewResult = ViewEngines.Engines.FindPartialView(ControllerContext, viewName);
          ViewContext viewContext = new ViewContext(ControllerContext, viewResult.View, ViewData, TempData, sw);
          viewResult.View.Render(viewContext, sw);

          return sw.GetStringBuilder().ToString();
     }
}

Je n'ai fait aucun test de performance sur ce sujet, donc je ne sais pas si cela entraîne plus ou moins de surcharge que d'appeler une méthode d'action pour JsonResult et une pour ParticalViewResult, mais je pensais toujours que c'était assez cool. Il sérialise simplement une vue partielle dans une chaîne et l'envoie avec le Json comme l'un de ses paramètres. J'utilise ensuite JQuery pour prendre ce paramètre et le gifler dans son nœud DOM approprié :)

Dites-moi ce que vous pensez de mon hybride!

Si la réponse ne nécessite aucun autre traitement côté client, le HTML est OK à mon avis. L'envoi de JSON ne vous obligera qu'à effectuer ce traitement côté client.

D'un autre côté, j'utilise JSON lorsque je ne veux pas utiliser toutes les données de réponse à la fois. Par exemple, j'ai une série de trois sélections chaînées, où la valeur sélectionnée de l'un détermine quelles valeurs vont être utilisées pour remplir la seconde, et ainsi de suite.

IMV, il s'agit de séparer les données de la présentation des données, mais je suis avec Pascal, il ne s'ensuit pas nécessairement que cette séparation ne peut se faire qu'à travers la frontière client / serveur. Si vous avez déjà cette séparation (sur le serveur) et que vous souhaitez simplement montrer quelque chose au client, que vous renvoyiez JSON et le post-traitiez sur le client, ou renvoyiez simplement du HTML, cela dépend entièrement de vos besoins. Dire que vous avez «tort» de renvoyer du code HTML dans le cas général est tout simplement trop clair pour une déclaration IMV.

JSON est un format très polyvalent et léger. J'ai découvert sa beauté lorsque j'ai commencé à l'utiliser comme données d'analyseur de modèle côté client. Laissez-moi vous expliquer, alors qu'avant j'utilisais smarty et les vues côté serveur (générant une charge de serveur élevée), maintenant j'utilise certaines fonctions jquery personnalisées et toutes les données sont rendues côté client, en utilisant le navigateur clients comme analyseur de modèle. il enregistre les ressources du serveur et, d'autre part, les navigateurs améliorent quotidiennement leurs moteurs JS. Par conséquent, la vitesse d'analyse du client n'est pas un problème important pour le moment, d'autant plus que les objets JSON sont généralement très petits, de sorte qu'ils ne consomment pas beaucoup de ressources côté client. Je préfère avoir un site Web lent pour certains utilisateurs avec un navigateur lent plutôt qu'un site lent pour tout le monde en raison du serveur très chargé.

D'un autre côté, envoyer des données pures à partir du serveur vous les soustrayez de la présentation, donc si demain vous voulez les changer ou intégrer vos données dans un autre service, vous pouvez le faire beaucoup plus facilement.

Juste mes 2 cents.

Si vous voulez un client découplé propre, ce qui à mon avis est la meilleure pratique, alors il est logique d'avoir 100% du DOM créé par javascript. Si vous créez un client basé sur MVC qui possède tout le savoir-faire pour créer l'interface utilisateur, vos utilisateurs téléchargent un fichier javascript une fois et il est mis en cache sur le client. Toutes les demandes après ce chargement initial sont basées sur Ajax et ne renvoient que des données. Cette approche est la plus propre que j'ai trouvée et permet une encapsulation propre et indépendante de la présentation.

Le côté serveur se concentre alors uniquement sur la livraison des données.

Donc, demain, lorsque le produit vous demandera de modifier complètement la conception d'une page, tout ce que vous changez est le JS source qui crée le DOM, mais vous risquez de réutiliser vos gestionnaires d'événements déjà existants et le serveur est inconscient car il est découplé à 100% de la présentation

Selon votre interface utilisateur, vous devrez peut-être mettre à jour deux (ou plus) éléments différents dans votre DOM. Si votre réponse est en HTML, allez-vous analyser cela pour savoir ce qui va où? Ou vous pouvez simplement utiliser un hachage JSON.

Vous pouvez même le combiner, renvoyer un JSON avec des données html :)

{ 'dom_ele_1' : '<p>My HTML part 1</p>', 'dome_ele_2' : '<div>Your payment has been received</div>' }

Le HTML contient de nombreuses données redondantes et non affichées, c.-à-d. Des balises, des feuilles de style, etc. Ainsi, la taille du HTML par rapport aux données JSON sera plus grande, ce qui augmentera le temps de téléchargement et de rendu et le navigateur sera également occupé à rendre les nouvelles données.

L'envoi de json se fait généralement lorsque vous avez un widget javascript demandant des informations au serveur, comme une liste ou une arborescence ou une saisie semi-automatique. C'est à ce moment que j'enverrais JSON car ce sont des données qui seront analysées et utilisées brutes. Cependant, si vous allez simplement afficher du HTML, il vous faudra beaucoup moins de travail pour le générer côté serveur et l'afficher simplement sur le navigateur. Les navigateurs sont optimisés pour insérer du HTML directement dans le dom avec innerHTML = "", vous ne pouvez donc pas vous tromper avec cela.

Je pense que cela dépend de la structure de la conception, c'est juste plus sexy d'utiliser JSON que HTML mais la question est de savoir comment le gérer pour qu'il soit facile à entretenir.

Par exemple, disons que j'ai la page de liste qui utilise le même html / style de l'ensemble du site, j'écrirais la fonction globale pour formater ces parties de HTML et tout ce que j'ai à faire est de passer l'objet JSON dans la fonction.

La réponse HTML est suffisante dans la plupart des cas, sauf si vous devez effectuer des calculs côté client.

Dépend des circonstances.

Parfois, il est essentiel d'éviter JSON. Lorsque nos programmeurs ont du mal à programmer en js, par exemple.

Mon expérience me dit que: mieux utiliser le service ajax que JSON en ligne.

Tôt ou tard, le js devient un problème