Почему плохой практикой является возвращать сгенерированный HTML вместо JSON? Либо это?


301

Загружать HTML-контент из ваших пользовательских URL-адресов / веб-сервисов довольно просто, используя JQuery или любую другую подобную среду. Я использовал этот подход много раз и до сих пор и нашел производительность удовлетворительной.

Но все книги, все эксперты пытаются заставить меня использовать JSON вместо сгенерированного HTML. Как это намного лучше, чем HTML?

Это намного быстрее?
Есть ли у него значительно меньшая нагрузка на сервер?

С другой стороны, у меня есть несколько причин для использования сгенерированного HTML.

  1. Это простая разметка, часто такая же компактная или даже более компактная, чем JSON.
  2. Это менее подвержено ошибкам, потому что все, что вы получаете, это разметка, а не код.
  3. В большинстве случаев программирование будет выполняться быстрее, поскольку вам не придется писать код отдельно для клиентской части.

На какой ты стороне и почему?


Стоит отметить, что X в AJAX - это XML, а HTML в какой-то момент должен был быть XML. Идея заключалась в том, что HTML был человеком и машиночитаемыми данными (например, JSON), а CSS делал презентацию. В этих условиях не будет нарушено «разделение интересов» для отправки HTML в запросе AJAX
code_monk

Ответы:


255

Я немного с обеих сторон, на самом деле:

  • Когда на стороне javascript мне нужны данные , я использую JSON
  • Когда на стороне javascript мне нужна презентация, по которой я не буду делать никаких вычислений, я обычно использую HTML

Основное преимущество использования HTML - это когда вы хотите заменить полную часть своей страницы тем, что возвращается из запроса Ajax:

  • Перестроить часть страницы в JS (довольно) сложно
  • У вас, вероятно, уже есть какой-то шаблонизатор на стороне сервера, который был использован для генерации страницы в первую очередь ... Почему бы не использовать его повторно?

Обычно я не принимаю во внимание аспекты производительности, по крайней мере на сервере:

  • На сервере создание части HTML или некоторого JSON, вероятно, не будет иметь большого значения
  • О размере материала, который проходит через сеть: ну, вы, вероятно, не используете сотни КБ data / html ... Использование gzip для всего, что вы переносите, - вот что будет иметь наибольшее значение (не выбор между HTML и JSON)
  • Однако следует принять во внимание одну вещь: какие ресурсы потребуются клиенту для воссоздания HTML (или структуры DOM) из данных JSON ... сравните это с добавлением части HTML на страницу; -)

Наконец, одна вещь, которая определенно имеет значение:

  • Сколько времени вам понадобится, чтобы разработать новую систему, которая будет отправлять данные в виде JSON + кода JS, необходимого для внедрения их в виде HTML на страницу?
  • Сколько времени потребуется, чтобы просто вернуть HTML? И как долго, если вы сможете повторно использовать уже существующий серверный код?


И ответить на другой ответ: если вам нужно обновить более одной части страницы, все еще есть решение / взломать отправку всех этих частей в одну большую строку, которая группирует несколько частей HTML, и извлекать соответствующие части в JS.

Например, вы можете вернуть строку, которая выглядит следующим образом:

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

Это выглядит не очень хорошо, но это определенно полезно (я использовал это довольно пару раз, в основном, когда данные HTML были слишком большими, чтобы быть инкапсулированными в JSON) : вы отправляете HTML для частей страницы, которые нужна презентация, и вы отправляете JSON для ситуации, когда вам нужны данные ...

... И чтобы извлечь их, метод подстроки JS сделает свое дело, я полагаю ;-)


6
Все данные в конечном итоге представлены.
Кирилл Гупта

47
@ Кирилл: А? Я думаю, что вы пытаетесь сказать, что данные, которые будут полезны, должны использоваться и, таким образом, представлены где-то в некоторой форме, и я согласен. Но говорить о том, что данные являются представлением, кажется, по меньшей мере, ошибочным.
Винко Врсалович

10
Привет, Винко, обратите внимание на «в конечном итоге»? Я имею в виду именно то, что вы имеете в виду. Просто пытаюсь попасть в книгу цитат здесь. Ха ха!
Кирилл Гупта

37
Основной вопрос заключается в том, уверены ли вы, абсолютно точно, в конечном счете, что вы не будете использовать эти данные ни для чего, кроме HTML. Потому что после упаковки в HTML данные будут практически невосстановимыми. С JSON ваш бэкэнд может работать с XML, SVG, механизмами баз данных, межсайтовым API и тысячами других интерфейсов и систем, которые могут принимать JSON. С HTML вы сможете использовать его только внутри HTML.
SF.

3
@SF: при возврате HTML-кода с сервера я стараюсь отделить генерирующий HTML-код от кода, обращающегося к базе данных. Таким образом, я могу легко добавить форму JSON.
Casebash

114

Я в основном согласен с мнением, изложенным здесь. Я просто хотел обобщить их как:

  • Это плохая практика отправлять HTML, если вы в конечном итоге анализируете его на стороне клиента, чтобы выполнить некоторые вычисления над ним.

  • Неправильно отправлять JSON, если все, что вам в итоге нужно сделать, это включить его в дерево DOM страницы.


3
Что делать, если вам нужно сделать некоторые вычисления, а также включить его в DOM страницы?
Энрике

Интересно, как долго к этому утверждению будет приложена правдивость? Если вы добавите « Half-life of Knowledge » в уравнение?
Val

Можно ли вернуть HTML-код с тегами <script>, а затем выполнить их на стороне клиента при загрузке страницы?
nish1013

Это. Кроме того, если вы возвращаете данные, которые каким-то образом должны быть гибкими в их представлении, например, если у вас есть таблица HTML со столбцами, которые вы хотели бы иметь возможность сортировать. Независимо от того, сделали ли вы их сортируемыми сейчас или нет, возможно, вы захотите это позже, поэтому в таком случае проверка будущего стоит дополнительных усилий по прохождению маршрута JSON.
trpt4him

Я также добавил бы, что если вы запрашиваете URL-адреса изображений через JSON просто для того, чтобы попытаться отобразить их на странице, гораздо эффективнее включить их в HTML с самого начала, чтобы изображения могли начать загружаться раньше (до того, как ваш ajax вернется) ,
FailedUnitTest

30

Хорошо,

Я один из тех редких людей, которым нравится разделять вещи следующим образом: - сервер отвечает за доставку данных (модель); - клиент отвечает за отображение (просмотр) и манипулирование данными (модель);

Итак, сервер должен сосредоточиться на доставке модели (в этом случае JSON лучше). Таким образом, вы получаете гибкий подход. Если вы хотите изменить представление вашей модели, вы оставляете сервер, отправляющий те же данные, и просто изменяете клиент, компоненты javascript, которые превращают эти данные в представление. Представьте себе, у вас есть сервер доставки данных на мобильные устройства, а также настольные приложения.

Кроме того, такой подход повышает производительность, поскольку серверный и клиентский код можно создавать одновременно, не теряя при этом внимания, что происходит, когда вы продолжаете переключаться с js на PHP / JAVA / и т. Д.

Вообще, я думаю, что большинство людей предпочитают делать как можно больше на стороне сервера, потому что они не справляются с js, поэтому они стараются избегать этого как можно больше.

По сути, у меня такое же мнение, как и у тех парней, которые работают над Angular. На мой взгляд, это будущее веб-приложений.


Да, я полностью согласен с вами. Тем не менее, делая столько серверной стороны, когда дело касается конфиденциальной информации, я бы посчитал это лучшим. Если вам нужно, чтобы клиент реагировал по-разному, в зависимости от результата, я бы использовал json, иначе я бы использовал html.
Fi Horan

9

У меня есть кое-что интересное, я думаю, я мог бы добавить. Я разработал приложение, которое загружало полный просмотр только один раз. С этого момента он связывался с сервером только через ajax. Только когда-либо нужно было загрузить одну страницу (моя причина этого здесь не важна). Интересная часть состоит в том, что у меня была особая необходимость вернуть некоторые данные для обработки в javascript и частичное представление для отображения. Я мог бы разделить это на два вызова к двум отдельным методам действия, но я решил пойти с чем-то более веселым.

Проверьте это:

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

Что такое RenderPartialViewToString () вы можете спросить? Вот этот маленький самородок крутости прямо здесь:

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

Я не проводил никакого тестирования производительности на этом, поэтому я не уверен, что это потребует больше или меньше накладных расходов, чем вызов одного метода действия для JsonResult и одного для ParticalViewResult, но я все еще думал, что это было довольно круто. Он просто сериализует частичное представление в строку и отправляет его вместе с Json в качестве одного из параметров. Затем я использую JQuery, чтобы взять этот параметр и вставить его в соответствующий узел DOM :)

Дайте мне знать, что вы думаете о моем гибриде!


1
Отправка визуализированного представления и данных в одном запросе выглядит несколько избыточной. Шучу, если бы у вас была возможность выполнять рендеринг представления на стороне клиента, было бы еще лучше отправить шаблон представления и данные в виде отдельных запросов. Требуется дополнительный запрос, но только один раз, поскольку шаблонный запрос будет кэшироваться для последующих запросов. В идеале было бы лучше использовать комбинацию клиентского и серверного рендеринга, чтобы вы могли создавать страницы на сервере и частично в браузере, но если вы только реализуете рендеринг на стороне сервера, это неплохой подход.
Эван Плейс

8

Если ответ не требует дальнейшей обработки на стороне клиента, на мой взгляд, HTML в порядке. Отправка JSON только заставит вас выполнить эту обработку на стороне клиента.

С другой стороны, я использую JSON, когда не хочу использовать все данные ответов сразу. Например, у меня есть серия из трех связанных выборок, где выбранное значение одного определяет, какие значения будут использоваться для заполнения второго, и так далее.


7

IMV, это все о отделении данных от представления данных, но я с Паскаля, это не обязательно означает, что это разделение может быть только через границу клиент / сервер. Если у вас уже есть это разделение (на сервере) и вы просто хотите что-то показать клиенту, то, будете ли вы отправлять JSON и обрабатывать его на клиенте, или просто будете возвращать HTML, полностью зависит от ваших потребностей. Сказать, что вы «не правы» отправлять обратно HTML в общем случае, - это слишком сложно для утверждения IMV.


6

JSON - очень универсальный и легкий формат. Я обнаружил его красоту, когда начал использовать его как данные анализатора шаблонов на стороне клиента. Позвольте мне объяснить, что до того, как я использовал smarty и views на стороне сервера (создавая высокую нагрузку на сервер), теперь я использую некоторые пользовательские функции jquery, и все данные отображаются на стороне клиента, используя клиентский браузер в качестве парсера шаблонов. это экономит ресурсы сервера, и с другой стороны, браузеры улучшают свои движки JS каждый день. Таким образом, скорость синтаксического анализа клиента сейчас не важна, тем более что объекты JSON обычно очень малы, поэтому они не потребляют много ресурсов на стороне клиента. Я предпочитаю иметь медленный сайт для некоторых пользователей с медленным браузером, а не медленный сайт для всех из-за очень загруженного сервера.

С другой стороны, отправляя чистые данные с сервера, вы абстрагируете их от представления, поэтому, если завтра вы захотите изменить их или интегрировать свои данные в другой сервис, вы сможете сделать это намного проще.

Просто мои 2 цента.


И как вы гарантируете, что получите читаемую страницу, когда javascript отключен?
Винко Врсалович

8
если JS отключен, вы также не сможете загружать html. JS отключен у 2,3% пользователей согласно моей статистике Google Analytics. Лучший способ пойти вниз - постараться угодить всем.
Майк

4
Я согласен на 100% с Майком. Попытка угодить всем невозможна и только навредит вам. Если пользователи отключают JS, они должны быть использованы на многих сайтах, которые на них не работают.
Chev

1
Как вы получаете статистику JavaScript в Analytics, так как Analytics использует Javascript для отслеживания данных?
Ник

@ Ник Хороший вопрос, но я нашел это: stackoverflow.com/questions/15265883/…
Ренан Кавальери

6

Если вам нужен чистый отделенный клиент, что, на мой взгляд, является наилучшей практикой, то имеет смысл иметь 100% DOM, созданных с помощью javascript. Если вы создаете клиент на основе MVC, который обладает всеми необходимыми знаниями для создания пользовательского интерфейса, тогда ваши пользователи загружают один файл JavaScript один раз, и он кэшируется на клиенте. Все запросы после этой начальной загрузки основаны на Ajax и возвращают только данные. Этот подход является самым чистым, который я нашел, и обеспечивает чистую независимую инкапсуляцию презентации.

Серверная сторона тогда просто фокусируется на доставке данных.

Поэтому завтра, когда продукт просит вас полностью изменить дизайн страницы, все, что вы изменяете, - это исходный JS, который создает DOM, но, скорее всего, сможет повторно использовать ваши уже существующие обработчики событий, и сервер забывает, потому что он на 100% отделен от представления.


1
Я согласен, также вы можете повторно использовать JSON для вашего мобильного приложения.
Алекс Шилман

Это должен был быть принятый ответ - первые 6-7 слов отвечают на вопрос лаконично.
nicholaswmin

Согласен. Преимущество возвращаемых данных (JSON) перед презентацией (html) в том, что теперь у вас есть «бесплатный» веб-API, который можно повторно использовать для других клиентов, будь то мобильный или совершенно другое приложение, которое заинтересовано в данных из этого приложения. и т.д. По моему опыту, использование простой веб-инфраструктуры на стороне сервера, которая имеет дело только с данными, а не с представлением, часто приводит к хорошим и простым результатам. Современные браузеры и процессоры настолько быстры, что только в особых случаях рендеринг станет узким местом. Самым большим узким местом в основном являются сама сеть и вызов базы данных.
beginner_

4

В зависимости от вашего пользовательского интерфейса вам может потребоваться обновить два (или более) различных элемента в вашей DOM. Если ваш ответ в HTML, вы собираетесь проанализировать это, чтобы выяснить, что и куда? Или вы можете просто использовать хэш JSON.

Вы даже можете объединить это, вернуть JSON с HTML-данными :)

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

Неправильно отправлять JSON, если все, что вам в итоге нужно сделать, это включить его в дерево DOM страницы ... и, комбинируя JSON с HTML, вы используете эту плохую методику
thermz

2

В HTML много избыточных и не отображаемых данных, например тегов, таблиц стилей и т. Д. Таким образом, размер HTML по сравнению с данными JSON будет больше, что приведет к увеличению времени загрузки и рендеринга, а также к тому, что браузер будет занят рендерингом новых данных.


1

Отправка json обычно выполняется, когда у вас есть виджет javascript, запрашивающий информацию с сервера, такую ​​как список, древовидная структура или автозаполнение. Это когда я отправляю JSON, так как это данные, которые будут проанализированы и использованы в сыром виде. Однако, если вы просто собираетесь показывать HTML, то гораздо меньше работы для его генерации на стороне сервера и просто показа в браузере. Браузеры оптимизированы для вставки HTML непосредственно в dom с помощью innerHTML = "", поэтому вы не ошибетесь с этим.


FWIW, innerHTMLисторически намного медленнее, чем фрагмент документа: coderwall.com/p/o9ws2g/… .
Нейт Уиттекер,

0

Я думаю, что это зависит от структуры дизайна, просто использование JSON более привлекательно, чем HTML, но вопрос в том, как справиться с этим, чтобы его было легко поддерживать.

Например, скажем, у меня есть страница листинга, которая использует тот же html / стиль всего сайта, я написал бы глобальную функцию для форматирования этих частей HTML, и все, что мне нужно сделать, это передать объект JSON в функцию.


0

Html-ответа достаточно в большинстве случаев, если только вам не придется выполнять какие-либо вычисления на стороне клиента.


0

Зависит от обстоятельств.

Иногда важно избегать JSON. Например, когда у наших программистов возникают проблемы с программированием на js.

Мой опыт подсказывает мне, что лучше использовать сервис ajax, чем встроенный JSON.

Рано или поздно JS становится проблемой

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.