18 Работа с протоколом HTTP

Протокол передачи гипертекста (Hypertext Transfer Protocol, HTTP) определяет, как веб-броузеры должны запрашивать документы, как они должны передавать информацию веб-серверам и как веб-серверы должны отвечать на эти запросы и передачи. Очевидно, что веб-броузеры очень много работают с протоколом HTTP. Тем не менее, как правило, сценарии не работают с протоколом HTTP, когда пользователь щелкает на ссылке, отправляет форму или вводит URL в адресной строке.

Однако JavaScript-код способен работать с протоколом HTTP. HTTP-запросы могут инициироваться, когда сценарий устанавливает значение свойства location объекта Window или вызывает метод submit() объекта Form. В обоих случаях броузер загружает в окно новую страницу. Такого рода взаимодействие с протоколом HTTP может быть вполне оправданным в веб-страницах, состоящих из нескольких фреймов, но в этой главе мы будем говорить совсем о другом. Здесь мы рассмотрим такое взаимодействие JavaScript-кода с веб-сервером, при котором веб-броузер не перезагружает содержимое окна или фрейма.

Термин Ajax описывает архитектуру веб-приложений, отличительной чертой которых является работа с протоколом HTTP.[48]

Ключевой особенностью Ajax-приложения является использование протокола HTTP для инициации обмена данными с веб-сервером без необходимости перезагружать страницу. Возможность избежать перезагрузки страницы (что было привычным на первых этапах развития Всемирной паутины) позволяет создавать веб-приложения, близкие по своему поведению к обычным приложениям. Веб-приложение может использовать технологии Ajax для передачи на сервер результатов взаимодействия с пользователем или для ускорения запуска приложения, отображая сначала простую страницу и подгружая дополнительные данные и компоненты страницы по мере необходимости.

Термин Comet описывает похожую архитектуру веб-приложений, также использующих протокол HTTP.[49]

В некотором смысле архитектура Comet является обратной по отношению к Ajax: в архитектуре Comet не клиент, а сервер инициирует взаимодействие, асинхронно отсылая сообщения клиенту. Если веб-приложению потребуется отвечать на сообщения, отправляемые сервером, оно сможет использовать приемы Ajax для отправки или запроса данных. В архитектуре Ajax клиент «вытягивает» данные с сервера. В архитектуре Comet сервер «навязывает» данные клиенту. Иногда архитектуру Comet называют «Server Push», «Ajax Push» и «HTTP Streaming».

Есть множество способов реализации архитектур Ajax и Comet, и эти базовые реализации иногда называют транспортами. Элемент <img>, например, имеет свойство src. Когда сценарий записывает в это свойство URL-адрес, инициируется HTTP-запрос GET и выполняется загрузка содержимого с этого URL-адреса. Таким образом, сценарий может отправлять информацию веб-серверу, добавляя ее в виде строки запроса в URL-адрес изображения и устанавливая свойство src элемента <img>. В ответ на этот запрос веб-сервер должен вернуть некоторое изображение, которое, например, может быть невидимым: прозрачным и размером 1x1 пиксел.[50]

Элемент <img> - не самый лучший транспорт Ajax, потому что обмен данными ведется только в одном направлении: клиент может передать данные серверу, но ответом сервера всегда будет изображение, извлечь информацию из которого на стороне клиента очень непросто. Элемент <iframe> обладает большей гибкостью. При использовании элемента <iframe> в качестве транспорта Ajax сценарий сначала добавляет в URL-адрес информацию, предназначенную для веб-сервера, а затем записывает этот URL-адрес в свойство src тега <ifгате>. Сервер создает HTML-документ, содержащий ответ на запрос, и отправляет его обратно веб-броузеру, который выводит ответ в теге <iframe>. При этом элемент <iframe> необязательно должен быть видимым для пользователя - он может быть сокрыт, например, средствами таблиц стилей CSS. Сценарий может проанализировать ответ сервера, выполнив обход документа в элементе <iframe>. Обратите внимание, что взаимодействие с документом ограничивается политикой общего происхождения, о которой рассказывается в разделе 13.6.2.

Даже изменение свойства src элемента <script> может использоваться для инициирования HTTP-запроса GET. Использование элементов <script> для работы с протоколом HTTP выглядит особенно привлекательно, потому что они не являются субъектами политики общего происхождения и могут использоваться для взаимодействий с разными серверами. Обычно при использовании транспорта Ajax на основе элемента <script> ответ сервера имеет вид данных в формате JSON (раздел 6.9), которые автоматически «декодируются», когда содержимое элемента <script> выполняется интерпретатором JavaScript. Из-за использования формата данных JSON этот транспорт Ajax получил название «JSONP».

Хотя архитектура Ajax может быть реализована поверх транспорта <iframe> или <script>, существует более простой путь. Уже достаточно давно все броузеры стали поддерживать объект XMLHttpRequest, определяющий прикладной интерфейс для работы с протоколом HTTP. Этот интерфейс обеспечивает возможность выполнять POST-запросы в дополнение к обычным GET-запросам и может возвращать ответ веб-сервера синхронно или асинхронно, в виде простого текста или в виде объекта Document. Несмотря на свое название, объект XMLHttpRequest не ограничивается использованием XML-документов - он в состоянии принимать любые текстовые документы. Прикладной интерфейс объекта XMLHttpRequest рассматривается в разделе 18.1, который занимает значительную часть главы. Большая часть примеров реализации архитектуры Ajax в этой главе в качестве транспорта использует объект XMLHttpRequest, но в разделе 18.2 также будет показано, как использовать транспорт на основе элемента <script>, так как он способен обходить ограничения политики общего происхождения.

Транспортные механизмы в архитектуре Comet сложнее, чем в архитектуре Ajax, но все они требуют установления (и восстановления, в случае необходимости) соединения с сервером со стороны клиента и обязывают сервер поддерживать соединение открытым, чтобы через него можно было отправлять асинхронные сообщения. Транспортом в архитектуре Comet может служить, например, скрытый элемент <iframe>, если сервер отправляет сообщения в виде элементов <script>, выполняемых в элементе <iframe>. Более надежный и переносимый подход к реализации архитектуры Comet заключается в том, чтобы клиент устанавливал соединение с сервером (используя Ajax-транспорт), а сервер поддерживал это соединение открытым, пока имеется необходимость отправлять сообщения. Каждый раз, когда сервер отправляет сообщение, он закрывает соединение, что позволяет гарантировать благополучное получение сообщения клиентом. После обработки сообщения клиент может сразу же установить новое соединение для будущих сообщений.

Реализация надежного и переносимого транспорта для архитектуры Comet является сложной задачей, и большинство веб-разработчиков, использующих архитектуру Comet, опираются на транспорты, реализованные в веб-фреймворках, таких как Dojo. На момент написания этих строк производители броузеров приступили к реализации положений проекта спецификации «Server-Sent Events», связанной со стандартом HTML5, которая определяет простой прикладной интерфейс для архитектуры Comet в виде объекта EventSource. Интерфейс объекта EventSource будет рассматриваться в разделе 18.3 и там же будет продемонстрирована простая его имитация на основе объекта XMLHttpRequest.

Имеется также возможность конструировать высокоуровневые протоколы взаимодействий поверх Ajax и Comet. Эти приемы организации взаимодействий типа клиент/сервер можно использовать, например, в качестве основы механизма RPC (Remote Procedure Call - вызов удаленных процедур) или системы событий типа издатель/подписчик. Однако в данной главе мы не будем рассматривать подобные высокоуровневые протоколы, а сконцентрируемся на прикладных интерфейсах поддержки архитектур Ajax и Comet.

Использование XML не является обязательным

Символ «X» в аббревиатуре «Ajax» обозначает «XML». Основной прикладной интерфейс для работы с протоколом HTTP на стороне клиента (XMLHttpRequest) также содержит название «XML» в своем имени, и, как мы узнаем далее, одно из свойств объекта XMLHttpRequest имеет имя responseXML. Вследствие этого может сложиться впечатление, что XML является важной частью работы с протоколом HTTP. Но это не так: эти имена являются историческим наследием тех дней, когда XML было модным словечком. Конечно, реализации Ajax способны работать с XML-документами, но использование формата XML является необязательным, и в действительности он редко используется не практике. Спецификация XMLHttpRequest полна несоответствий в именах, с которыми нам придется сталкиваться:

Имя объекта XMLHttpRequest было выбрано исходя из соображений совместимости с Веб, хотя каждая часть этого имени может вводить в заблуждение. Во-первых, объект поддерживает любые текстовые форматы, включая XML. Во-вторых, он может использоваться для отправки запросов по обоим протоколам, HTTP и HTTPS (некоторые реализации могут поддерживать дополнительные протоколы, помимо HTTP и HTTPS, но эти возможности не регламентируются в спецификации). Наконец, он поддерживает «запросы» («requests») в более широком смысле, - как это подразумевает использование протокола HTTP. А именно, все операции, связанные с выполнением HTTP-запросов или получением НТТР-ответов для определенных НТТР-методов.

******************************************