Pourquoi est-ce une mauvaise pratique de renvoyer du 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 framework similaire. J'ai utilisé cette approche plusieurs fois et jusqu'à maintenant et j'ai trouvé la performance satisfaisante.
Mais tous les livres, tous les experts essaient de me faire utiliser JSON au lieu du HTML généré. Comment est-ce beaucoup plus supérieur que le HTML?
Est-ce beaucoup plus rapide?
Le serveur at-il une charge beaucoup plus faible?
De l'autre côté, j'ai des raisons d'utiliser le code HTML généré.
- C'est un balisage simple, et souvent aussi compact ou en réalité plus compact que JSON.
- Il est moins sujet aux erreurs car tout ce que vous obtenez est du balisage et aucun code.
- Il sera plus rapide de programmer dans la plupart des cas car vous n’auriez pas besoin d’écrire du code séparément pour le client.
De quel côté es-tu et pourquoi?
Je suis un peu des deux côtés, en fait:
- Quand j'ai besoin de javascript du côté de data , j'utilise JSON
- Quand ce dont j'ai besoin du côté javascript est presentation sur lequel je ne ferai aucun calcul, j'utilise généralement HTML
Le principal avantage de l’utilisation de HTML réside dans le fait que vous souhaitez remplacer une partie complète de votre page par ce qui provient de la requête Ajax:
- Reconstruire une partie de la page dans JS est (assez) difficile
- Vous avez probablement déjà un moteur de gabarit 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", du moins sur le serveur:
- Sur le serveur, générer une partie du code HTML ou du code JSON ne fera probablement pas une grande différence
- En ce qui concerne la taille des éléments qui transitent par le réseau: vous n’utilisez probablement pas des centaines de ko de données/html ... Utiliser gzip pour tout ce que vous transférez est ce qui fera la plus grande différence (ne pas choisir entre HTML et JSON)
- Une chose qui pourrait être prise en compte, cependant, concerne les ressources dont vous aurez besoin sur le client pour recréer le code HTML (ou la structure DOM) à partir des données JSON ... comparez cela à une partie du code HTML. dans la page ;-)
Enfin, une chose qui compte vraiment:
- Combien de temps faudra-t-il pour développer un nouveau système qui enverra les données sous forme de code JSON + au JS requis pour les injecter au format HTML dans la page?
- Combien de temps faudra-t-il pour renvoyer du code 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 avez besoin de mettre à jour plus d’une partie de la page, il reste 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 retourner 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 bien, mais c'est vraiment utile (je l'ai utilisé plusieurs fois, surtout quand les données HTML étaient trop volumineuses pour être encapsulées dans JSON): vous envoyez du HTML pour les portions de la page qui a besoin de présentation, et vous envoyez JSON pour la situation où vous avez besoin de données ...
... Et pour extraire ceux-ci, 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 y effectuer des calculs.
Il est déconseillé d’envoyer du JSON si tout ce que vous faites est de l’intégrer à l’arborescence DOM de la page.
Bien,
Je suis l’une des rares personnes à aimer 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 la présentation (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 préférable) . Vous obtenez ainsi une approche flexible. Si vous souhaitez modifier l'affichage de votre modèle, vous conservez l'envoi des mêmes données par le serveur et il vous suffit de modifier les composants client, javascript, qui modifient ces données dans une vue. Imaginez, vous avez un serveur fournissant des données aux appareils mobiles ainsi qu'aux applications de bureau.
En outre, cette approche augmente la productivité, car les codes serveur et client peuvent être construits en même temps, sans jamais perdre le focus, ce qui se produit lorsque vous passez de js à PHP/Java/etc.
De manière générale, je pense que la plupart des gens préfèrent faire le plus possible côté serveur car ils ne maîtrisent pas js, ils essaient donc de l'éviter autant que possible.
En gros, j'ai le même avis 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 jamais chargé qu'une seule fois la vue complète. À partir de ce moment, il renvoie au serveur avec ajax uniquement. Il n’a jamais fallu charger qu’une seule page (ma raison n’est pas importante ici). Ce qui est intéressant, c’est que j’avais un besoin particulier de renvoyer certaines données à exploiter dans le javascript ET une vue partielle à afficher. J'aurais pu scinder cela en deux appels à deux méthodes d'action distinctes, mais j'ai décidé de choisir 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 () pourriez-vous 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();
}
}
Comme je n’ai fait aucun test de performance à ce sujet, je ne suis pas sûr que cela implique plus de frais généraux que d’appeler une méthode d’action pour le JsonResult et une autre pour le ParticalViewResult, mais j’ai quand même trouvé cela plutôt cool. Il sérialise juste une vue partielle dans une chaîne et l'envoie avec le Json en tant que paramètre. J'utilise ensuite JQuery pour prendre ce paramètre et le glisser dans son nœud DOM approprié :)
Faites-moi savoir ce que vous pensez de mon hybride!
Si la réponse ne nécessite aucun autre traitement côté client, le format HTML convient à mon avis. L'envoi de JSON ne vous obligera qu'à effectuer ce traitement côté client.
Par ailleurs, j'utilise JSON lorsque je ne souhaite pas utiliser toutes les données de réponse en même temps. 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 les valeurs qui vont être utilisées pour renseigner 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, cela ne veut pas dire que cette séparation ne peut se faire que sur la frontière client/serveur. Si vous avez déjà cette séparation (sur le serveur) et que vous voulez simplement montrer quelque chose au client, que vous renvoyiez JSON et le post-traitiez sur le client, ou que vous renvoyiez simplement HTML, dépend entièrement de vos besoins. Dire que vous avez "tort" de renvoyer du HTML dans le cas général est tout simplement trop généreux pour une déclaration IMV.
Si vous voulez un client découplé net, ce qui, à mon avis, est la meilleure pratique, il est logique de disposer de 100% du DOM créé par javascript. Si vous créez un client basé sur MVC disposant de tout le savoir-faire nécessaire pour créer l'interface utilisateur, vos utilisateurs téléchargent un fichier javascript une fois et le mettent en cache sur le client. Toutes les demandes postérieures au 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 fournit une encapsulation propre et indépendante de la présentation.
Le côté serveur se concentre alors uniquement sur la livraison des données.
Ainsi, demain, lorsque le produit vous demandera de modifier complètement la conception d'une page, vous ne modifierez que le fichier JS source qui crée le DOM, mais vous serez probablement amené à réutiliser vos gestionnaires d'événements existants et le serveur sera inconscient car il est découplé à 100% de la présentation.
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'analyse de modèles côté client. Laissez-moi vous expliquer, alors que j’utilisais auparavant smarty et des vues côté serveur (générant une charge serveur élevée), j’utilise maintenant certaines fonctions jQuery personnalisées et toutes les données sont restituées côté client, en utilisant le navigateur des clients comme analyseur de modèles. il enregistre les ressources du serveur et, d'autre part, les navigateurs améliorent chaque jour leur moteur JS. Par conséquent, la vitesse d'analyse du client n'est pas un problème important pour le moment. De plus, les objets JSON sont généralement très petits et ne consomment donc 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 à cause du serveur très chargé.
D'autre part, en envoyant des données pures à partir d'un serveur, vous les extrayez de la présentation. Ainsi, si vous souhaitez les modifier ou les intégrer à un autre service demain, vous pourrez le faire beaucoup plus facilement.
Juste mes 2 cents.
Selon votre interface utilisateur, vous devrez peut-être mettre à jour deux (ou plusieurs) éléments différents dans votre DOM. Si votre réponse est en HTML, allez-vous analyser cela pour savoir ce qui se passe où? Ou vous pouvez simplement utiliser un hachage JSON.
Vous pouvez même le combiner, renvoyer un JSON avec données html :)
{ 'dom_ele_1' : '<p>My HTML part 1</p>', 'dome_ele_2' : '<div>Your payment has been received</div>' }
Le HTML comporte de nombreuses données redondantes et non affichées, telles que les balises, les feuilles de style, etc.
L'envoi de json est généralement effectué lorsque vous avez un widget javascript demandant des informations au serveur, tel qu'une liste, une vue en arborescence ou une saisie semi-automatique. C’est à ce moment-là que j’enverrais JSON, car ce sont des données qui seront analysées et utilisées brutes. Cependant, si vous voulez simplement montrer du HTML, il vous demandera beaucoup moins de travail de le générer côté serveur et de le montrer simplement dans le navigateur. Les navigateurs sont optimisés pour insérer du code HTML directement dans le domaine avec innerHTML = "". Vous ne pouvez donc pas vous tromper.
Cela dépend des circonstances.
Parfois, il est essentiel d'éviter JSON . Lorsque nos programmeurs ont des difficultés à programmer en js, par exemple.
Mon expérience me dit que: mieux utiliser le service ajax que le JSON en ligne.
Tôt ou tard, le JS devient un problème
La réponse HTML suffit dans la plupart des cas, sauf si vous devez effectuer des calculs côté client.
Je pense que cela dépend de la structure du design, il est simplement plus sexy d’utiliser JSON que HTML, mais la question est de savoir comment l’on peut le gérer pour qu’il soit facile à maintenir.
Par exemple, supposons que la page de liste utilise le même style/HTML que l'ensemble du site. J'écrirais la fonction globale pour formater ces portions de HTML et tout ce que je dois faire est de transmettre l'objet JSON à la fonction.