Глава 01. Гипермедиа: реинтродукция
Гипермедиа сегодня — универсальная технология, почти такая же распространенная, как электричество.
Миллиарды людей используют системы на основе гипермедиа каждый день, в основном взаимодействуя с языком разметки гипертекста (HTML), обмен которым осуществляется через протокол передачи гипертекста (HTTP) , с помощью веб-браузера, подключенного к Всемирной паутине.
Люди используют эти системы, чтобы узнавать новости, узнавать друзей, покупать вещи в Интернете, играть в игры, отправлять электронные письма и т. д. Разнообразие и огромное количество онлайн-услуг, предоставляемых гипермедиа, поистине поразительны.
И все же, несмотря на эту повсеместность, сама по себе тема гипермедиа сегодня является на удивление малоисследованной концепцией, оставленной в основном специалистам. Да, вы можете найти множество руководств о том, как создавать HTML, создавать ссылки и формы и т. д. Но редко можно увидеть обсуждение HTML как гипермедиа и, в более широком смысле, о том, как вся система гипермедиа сочетается друг с другом.
Это контрастирует с ранней эпохой веб-разработки, когда такие концепции, как передача репрезентативного состояния (REST)и гипермедиа как двигатель состояния приложения (HATEOAS), часто обсуждались, уточнялись и обсуждались среди веб-разработчиков.
При печальном повороте событий сегодня к самому популярному в мире гипермедиа, HTML, часто относятся с негодованием: это неуклюжий устаревший язык разметки, который приходится неохотно использовать для создания пользовательских интерфейсов в веб-приложениях, которые все чаще полностью основаны на JavaScript.
HTML есть в браузере, и поэтому нам приходится его использовать.
Это позор, и мы надеемся убедить вас, что гипермедиа — это не просто часть устаревшей технологии, которую нам приходится принимать и с которой приходится иметь дело. Вместо этого мы стремимся показать вам, что гипермедиа — это чрезвычайно инновационный, простой и гибкий способ создания надежных приложений: приложения, управляемые гипермедиа .
Мы надеемся, что к концу этой книги вы, как и мы, почувствуете, что подход гипермедиа заслуживает места за столом, когда вы, веб-разработчик, обдумываете архитектуру своего следующего приложения. Создание приложения, управляемого гипермедиа, поверх такой гипермедийной системы , как Интернет, является жизнеспособным и зачастую отличным выбором для современных веб-приложений.
(И, как будет показано в разделе, посвященном Hyperview, не только веб-приложениям.)
Что такое гипермедиа?
Гипертексты: новые формы письма, появляющиеся на экранах компьютеров, которые разветвляются или действуют по команде читателя. Гипертекст — это непоследовательный фрагмент текста; только дисплей компьютера делает его практичным.
— Тед Нельсон, https://archive.org/details/SelectedPapers1977/page/n7/mode/2up
Начнем с самого начала: что такое гипермедиа?
Гипермедиа — это носитель, например текст, который включает в себя нелинейное ветвление от одного места носителя к другому, например, посредством гиперссылок, встроенных в носитель. Префикс «гипер-» происходит от греческого префикса «ὑπερ-», который означает «за пределами» или «сверх», указывая на то, что гипермедиа выходит за рамки обычных, пассивно потребляемых средств массовой информации, таких как журналы и газеты.
Гиперссылки являются каноническим примером того, что называется элементом управления гипермедиа :
Гипермедиа контроль
Элемент управления гипермедиа — это элемент гипермедиа, который описывает (или контролирует) некоторый вид взаимодействия, часто с удаленным сервером, путем кодирования информации об этом взаимодействии непосредственно и полностью внутри себя.
Элементы управления гипермедиа — это то, что отличает гипермедиа от других видов медиа.
Возможно, вам более знаком термин «гипертекст» , со страницы Википедии которого взята приведенная выше цитата. Гипертекст — это подкатегория гипермедиа, и большая часть этой книги посвящена обсуждению того, как создавать современные приложения с использованием гипертекстов, таких как HTML, язык разметки гипертекста или HXML, гипертекст, используемый системой мобильной гипермедиа Hyperview.
Гипертексты, такие как HTML, функционируют наряду с другими технологиями, имеющими решающее значение для работы всей системы гипермедиа: сетевые протоколы, такие как HTTP, другие типы мультимедиа, такие как изображения и видео, серверы гипермедиа (т. е. серверы, предоставляющие API-интерфейсы гипермедиа), сложные клиенты гипермедиа (например, веб-браузеры). , и так далее.
По этой причине мы предпочитаем более широкий термин «гипермедийные системы» при описании базовой архитектуры приложений, созданных с использованием гипертекста, чтобы подчеркнуть архитектуру системы, а не конкретную используемую гипермедиа.
Многие современные веб-разработчики недооценивают и игнорируют всю архитектуру системы гипермедиа.
Краткая история гипермедиа
Откуда взялась идея гипермедиа?
Хотя существовало множество предшественников современной идеи гипертекста и более общей гипермедиа, многие люди указывают на статью 1945 года « Как мы можем думать », написанную Ванневаром Бушем в The Atlantic, как отправную точку для рассмотрения того, что стало современной гипермедиа.
В этой статье Буш описал устройство под названием Memex, которое, используя сложную механическую систему катушек и микрофильмов, а также систему кодирования, позволит пользователям переключаться между связанными кадрами контента. Memex так и не был реализован, но послужил источником вдохновения для последующих работ над идеей гипермедиа.
Термины «гипертекст» и «гипермедиа» были придуманы в 1963 году Тедом Нельсоном, который продолжил работу над системой редактирования гипертекста в Университете Брауна, а позже создал систему поиска и редактирования файлов (FRESS) , потрясающе продвинутую систему гипермедиа. для своего времени. (Возможно, это была первая цифровая система, в которой было понятие «отмена».)
Пока Нельсон работал над своими идеями, Дуглас Энгельбарт был занят работой в Стэнфордском исследовательском институте, явно пытаясь воплотить в жизнь мемекс Ванневара Буша. В 1968 году Энглбарт выступил с «Матерью всех демонстраций» в Сан-Франциско, Калифорния.
Энглбарт продемонстрировал невероятное количество технологий:
Удаленное редактирование текста совместно со своими коллегами из Менло-Парка.
Видео и аудио чат.
Интегрированная оконная система с возможностью изменения размера окон и т. д.
Узнаваемый гипертекст, при нажатии на подчеркнутый текст осуществляется переход к новому содержимому.
Несмотря на овации потрясенной аудитории после его выступления, прошли десятилетия, прежде чем технологии, продемонстрированные Энглбартом, стали мейнстримом.
Современная реализация
В 1990 году Тим Бернерс-Ли, работавший в ЦЕРНе, опубликовал первый веб-сайт. Он работал над идеей гипертекста в течение десяти лет и, наконец, в отчаянии от того, что исследователям было так трудно делиться своими исследованиями, нашел подходящий момент и институциональную поддержку для создания Всемирной паутины:
Создание сети было действительно актом отчаяния, потому что ситуация без нее была очень сложной, когда я позже работал в ЦЕРНе. Большинство технологий, используемых в сети, например, гипертекст, Интернет, многошрифтовые текстовые объекты, уже были разработаны. Мне оставалось только собрать их вместе. Это был шаг к обобщению, переходу на более высокий уровень абстракции, размышлению обо всех существующих системах документации как о возможной части более крупной воображаемой системы документации.
— Тим Бернерс-Ли, https://britishheritage.org/tim-berners-lee-the-world-wide-web
К 1994 году его творение стало настолько популярным, что Бернерс-Ли основал W3C, рабочую группу компаний и исследователей, задачей которой было улучшение Интернета. Все стандарты, созданные W3C, были бесплатными и могли быть приняты и реализованы кем угодно, что закрепляло открытую и совместную природу Интернета.
В 2000 году Рой Филдинг, тогда работавший в Калифорнийском университете в Ирвайне, опубликовал в Интернете основополагающую докторскую диссертацию: «Архитектурные стили и проектирование сетевых архитектур программного обеспечения». Филдинг работал над HTTP-сервером Apache с открытым исходным кодом, и его диссертация представляла собой описание того, что, по его мнению, было новой и особой сетевой архитектурой , возникшей на заре Интернета. Филдинг работал над первоначальными спецификациями HTTP и в своей статье определил модель сети гипермедиа в Интернете, используя термин REpresentational State Transfer (REST) .
Работа Филдинга стала основным пробным камнем для первых веб-разработчиков, предоставив им язык для обсуждения новой технической среды, в которой они создавали приложения.
Мы подробно обсудим ключевые идеи Филдинга в главе 2 и попытаемся исправить ситуацию в отношении REST, HATEOAS и гипермедиа.
Самый успешный гипертекст в мире: HTML
Вначале была гиперссылка, и гиперссылка была в сети, и гиперссылка была сеть. И это было хорошо.
— Спасение REST от зимы API, https://intercoolerjs.org/2016/01/18/rescuing-rest.html .
Система, которую создали Бернерс-Ли, Филдинг и многие другие, вращалась вокруг гипермедиа: HTML. HTML начинался как гипермедиа, доступная только для чтения и использовавшаяся (сначала) для публикации научных документов. Эти документы были связаны между собой с помощью тегов привязки, которые создавали между ними гиперссылки , позволяя пользователям быстро перемещаться между документами.
Когда был выпущен HTML 2.0, в нем появилось понятие тега form, присоединившегося к тегу привязки (т. е. гиперссылке) в качестве второго элемента управления гипермедиа. Введение тега формы сделало создание веб- приложений жизнеспособным, предоставив механизм обновления ресурсов, а не просто их чтения.
Именно в этот момент Интернет превратился из интересной документально-ориентированной системы в привлекательную прикладную архитектуру .
Сегодня HTML является наиболее широко используемым из существующих гипермедиа, и в этой книге, естественно, предполагается, что читатель имеет достаточное представление о нем. Вам не нужно быть экспертом по HTML (или CSS), чтобы понять код в этой книге, но чем лучше вы понимаете основные теги и концепции HTML, тем больше вы получите от нее.
Сущность HTML как гипермедиа
Давайте рассмотрим эти два определяющих элемента гипермедиа (то есть два определяющих элемента управления гипермедиа ) HTML, тег привязки и тег формы, немного подробнее.
Привязка тегов
Теги привязки настолько знакомы, что кажутся скучными, но, как исходный элемент управления гипермедиа, стоит пересмотреть механику гиперссылок, чтобы направить мысли в нужное место для более глубокого понимания гипермедиа.
Рассмотрим простой тег привязки, встроенный в более крупный HTML-документ:
Тег привязки состоит из самого тега, <a></a>а также атрибутов и содержимого внутри тега. Особый интерес представляет hrefатрибут, задающий гипертекстовую ссылку на другой документ или фрагмент документа. Именно этот атрибут делает тег привязки элементом управления гипермедиа.
В типичном веб-браузере этот тег привязки будет интерпретироваться как:
Покажите текст «Hypermedia Systems» таким образом, чтобы он был кликабельным.
Возьмите HTML-содержимое тела HTTP-ответа на этот запрос и замените весь экран браузера новым документом, обновив панель навигации на этот новый URL-адрес.
Якоря представляют собой основной механизм, который мы используем сегодня для навигации по сети, выбирая ссылки для перехода от документа к документу или от ресурса к ресурсу.
Вот как визуально выглядит взаимодействие пользователя с тегом привязки/гиперссылкой:
При нажатии на ссылку браузер (или, как мы его иногда называем, клиент гипермедиа ) инициирует HTTP- GETзапрос к URL-адресу, закодированному в атрибуте ссылки href.
Обратите внимание, что HTTP-запрос включает дополнительные данные (т. е. метаданные ) о том, что именно браузер хочет от сервера, в виде заголовков. Мы обсудим эти заголовки и HTTP более подробно в главе 2.
Затем сервер гипермедиа отвечает на этот запрос ответом гипермедиа — HTML — для новой страницы. Это может показаться небольшим и очевидным моментом, но это абсолютно важный аспект по-настоящему RESTful гипермедиа-системы : клиент и сервер должны взаимодействовать через гипермедиа!
Теги формы
Теги привязки обеспечивают навигацию между документами или ресурсами, но не позволяют обновлять эти ресурсы. Эта функциональность относится к тегу формы.
Вот простой пример формы в HTML:
Как и тег привязки, тег формы состоит из самого тега <form></form>в сочетании с атрибутами и содержимым внутри тега. Обратите внимание, что тег формы не имеет hrefатрибута, а имеет actionатрибут, указывающий, где выдавать HTTP-запрос.
Более того, у него также есть methodатрибут, который точно определяет, какой именно «метод» HTTP использовать. В этом примере форма просит браузер выдать запрос POST.
В отличие от тегов привязки, содержимое и теги внутри формы могут влиять на взаимодействие гипермедиа, которое форма осуществляет с сервером. Значения тегов и других тегов, таких как теги, будут включены в HTTP-запрос при отправке формы, как параметры URL-адреса в случае a и как часть тела запроса в случае . Это позволяет форме включать в запрос произвольный объем информации, полученной от пользователя, в отличие от тега привязки.inputselectGETPOST
В типичном браузере этот тег формы и его содержимое будут интерпретироваться браузером примерно следующим образом:
Покажите пользователю текстовый ввод и кнопку «Зарегистрироваться».
Когда пользователь отправляет форму, нажав кнопку «Зарегистрироваться» или нажав клавишу ввода, когда элемент ввода находится в фокусе, выдайте HTTP-
POSTзапрос к пути/signupна «текущем» сервере.Возьмите HTML-содержимое тела ответа HTTP и замените весь экран браузера новым документом, обновив панель навигации на этот новый URL-адрес.
Этот механизм позволяет пользователю отправлять запросы на обновление состояния ресурсов на сервере. Обратите внимание, что, несмотря на этот новый тип запроса, связь между клиентом и сервером по-прежнему полностью осуществляется с помощью гипермедиа .
Именно тег формы делает возможными приложения, управляемые гипермедиа.
Если вы опытный веб-разработчик, вы, вероятно, понимаете, что мы опускаем здесь некоторые детали и сложности. Например, ответ на отправку формы часто перенаправляет клиента на другой URL-адрес.
Это правда, и мы более подробно углубимся в формы с формами в последующих главах, но на данный момент этого простого примера достаточно, чтобы продемонстрировать основной механизм обновления состояния системы исключительно в гипермедиа.
Вот схема взаимодействия:
Приложения Веб 1.0
Как человек, интересующийся веб-разработкой, приведенные выше диаграммы и обсуждение, вероятно, вам очень знакомы. Возможно, вам даже покажется этот контент скучным. Но сделайте шаг назад и учтите тот факт, что эти два элемента управления гипермедиа, привязки и формы, являются единственными собственными способами взаимодействия пользователя с сервером в простом HTML.
Всего две метки!
И все же, вооружившись только этими двумя тегами, ранняя сеть могла расти в геометрической прогрессии и предлагать ошеломляюще большое количество онлайн-динамических функций миллиардам людей.
Это убедительное свидетельство силы гипермедиа. Даже сегодня, в мире веб-разработки, в котором все больше доминируют крупные интерфейсные платформы, ориентированные на JavaScript, многие люди предпочитают использовать простой HTML-код для достижения целей своих приложений и часто полностью довольны результатами.
Эти два тега придают HTML огромную выразительную силу.
Так чем же не гипермедиа?
Таким образом, ссылки и формы — это два основных механизма взаимодействия с сервером, основанных на гипермедиа, доступных в HTML.
Оформите запрос.
Преобразуйте ответ в объект JavaScript.
Вызовите
updateUI()функцию с объектом.
Эта кнопка имеет onclickатрибут, который определяет некоторый код JavaScript, который будет запускаться при нажатии кнопки.
JavaScript выдаст HTTP- GETзапрос AJAX для /api/v1/contacts/1использования fetch(). Запрос AJAX похож на «обычный» HTTP-запрос, но он выдается браузером «за кулисами». Пользователь не видит индикатор запроса из браузера, как при использовании обычных ссылок и форм. Кроме того, в отличие от запросов, выдаваемых этими элементами управления гипермедиа, код JavaScript должен обрабатывать ответ от сервера.
Несмотря на то, что AJAX имеет XML как часть своей аббревиатуры, сегодня ответ HTTP на этот запрос почти наверняка будет в формате нотации объектов JavaScript (JSON), а не XML.
HTTP-ответ на этот запрос может выглядеть примерно так:
Начало объекта JSON.
Свойство, в данном случае с именем
idи значением42.Еще одно свойство — адрес электронной почты контакта с этим идентификатором.
Приведенный выше код JavaScript преобразует текст JSON, полученный от сервера, в объект JavaScript, вызывая json()для него метод. Затем этот новый объект JavaScript передается методу updateUI().
Этот updateUI()метод отвечает за обновление пользовательского интерфейса на основе данных, закодированных в объекте JavaScript, возможно, путем отображения контакта в фрагменте HTML, сгенерированном с помощью шаблона на стороне клиента в приложении JavaScript.
Детали того, что именно updateUI()делает функция, не важны для нашего обсуждения.
Что важно , решающим аспектом этого взаимодействия с сервером на основе JSON является то, что оно не использует гипермедиа. Используемый здесь JSON API не возвращает ответ гипермедиа. В нем нет гиперссылок или других элементов управления в стиле гипермедиа.
Этот JSON API — это, скорее, Data API .
Поскольку ответ находится в формате JSON и не является гипермедиа, метод JavaScript updateUI()должен понимать, как преобразовать эти контактные данные в HTML.
В частности, коду updateUI()необходимо знать внутреннюю структуру и значение данных.
Ему необходимо знать:
Точно так же структурированы и названы поля в объекте данных JSON.
Как они связаны друг с другом.
Как обновить локальные данные, которым соответствуют эти новые данные.
Как отобразить эти данные в браузере.
Какие дополнительные действия/конечные точки API можно вызвать с помощью этих данных.
Короче говоря, логика updateUI()должна иметь глубокие знания о конечной точке API /api/v1/contact/1, знания, предоставляемые через какой-то побочный канал, помимо самого ответа. В результате updateUI()код и API имеют прочную связь, известную как жесткая связь : если формат ответа JSON изменится, то updateUI()почти наверняка код также потребуется изменить.
Одностраничные приложения
Этот фрагмент JavaScript, хотя и очень скромный, является естественным началом гораздо более масштабного концептуального подхода к созданию веб-приложений. Это начало одностраничного приложения (SPA) . Веб-приложение больше не перемещается между страницами с помощью элементов управления гипермедиа, как это было в случае со ссылками и формами.
Вместо этого приложение обменивается простыми данными с сервером, а затем обновляет содержимое на одной странице.
Когда эта стратегия или архитектура применяется для всего приложения, все происходит на «одной странице», и, таким образом, приложение становится «одностраничным приложением».
Архитектура одностраничных приложений сегодня чрезвычайно популярна и является доминирующим подходом к созданию веб-приложений за последнее десятилетие. Об этом можно судить по тому высокому уровню внимания и дискуссий, которые он получил в отрасли.
Сегодня подавляющее большинство одностраничных приложений используют гораздо более сложные структуры для управления пользовательским интерфейсом, чем показано в этом простом примере. Популярные библиотеки, такие как React, Angular, Vue.js и т. д., теперь являются распространенным и даже стандартным способом создания веб-приложений.
В этих более сложных средах разработчики обычно работают со сложной моделью на стороне клиента, то есть с объектами JavaScript, хранящимися локально в памяти браузера и представляющими «модель» или «домен» вашего приложения. Эти объекты JavaScript обновляются с помощью кода JavaScript, а затем платформа «реагирует» на эти изменения, обновляя пользовательский интерфейс.
Когда пользователь обновляет пользовательский интерфейс, эти изменения также передаются в объекты модели, создавая «двусторонний» механизм привязки: модель может обновлять пользовательский интерфейс, а пользовательский интерфейс может обновлять модель.
Это гораздо более сложный подход к веб-клиенту, чем гипермедиа, и обычно он почти полностью исключает базовую инфраструктуру гипермедиа, доступную в браузере.
HTML по-прежнему используется для создания пользовательских интерфейсов, но гипермедийный аспект двух основных элементов управления гипермедиа — якорей и форм — не используется. Ни один из тегов не взаимодействует с сервером через собственный механизм гипермедиа . Скорее, они становятся элементами пользовательского интерфейса, которые управляют локальным взаимодействием с моделью предметной области в памяти через JavaScript, который затем синхронизируется с сервером с помощью API-интерфейсов JSON с простыми данными.
Итак, как и в случае с нашей простой кнопкой выше, подход «Одностраничное приложение» исключает архитектуру гипермедиа. Он оставляет в стороне преимущества существующей веб-архитектуры RESTful и встроенных функций, имеющихся в собственных элементах управления гипермедиа HTML, в пользу поведения, управляемого JavaScript.
SPA больше похожи на приложения «толстого клиента» , то есть на клиент-серверные приложения 1980-х годов — архитектуру, популярную до появления Интернета и на которую Интернет во многом был реакцией.
Конечно, этот подход не обязательно неправильный: бывают случаи, когда подход с толстым клиентом является подходящим выбором для приложения. Но стоит задуматься, почему веб-разработчики так часто делают этот выбор, не рассматривая другие альтернативы, и есть ли причины не идти по этому пути.
Зачем использовать гипермедиа?
Новой нормой веб-разработки является создание одностраничного приложения React с серверным рендерингом. Два ключевых элемента этой архитектуры выглядят примерно так:
Основной пользовательский интерфейс создается и обновляется на JavaScript с использованием React или чего-то подобного.
Бэкэнд — это API, к которому приложение отправляет запросы.
Эта идея действительно захлестнула Интернет. Все началось с нескольких крупных популярных веб-сайтов и распространилось на такие уголки, как маркетинговые сайты и блоги.
— Том Макрайт, https://macwright.com/2020/05/10/spa-fatigue.html
Подход одностраничного приложения на основе JavaScript покорил мир веб-разработки, и если и была одна-единственная причина его бешеного успеха, то она заключалась в следующем: одностраничное приложение предлагает гораздо более интерактивный и захватывающий опыт, чем старое, неуклюжее, Приложения на основе гипермедиа Web 1.0 могли бы это сделать. SPA имели возможность плавно обновлять элементы внутри страницы без резкой перезагрузки всего документа, у них была возможность использовать CSS-переходы для создания приятных визуальных эффектов и возможность подключаться к произвольным событиям, таким как движения мыши.
Все эти возможности дают приложениям на основе JavaScript огромное преимущество в создании сложного пользовательского опыта.
Учитывая популярность, мощь и успех этого современного подхода к созданию веб-приложений, с какой стати вам рассматривать более старый, более громоздкий и менее популярный подход, такой как гипермедиа?
Усталость JavaScript
Мы рады, что вы спросили!
Оказывается, архитектура гипермедиа, даже в ее исходной форме Web 1.0, имеет ряд преимуществ по сравнению с подходом Single Page Application + JSON Data API. Три из самых крупных:
Это чрезвычайно простой подход к созданию веб-приложений.
Он чрезвычайно терпим к изменениям контента и API. На самом деле, оно процветает за счет них!
Он использует проверенные и надежные функции веб-браузеров, такие как кэширование.
Первые два преимущества, в частности, устраняют основные болевые точки современной веб-разработки:
Инфраструктура одностраничных приложений стала чрезвычайно сложной, и для ее управления часто требуется целая команда.
Изменение JSON API — постоянные изменения, вносимые в JSON API для поддержки потребностей приложений — стало основной проблемой для многих команд разработчиков приложений.
Сочетание этих двух проблем, а также других проблем, таких как отток библиотек JavaScript, привело к явлению, известному как «усталость JavaScript». Это относится к общему чувству усталости от всех препятствий, которые необходимо преодолеть, чтобы что-то сделать в современных веб-приложениях.
Мы считаем, что гипермедийная архитектура может помочь многим разработчикам и командам избавиться от усталости от JavaScript.
Но если гипермедиа так хороша и если она решает так много проблем, с которыми сталкивается индустрия веб-разработки, почему ее вообще оставили в стороне? В конце концов, гипермедиа была первой. Почему веб-разработчики просто не придерживались этого?
Есть две основные причины, по которым гипермедиа не вернулась в веб-разработку.
Во-первых, выразительность HTML как гипермедиа не сильно изменилась, если вообще изменилась, со времен HTML 2.0, выпущенного в середине 1990-х годов . Конечно, в HTML было добавлено много новых функций , но за последние почти три десятилетия не было никаких серьезных новых способов взаимодействия с сервером в HTML.
Разработчики HTML по-прежнему имеют только теги привязки и формы, доступные в качестве элементов управления гипермедиа, и эти элементы управления гипермедиа по-прежнему могут только выдавать GETи POSTзапрашивать.
Это озадачивающее отсутствие прогресса в HTML немедленно приводит ко второй и, возможно, более практической причине того, что HTML как гипермедиа переживает трудные времена: поскольку интерактивность и выразительность HTML остаются замороженными, требования веб-пользователей продолжают расти. , призывая к созданию все большего количества интерактивных веб-приложений.
Приложения на основе JavaScript в сочетании с API-интерфейсами JSON, ориентированными на данные, стали способом предоставления этих более сложных пользовательских интерфейсов. Именно тот пользовательский опыт , которого можно было достичь с помощью JavaScript и которого нельзя было достичь с помощью простого HTML, побудил сообщество веб-разработчиков перейти к подходу к одностраничным приложениям на основе JavaScript. Этот сдвиг не был вызван каким-либо внутренним превосходством одностраничного приложения как системной архитектуры.
Так не должно было быть. В идее гипермедиа нет ничего такого , что мешало бы иметь более богатую и выразительную модель интерактивности, чем стандартный HTML. Вместо того, чтобы отходить от подхода, основанного на гипермедиа, отрасль могла бы потребовать большей интерактивности от HTML.
Вместо этого стандартом стало создание приложений в стиле толстого клиента в веб-браузерах, что стало понятным переходом к более привычной модели создания многофункциональных приложений.
Конечно, не все игнорируют гипермедиа. Были предприняты героические усилия по дальнейшему развитию гипермедиа за пределами HTML, такие как HyTime, VoiceXML и HAL.
Но HTML, наиболее широко используемый гипермедиа в мире, перестал развиваться как гипермедиа. Мир веб-разработки пошел дальше, решая проблемы интерактивности с помощью HTML, приняв SPA на основе JavaScript и, в основном непреднамеренно, совершенно другую системную архитектуру.
Возрождение гипермедиа?
Интересно подумать о том, как мог бы развиваться HTML. Как HTML мог бы продолжать развиваться вместо того, чтобы застопориться в качестве гипермедиа? Могло ли оно продолжать добавлять новые элементы управления гипермедиа и увеличивать выразительность существующих? Можно ли было создавать современные веб-приложения в рамках этой оригинальной, ориентированной на гипермедиа и RESTful модели, которая сделала раннюю сеть Интернет такой мощной, такой гибкой и такой увлекательной?
Это может показаться пустым предположением, но у нас есть хорошие новости на этот счет: за последнее десятилетие появилось несколько своеобразных альтернативных библиотек внешнего интерфейса, которые пытаются снова продвинуть HTML. По иронии судьбы, эти библиотеки написаны на JavaScript — технологии, которая вытеснила HTML в качестве центра веб-разработки.
Однако эти библиотеки используют JavaScript не в качестве замены фундаментальной гипермедийной системы Интернета.
Вместо этого они используют JavaScript для расширения самого HTML как гипермедиа .
Эти библиотеки , ориентированные на гипермедиа, превращают гипермедиа в основную технологию веб-приложений.
Библиотеки JavaScript, ориентированные на гипермедиа
В мире веб-разработки продолжаются споры между подходом одностраничного приложения (SPA) и подходом, который сейчас называется подходом «многостраничного приложения» (MPA). MPA — это современное название старого способа создания веб-приложений Web 1.0, использующего ссылки и формы, расположенные на нескольких веб-страницах, отправки HTTP-запросов и получения ответов HTML.
Приложения MPA по своей природе являются приложениями, управляемыми гипермедиа: в конце концов, это именно то, что Рой Филдинг описал в своей диссертации.
Эти приложения, как правило, неуклюжи, но работают достаточно хорошо. Многие веб-разработчики и команды предпочитают принять ограничения простого HTML в интересах простоты и надежности.
Рич Харрис, создатель Svelte.js, популярной библиотеки SPA, и идейный лидер в дебатах по поводу SPA, предложил сочетание этого старого стиля MPA и нового стиля SPA. Харрис называет этот подход к созданию веб-приложений «переходным», поскольку он пытается объединить подход MPA и новый подход SPA в единое целое. (Это чем-то похоже на «переходное» направление в архитектуре, сочетающее традиционные и современные архитектурные стили.)
Термин «переходный» подходит для приложений смешанного типа и предлагает разумный компромисс между двумя подходами, используя любой из них в зависимости от конкретного случая.
Но этот компромисс по-прежнему кажется неудовлетворительным.
Должны ли мы по умолчанию использовать эти две очень разные архитектурные модели в наших приложениях?
Напомним, что суть компромисса между SPA и MPA — это пользовательский опыт или интерактивность приложения. Обычно это определяет решение о выборе одного подхода по сравнению с другим для приложения или — в случае «переходного» приложения — для конкретной функции.
Оказывается, что благодаря использованию библиотеки, ориентированной на гипермедиа, разрыв в интерактивности между подходами MPA и SPA резко сокращается. Вы можете использовать подход MPA, то есть подход гипермедиа, для большей части вашего приложения без ущерба для пользовательского интерфейса. Возможно, вы даже сможете использовать подход гипермедиа для всех нужд вашего приложения.
Вместо того, чтобы использовать SPA с небольшим количеством гипермедиа по краям или сочетанием этих двух подходов, вы часто можете создать веб-приложение, которое в первую очередь или полностью управляется гипермедиа и которое по-прежнему удовлетворяет интерактивности, необходимой вашим пользователям.
Это может значительно упростить ваше веб-приложение и создать гораздо более связную и понятную часть программного обеспечения. Хотя еще есть время и место для более сложного подхода SPA, который мы обсудим позже в книге, приняв подход, ориентированный на гипермедиа, и используя библиотеку, ориентированную на гипермедиа, чтобы максимально расширить HTML, ваше веб-приложение может быть мощный, интерактивный и простой.
И делать это очень весело и просто.
Приложения, управляемые гипермедиа
При создании веб-приложения с помощью htmx примерно применяется термин «многостраничное приложение» , но он не полностью характеризует ядро архитектуры приложения. Как вы увидите, htmx не требует замены целых страниц, и фактически приложение на основе htmx может полностью размещаться на одной странице. Мы не рекомендуем эту практику, но это возможно!
Поэтому неправильно называть веб-приложения, созданные с помощью htmx, «многостраничными приложениями». Что общего между старым подходом Web 1.0 MPA и новыми гипермедиа-ориентированными библиотечными приложениями, так это использование гипермедиа в качестве основной технологии и архитектуры.
Поэтому для описания обоих мы используем термин « приложения, управляемые гипермедиа» (HDA) .
Это поясняет, что основное различие между этими двумя подходами и подходом SPA заключается не в количестве страниц в приложении, а в базовой архитектуре системы .
Приложение, управляемое гипермедиа (HDA)
Веб-приложение, использующее гипермедиа и обмен гипермедиа в качестве основного механизма взаимодействия с сервером.
Итак, как выглядит HDA вблизи?
Давайте посмотрим на реализацию простой кнопки на основе JavaScript, представленной выше, на базе HTML:
выдает
GETзапрос на/contacts/1, заменяяcontact-ui.
Как и в случае с кнопкой с поддержкой JavaScript, эта кнопка снабжена некоторыми атрибутами. Однако в данном случае у нас нет каких-либо (явных) сценариев JavaScript.
Вместо этого у нас есть декларативные атрибуты, очень похожие hrefна атрибут тегов привязки и actionатрибут тегов формы. Атрибут hx-getсообщает htmx: «Когда пользователь нажимает эту кнопку, выдайте GETзапрос на /contacts/1». Атрибут hx-targetсообщает htmx: «Когда ответ вернется, возьмите полученный HTML-код и поместите его в элемент с идентификатором contact-ui».
Здесь мы подходим к сути htmx и тому, как он позволяет создавать приложения, управляемые гипермедиа:
Ожидается, что HTTP-ответ от сервера будет в формате HTML, а не JSON .
Ответ HTTP на этот запрос, управляемый htmx, может выглядеть примерно так:
Этот небольшой фрагмент HTML будет помещен в элемент DOM с идентификатором contact-ui.
Таким образом, эта кнопка на базе htmx обменивается гипермедиа с сервером, точно так же, как это может делать тег привязки или форма, и, таким образом, взаимодействие по-прежнему использует базовую гипермедийную модель Интернета. Htmx добавляет функциональность этой кнопке (через JavaScript), но эта функциональность дополняет HTML как гипермедиа. Htmx расширяет гипермедийную систему Интернета, а не заменяет эту гипермедийную систему совершенно другой архитектурой.
Несмотря на внешнее сходство друг с другом, оказывается, что эта кнопка на базе HTML и кнопка на основе JavaScript используют совершенно разные системные архитектуры и, следовательно, подходы к веб-разработке.
По мере того как в этой книге мы будем рассматривать создание приложения, управляемого гипермедиа, различия между этими двумя подходами будут становиться все более и более очевидными.
Когда следует использовать гипермедиа?
Гипермедиа часто, хотя и не всегда , является отличным выбором для веб-приложения.
Возможно, вы создаете веб-сайт или приложение, которое просто не требует большого взаимодействия с пользователем. Таких полезных веб-приложений много, и в этом нет ничего постыдного! Такие приложения, как Amazon, eBay, любое количество новостных сайтов, торговых сайтов, досок объявлений и т. д., чтобы быть эффективными, не нуждаются в большом количестве интерактивности: они в основном состоят из текста и изображений, а именно для этого и был разработан Интернет.
Возможно, ваше приложение добавляет большую часть своей ценности на стороне сервера за счет координации пользователей или применения сложного анализа данных и последующего представления их пользователю. Возможно, ваше приложение повышает ценность, просто работая с хорошо спроектированной базой данных и выполняя простые операции «Создать-Чтение-Обновление-Удалить» (CRUD). Опять же, в этом нет ничего постыдного!
В любом из этих случаев использование подхода с использованием гипермедиа, вероятно, будет отличным выбором: потребности в интерактивности этих приложений не столь значительны, и большая часть ценности этих приложений сосредоточена на стороне сервера, а не на стороне клиента.
Все эти приложения поддерживают то, что Рой Филдинг назвал «крупномасштабной передачей гипермедийных данных»: вы можете просто использовать теги привязки и формы с ответами, которые возвращают целые HTML-документы из запросов, и все будет работать нормально. Это именно то, для чего был создан Интернет!
Приняв для этих приложений подход гипермедиа, вы избавите себя от огромного количества сложностей на стороне клиента, которые возникают при использовании подхода одностраничного приложения: нет необходимости в маршрутизации на стороне клиента, для управления моделью на стороне клиента, для ручное подключение логики JavaScript и т. д. Кнопка «Назад» будет «просто работать». Глубокие ссылки «просто сработают». Вы сможете сосредоточить свои усилия на своем сервере, где ваше приложение действительно приносит пользу.
И, наложив на этот подход htmx или другую библиотеку, ориентированную на гипермедиа, вы можете решить многие проблемы с удобством использования, которые возникают в обычном HTML, и воспользоваться преимуществами более детальной передачи гипермедиа. Это открывает целый ряд новых пользовательских интерфейсов и возможностей, значительно расширяя набор приложений, которые можно создавать с использованием гипермедиа .
Но об этом позже.
Когда не следует использовать гипермедиа?
А что насчет того, что не всегда ? Когда гипермедиа не подойдет для приложения?
Одним из примеров, который сразу приходит на ум, является онлайн-приложение для работы с электронными таблицами. В случае с электронной таблицей обновление одной ячейки может повлечь за собой большое количество каскадных изменений, которые необходимо внести по всему листу. Хуже того, это может происходить при каждом нажатии клавиши .
В этом случае мы имеем очень динамичный пользовательский интерфейс без четких границ относительно того, что может потребоваться обновить с учетом конкретного изменения. Внедрение обратного обхода сервера в стиле гипермедиа при каждом изменении ячейки сильно снизит производительность.
Это просто не та ситуация, в которой можно использовать подход «крупномасштабной передачи гипермедийных данных» в Интернете. Для такого приложения мы, безусловно, рекомендуем рассмотреть возможность использования сложного подхода на клиентском JavaScript.
Однако даже в случае с онлайн-таблицей есть области, где подход гипермедиа может помочь.
Приложение для работы с электронными таблицами, вероятно, также имеет страницу настроек. И, возможно, эта страница настроек подходит для подхода гипермедиа. Если это просто набор относительно простых форм, которые необходимо сохранить на сервере, велика вероятность, что гипермедиа действительно отлично подойдет для этой части приложения.
И, приняв гипермедиа для этой части вашего приложения, вы сможете значительно упростить эту часть приложения. Тогда вы сможете сэкономить большую часть бюджета сложности вашего приложения на основной, сложной логике электронных таблиц, сохраняя простые вещи простыми.
Зачем тратить всю сложность, связанную с тяжелым фреймворком JavaScript, на такую простую вещь, как страница настроек?
Бюджет сложности
Любой программный проект имеет бюджет сложности, явный или нет: существует только такая сложность, которую может вынести данная команда разработчиков, и каждая новая функция и выбор реализации добавляют, по крайней мере, немного больше к общей сложности системы.
Что особенно неприятно в сложности, так это то, что она имеет тенденцию расти в геометрической прогрессии: однажды вы можете держать всю систему в голове и понимать последствия конкретного изменения, а неделю спустя вся система кажется неразрешимой. Хуже того, попытки контролировать сложность, такие как введение абстракций или инфраструктуры для управления сложностью, часто в конечном итоге усложняют ситуацию. Действительно, задача хорошего инженера-программиста — держать сложность под контролем.
Надежный способ снизить сложность также и самый трудный: сказать «нет». Отказываться от запросов на новые функции — это искусство, и если вы научитесь делать это хорошо, заставляя людей чувствовать, что они сказали «нет», вы далеко пойдете.
К сожалению, это не всегда возможно: некоторые функции придется создавать. В этот момент возникает вопрос: «Какая самая простая вещь может сработать?» Понимание возможностей, доступных в подходе гипермедиа, даст вам еще один инструмент в вашем наборе «самых простых вещей».
Гипермедиа: сложная современная системная архитектура
В кругах веб-разработчиков гипермедиа часто рассматривается как старая и устаревшая технология, возможно, полезная для статических веб-сайтов, но определенно не являющаяся реалистичным выбором для современных, сложных веб-приложений.
Серьезно? Утверждаем ли мы, что с его помощью можно создавать современные веб-приложения?
Да серьезно.
Вопреки распространенному мнению, гипермедиа представляет собой инновационную и современную системную архитектуру для создания приложений, в некотором смысле более современную , чем преобладающие подходы к одностраничным приложениям. В оставшейся части книги мы познакомим вас с основными практическими концепциями гипермедиа, а затем продемонстрируем, как именно вы можете использовать преимущества этой системной архитектуры в своем собственном программном обеспечении.
В следующих главах вы получите четкое представление обо всех преимуществах и методах, которые дает этот подход. Мы надеемся, что вы также увлечетесь этим, как и мы.
HTML-примечания: <div> Суп
Самый известный вид беспорядочного HTML — это <div>суп.
Когда разработчики прибегают к использованию общих элементов <div>и <span>вместо более значимых тегов, мы либо ухудшаем качество наших веб-сайтов, либо создаем себе больше работы — возможно, и то, и другое.
Например, вместо добавления кнопки с использованием выделенного <button>элемента к <div>элементу может быть clickдобавлен прослушиватель событий.
С этой кнопкой есть две основные проблемы:
На нем нет фокусировки — клавиша Tab не приведет вас к нему.
Вспомогательные инструменты не могут определить, что это кнопка.
Да, мы можем это исправить, добавив role="button"`и tabindex="0":
Это простые исправления, но о них следует помнить . Из исходного кода HTML также неочевидно, что это кнопка, что затрудняет чтение источника и затрудняет обнаружение отсутствия этих атрибутов. Исходный код страниц с div-супом сложно редактировать и отлаживать.
Чтобы избежать супа с элементами div, ознакомьтесь со спецификацией HTML доступных тегов и рассматривайте каждый тег как еще один инструмент в своем наборе инструментов. Там могут быть вещи, которые вы раньше не помните! (С учетом того, что в настоящее время в спецификации определены 113 элементов, это скорее сарай для инструментов ).
Конечно, не каждый шаблон пользовательского интерфейса имеет назначенный элемент HTML. Нам часто приходится составлять элементы и дополнять их атрибутами. Однако прежде чем вы это сделаете, покопайтесь в ящике с инструментами HTML. Иногда вы можете быть удивлены тем, сколько всего доступно.
Last updated
