Почему Facebook, Twitter и GMail отображают все свои данные в браузере как JSON, а не HTML? - PullRequest
Новая
       6

Почему Facebook, Twitter и GMail отображают все свои данные в браузере как JSON, а не HTML?

11 голосов
/ 08 сентября 2011

Если вы войдете в Facebook, Twitter или Gmail и увидите источник, вы заметите нечто очень странное. Все ваши твиты и почта отображаются в формате JSON. Здесь нет угловых скобок. Я предполагаю, что все эти данные динамически отображаются в DOM. Если вы осмотрите какой-либо элемент на странице, вы увидите множество элементов div и других элементов HTML. Ни один из которых не был подан в оригинальной разметке. Вопросы:

  1. Почему бы этим 3 огромным сайтам понадобилось время для этого?
  2. Разве не было бы быстрее просто использовать HTML?
  3. Это для экономии пропускной способности, так как полезная нагрузка JSON меньше, чем HTML?
  4. Это потому, что эти сайты в значительной степени основаны на AJAX? Мое предположение было бы первым, но я понятия не имею. Я не уверен, нужно ли вам работать в Google Twitter или Facebook, чтобы понять, почему это так, но эта тактика используется всеми тремя сайтами, поэтому я считаю, что у них общая цель. Это заставляет меня думать, что это больше общего.

Ответы [ 5 ]

13 голосов
/ 08 сентября 2011

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

  1. Как уже упоминалось в предыдущих ответах, в браузере можно использовать кеширование, а полезная нагрузка JSON меньше
  2. Ониобеспечивает четкое разделение между службой, логикой пользовательского интерфейса и данными в соответствии с шаблоном MVC
    • JSON как модель
    • виджет JavaScript UI как представление, которое отображает данные
    • уровень службыв качестве контроллера, предоставляющего бизнес-логику / службу, которая подается на уровень пользовательского интерфейса

  3. Архитектура и разделение на основе API, упомянутые в пункте № 2 выше, позволяют компании обеспечивать доставку нескольких каналовбез особых переделок.Подумайте, хотите ли мы создать приложение для Twitter для Android:

    • JSON, поскольку модель остается прежней, здесь не нужно ничего переделывать, поскольку данные такие же
    • Теперь мы изменимПредставление из HTML в собственный пользовательский интерфейс Android, в этом случае нам потребуется кодировать код слоя пользовательского интерфейса
    • Service Layer, поскольку контроллер остается прежним, и нам здесь не нужно ничего делать

    Как вы можете видеть, эта модель позволяет Google / Twitter доставлять по нескольким каналам без необходимости переписывать их логику.То же самое относится к Mobile WebView по сравнению с обычным Desktop WebView.Все, что нам нужно изменить, - это уровень пользовательского интерфейса, а не уровень данных или контроллера.

Именно поэтому им требуется время, чтобы подумать о дизайне и архитектуре как таковой.Тесная связь между данными и представлением потребует от них переделки большого количества кода для доставки по нескольким каналам.Речь идет не о JSON против HTML или просто о сети, а скорее о архитектурном решении, которое позволило бы им доставлять свой контент на несколько каналов (iOS, Android, стороннее приложение, Mobile WebView, Desktop View, Desktop App и т. Д.).То, что вы видите в их HTML-источнике, является проявлением их стратегии в канале WebView.

3 голосов
/ 08 сентября 2011

Этот метод позволяет браузеру кэшировать HTML (и статические javascripts) и получать только строку json.Он довольно быстрый и дружелюбный.

2 голосов
/ 08 сентября 2011

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

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

0 голосов
/ 06 января 2012

По сути, это разделение представления и данных, перенесенных на другой уровень.На стороне сервера есть слой, который просто предоставляет данные.В целом, JSON - это хороший способ предоставить эти данные.Теперь то, как вы представляете, можно рассматривать отдельно.

Этот JSON может быть доставлен через веб-сервисы любому заинтересованному клиенту (Web / Desktop / Mobile / Other API).Тогда клиент может решить, как это представить.В Интернете мы используем много javascript-кодов для чтения и анализа этого JSON и манипулирования экраном / DOM.

0 голосов
/ 08 сентября 2011

Мое предположение: чтобы не повторять код, связанный с пользовательским интерфейсом.

Я только что взглянул на исходный код Twitter, и похоже, что они хотели сохранить всю логику пользовательского интерфейса в JavaScript. Это разумно, поскольку страница Twitter будет продолжать получать новые твиты, поэтому им все равно пришлось писать код, связанный с пользовательским интерфейсом, на JavaScript. Таким образом, вместо того, чтобы повторять один и тот же код в бэкэнде, он просто загружает исходные данные для рендеринга твитов во время загрузки страницы с помощью JavaScript.

Кэширование аргументов не имеет смысла для меня, так как он будет работать одинаково в любом подходе, так как исходный запрос страницы не кешируется.

...