Perché è una cattiva pratica restituire HTML generato anziché JSON? O è?

È abbastanza facile caricare contenuti HTML dai tuoi URL / servizi Web personalizzati utilizzando JQuery o qualsiasi altro framework simile. Ho usato questo approccio molte volte e fino ad ora e ho trovato le prestazioni soddisfacenti.

Ma tutti i libri, tutti gli esperti stanno cercando di farmi usare JSON invece di HTML generato. In che modo è molto più superiore dell'HTML?

È molto più veloce?
Ha un carico molto minore sul server?

Dall'altro lato ho alcuni motivi per usare HTML generato.

1. È un markup semplice e spesso altrettanto compatto o in realtà più compatto di JSON.
2. È meno soggetto a errori perché tutto ciò che ottieni è markup e nessun codice.
3. Nella maggior parte dei casi sarà più veloce programmare perché non sarà necessario scrivere il codice separatamente per il client.

Da che parte stai e perché?

Sono un po 'da entrambe le parti, in realtà:

• Quando ciò che mi serve sul lato javascript sono i dati , uso JSON
• Quando quello che mi serve sul lato javascript è la presentazione su cui non farò alcun calcolo, generalmente utilizzo l'HTML

Il vantaggio principale dell'utilizzo di HTML è quando si desidera sostituire una parte completa della pagina con ciò che ritorna dalla richiesta Ajax:

• Ricostruire una parte della pagina in JS è (abbastanza) difficile
• Probabilmente hai già un motore di template sul lato server, che è stato usato per generare la pagina in primo luogo ... Perché non riutilizzarla?

In genere non prendo davvero in considerazione il lato "prestazionale" delle cose, almeno sul server:

• Sul server, generare una porzione di HTML o un po 'di JSON probabilmente non farà molta differenza
• Circa le dimensioni del materiale che passa attraverso la rete: beh, probabilmente non usi centinaia di KB di dati / html ... L'uso di gzip su qualunque cosa tu stia trasferendo è ciò che farà la differenza (non scegliere tra HTML e JSON)
• Una cosa che potrebbe essere presa in considerazione, tuttavia, è quali risorse ti serviranno sul client per ricreare l'HTML (o la struttura DOM) dai dati JSON ... confrontalo con lo spingere una porzione di HTML nella pagina; -)

Infine, una cosa che conta definitivamente:

• Quanto tempo ci vorrà per sviluppare un nuovo sistema che invierà i dati come codice JSON + che JS ha richiesto per iniettarli come HTML nella pagina?
• Quanto tempo ci vorrà solo per restituire HTML? E per quanto tempo se riesci a riutilizzare parte del tuo codice lato server già esistente?

E per rispondere a un'altra risposta: se è necessario aggiornare più di una porzione della pagina, esiste ancora la soluzione / hacking di inviare tutte quelle parti all'interno di una grande stringa che raggruppa diverse parti HTML ed estrarre le parti pertinenti in JS.

Ad esempio, potresti restituire una stringa simile a questa:

<!-- 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 -->

Non sembra davvero buono, ma è sicuramente utile (l'ho usato un paio di volte, soprattutto quando i dati HTML erano troppo grandi per essere incapsulati in JSON) : stai inviando HTML per le parti della pagina che hai bisogno di presentazione e stai inviando JSON per la situazione in cui hai bisogno di dati ...

... E per estrarre quelli, il metodo di sottostringa JS farà il trucco, suppongo ;-)

Concordo principalmente con le opinioni espresse qui. Volevo solo riassumerli come:

• È una cattiva pratica inviare HTML se si finisce per analizzarlo sul lato client per fare alcuni calcoli su di esso.

• È una cattiva pratica inviare JSON se tutto ciò che farai sarà incorporarlo nell'albero DOM della pagina.

Bene,

Sono una di quelle rare persone a cui piace separare le cose in questo modo: - Il server è responsabile della consegna dei dati (modello); - Il cliente è responsabile della visualizzazione (visualizzazione) e della manipolazione dei dati (modello);

Quindi, il server dovrebbe concentrarsi sulla consegna del modello (in questo caso JSON è migliore). In questo modo, ottieni un approccio flessibile. Se vuoi cambiare la vista del tuo modello, mantieni il server che invia gli stessi dati e cambi semplicemente il client, i componenti javascript, che cambiano quei dati in una vista. Immagina di avere un server che fornisce dati ai dispositivi mobili e alle app desktop.

Inoltre, questo approccio aumenta la produttività, poiché il codice server e client può essere creato contemporaneamente, senza mai perdere l'attenzione che è ciò che accade quando si passa da js a PHP / JAVA / ecc.

In generale, penso che la maggior parte delle persone preferisca fare il più possibile sul lato server perché non padroneggiano js, ​​quindi cercano di evitarlo il più possibile.

Fondamentalmente, ho la stessa opinione di quei ragazzi che stanno lavorando su Angular. Secondo me è il futuro delle app web.

Ho qualcosa di interessante che ho pensato di aggiungere. Ho sviluppato un'applicazione che ha sempre caricato una vista completa solo una volta. Da quel momento in poi ha comunicato al server solo con Ajax. È sempre stato necessario caricare solo una pagina (la mia ragione non è importante qui). La parte interessante è che avevo una particolare necessità di restituire alcuni dati su cui operare nel javascript E una vista parziale da visualizzare. Avrei potuto dividerlo in due chiamate a due metodi di azione separati, ma ho deciso di scegliere qualcosa di un po 'più divertente.

Controlla:

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

Cos'è RenderPartialViewToString () che potresti chiedere? È questa piccola pepita di freschezza proprio qui:

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();
     }
}

Non ho fatto alcun test delle prestazioni su questo, quindi non sono sicuro se incorre in un sovraccarico più o meno rispetto alla chiamata di un metodo di azione per JsonResult e uno per ParticalViewResult, ma ho ancora pensato che fosse abbastanza bello. Serializza semplicemente una vista parziale in una stringa e la invia insieme a Json come uno dei suoi parametri. Quindi uso JQuery per prendere quel parametro e schiaffeggiarlo nel nodo DOM appropriato :)

Fammi sapere cosa ne pensi del mio ibrido!

Se la risposta non necessita di ulteriori elaborazioni sul lato client, secondo me l'HTML è OK. L'invio di JSON ti costringerà a eseguire tale elaborazione sul lato client.

D'altra parte, utilizzo JSON quando non desidero utilizzare tutti i dati di risposta contemporaneamente. Ad esempio, ho una serie di tre selezioni concatenate, in cui il valore selezionato di uno determina quali valori verranno utilizzati per popolare il secondo e così via.

IMV, si tratta solo di separare i dati dalla presentazione dei dati, ma sono con Pascal, non ne consegue necessariamente che tale separazione possa avvenire solo oltre il confine client / server. Se hai già quella separazione (sul server) e vuoi solo mostrare qualcosa al client, se rispedisci JSON e post-elaboralo sul client, o semplicemente rispedisci HTML, dipende interamente dalle tue esigenze. Dire che "sbagli" nel rinviare l'HTML nel caso generale è semplicemente una frase IMV troppo coperta.

JSON è un formato molto versatile e leggero. Ho scoperto la sua bellezza quando ho iniziato a usarlo come dati del parser del modello lato client. Permettetemi di spiegare, mentre prima utilizzavo smarty e viste sul lato server (generando un carico elevato del server), ora utilizzo alcune funzioni jquery personalizzate e tutti i dati vengono visualizzati sul lato client, usando il browser client come modello di parser. salva le risorse del server e d'altro canto i browser migliorano i loro motori JS ogni giorno. Quindi la velocità dell'analisi client non è un problema importante in questo momento, ancora di più, gli oggetti JSON sono di solito molto piccoli, quindi non consumano molte risorse sul lato client. Preferisco avere un sito web lento per alcuni utenti con un browser lento piuttosto che un sito lento per tutti a causa del server molto carico.

D'altra parte, l'invio di dati puri dal server lo sottragga dalla presentazione, quindi se domani vuoi modificarli o integrare i tuoi dati in un altro servizio puoi farlo molto più facilmente.

Solo i miei 2 centesimi.

Se vuoi un client disaccoppiato pulito, che secondo me è la migliore pratica, allora ha senso avere il 100% del DOM creato da javascript. Se si crea un client basato su MVC che ha tutto il know how per creare l'interfaccia utente, gli utenti scaricano un file javascript una volta ed è memorizzato nella cache sul client. Tutte le richieste successive a quel caricamento iniziale sono basate su Ajax e restituiscono solo dati. Questo approccio è il più pulito che ho trovato e prevede un incapsulamento pulito e indipendente della presentazione.

Il lato server si concentra quindi solo sulla consegna dei dati.

Quindi domani, quando il prodotto ti chiede di cambiare completamente il design di una pagina, tutto ciò che cambi è l'origine JS che crea il DOM, ma probabilmente riuscirai a riutilizzare i gestori di eventi già esistenti e il server è ignaro perché disaccoppiato al 100% dalla presentazione

A seconda dell'interfaccia utente, potrebbe essere necessario aggiornare due (o più) elementi diversi nel DOM. Se la tua risposta è in HTML, la analizzerai per capire cosa va dove? Oppure puoi semplicemente usare un hash JSON.

Puoi anche combinarlo, restituire un JSON con dati html :)

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

L'HTML ha molti dati ridondanti e non visualizzati, ad es. Tag, fogli di stile, ecc. Quindi le dimensioni dell'HTML rispetto ai dati JSON saranno maggiori, con conseguente aumento del tempo di download e di rendering, inoltre il browser sarà impegnato nel rendering dei nuovi dati.

L'invio di json viene generalmente eseguito quando si dispone di un widget javascript che richiede informazioni dal server, come un elenco o una vista ad albero o un completamento automatico. Questo è quando vorrei inviare JSON in quanto sono i dati che verranno analizzati e utilizzati grezzi. Tuttavia, se vuoi solo mostrare HTML, allora è molto meno lavoro per generarlo sul lato server e mostrarlo sul browser. I browser sono ottimizzati per l'inserimento di HTML direttamente nella dom con innerHTML = "", quindi non puoi sbagliare.

Penso che dipenda dalla struttura del design, è solo più sexy usare JSON che HTML ma la domanda è: come gestirlo per poterlo facilmente mantenere.

Ad esempio, supponiamo di avere la pagina di elenco che utilizza lo stesso html / stile dell'intero sito, scriverei la funzione globale per formattare quelle parti di HTML e tutto ciò che devo fare è passare l'oggetto JSON nella funzione.

La risposta HTML è sufficiente nella maggior parte dei casi a meno che non sia necessario eseguire alcuni calcoli sul lato client.

Dipende dalle circostanze.

A volte è essenziale evitare JSON. Ad esempio, quando i nostri programmatori hanno problemi a programmare in js.

La mia esperienza mi dice che: usare meglio il servizio Ajax di JSON in linea.

Prima o poi il js diventa un problema