AJAX, первоначально определенный в статье, написанной Джесси Джеймсом Гарреттом в феврале 2005 года, означал «Асинхронный JavaScript + XML». Несмотря на то, что это очень интересное определение, оно не объясняет всей его сути. AJAX – это вторичный путь связи из среды JavaScript в веб-браузере пользователя с вашим сервером. Использование AJAX вызывает изменения в типичном потоке страниц, который вы видите в обычном веб-приложении. С AJAX запросы теперь происходят чаще и могут привести к меньшим откликам не-HTML данных.
Суть AJAX
Чтобы получить истинное представление о том, что это на самом деле означает, давайте посмотрим на коммуникационный поток обычного веб-приложения. Он состоит из двух типов сетевой активности: инициируемые пользователем запросы протокола HTTP (HTTP) (ввод URL-адреса или переход по ссылке) и ответы с сервера. В веб-приложениях большинство пользовательских запросов содержат данные из формы, а ответы сервера генерируются на лету с помощью языка программирования, такого как PHP или Java. В обычной модели веб-приложения пользователь всегда генерирует запросы, поэтому высокая частота запросов на странице может возникнуть вследствие большого количества кликов по ней. Но, как правило, она держится на низком уровне, со случайным интервалом времени между каждым запросом.
Веб-приложение AJAX берет нормальный коммуникационный поток веб-приложения и добавляет новый тип запроса. Для вашего сервера это выглядит как обычный запрос страницы (хотя в большинстве случаев его данные будут в другом формате), но не для веб-браузера. Это запрос, который не требует перезагрузки страницы после завершения, и он не должен быть инициирован пользователем напрямую. Во многих случаях эти AJAX-запросы будут небольшими и могут, например, принимать форму запроса для проверки поля или предварительной загрузки некоторых данных. Однако запросы также могут быть большими. Например, они могут отправить форму через JavaScript или вернуть язык гипертекстовой разметки (HTML), который будет использоваться для замены содержимого на части страницы. Если вы посмотрите на запросы AJAX-приложения с течением времени и сравните их с обычным веб-приложением, вы сможете определить где какие, просто сравнив частоту их запросов.
Изменение частоты может сильно повлиять на вашу способность размещать веб-приложение AJAX. Теперь ваши серверы должны иметь возможность обрабатывать гораздо более многочисленные запросы от одного и того же числа пользователей. Это может быть особенно сложно, если каждый AJAX-запрос требует столько же обработки, сколько и обычная загрузка страницы.
Технологии AJAX
Если вы поищите в интернете материалы по AJAX, вы, вероятно, заметите большое количество элементов, появляющихся под именем AJAX, которые не соответствуют нашему определению. В большинстве случаев эти библиотеки предоставляют соответствующую функциональность, необходимую для завершения вашего AJAX-приложения. Глядя на эти библиотеки и методы, мы разделяем их на три группы:
- Те, которые непосредственно используются в AJAX;
- Те, кто тесно связаны с AJAX;
- Те, которые являются частью остального мира RIA.
Большинство технологий, непосредственно связанных с AJAX, – это те, которые составляют «асинхронную» и «XML» части аббревиатуры AJAX. Это библиотеки и методы, обеспечивающие коммуникационный уровень и способы кодирования данных, которые перемещаются по нему. Во многих случаях это объект XMLHttpRequest, но IFrames также популярны, и cookie или встроенные ActiveX/Java являются еще одной возможностью. "X" в AJAX – это метод, используемый при кодировании данных, и это область с огромным количеством возможностей. Данные могут быть переданы в виде простого текста, HTML, XML или любого другого типа формата, который может быть удобен для определенной ситуации.
XML чрезвычайно популярен как формат данных, потому что он поддерживается многими языками и потому что с ним легко описать произвольные типы данных. XML постоянно используется для упрощения механизмов удаленного вызова процедур (RPC), но его также можно использовать для непосредственного описания передаваемых данных. RPC позволяет напрямую сопоставлять типы JavaScript с типами данных сервера (PHP, Java и т. д.) и наоборот. XML уже использовался для этой цели, поэтому он включает в себя множество стандартизированных форматов, таких как те, что используются в SOAP, XML-RPC и WDDX. Он также может включать пользовательский формат XML, созданный для конкретной реализации AJAX.
Удаленный скриптинг
В основе улучшения юзабилити веб-приложения лежит устранение узких мест связи между пользователем и веб-приложением. Использование большинства веб-приложений означает затрачивание массы времени на экранах поиска, просматривая идентификатор элемента или ожидая перезагрузки страницы. Самый простой способ решить эти проблемы – поговорить с вашим сервером из JavaScript и пропустить перезагрузку страницы.
Эксперименты по этому новому пути начались в 2001 году; в то время это называлось удаленным скриптингом. Использовалось несколько разных подходов, но большинство из них оказались подходами в стиле RPC, использующими JavaScript-объект XMLHttpRequest для отправки данных. Этот же подход сегодня используется во многих реализациях AJAX, так почему же его распространение заняло так много времени? Возможно, большинству разработчиков было неудобно использовать JavaScript. Возможно также, что на вопрос о том, почему используется определенная веб-технология или нет, казалось невозможным ответить. Тем не менее, это был лишь тот случай, когда потребовалось много времени, чтобы достичь критической массы принятия.
Обзор XMLHttpRequest
Изначально Microsoft разработала XMLHttpRequest, чтобы позволить Internet Explorer (IE) загружать XML-документы из JavaScript. Несмотря на то, что в названии есть XML, XMLHttpRequest действительно является универсальным HTTP-клиентом для JavaScript. С его помощью JavaScript может выполнять запросы GET и POST HTTP (для запросов POST данные могут отправляться на сервер в выбранном вами формате). Основные ограничения для XMLHttpRequest связаны с изолированной программной средой безопасности браузера. Он может делать только HTTP(S) запросы (например, URL файлов не будут работать), и он может делать запросы только к тому же домену, что и текущая загруженная страница.
Ограничения безопасности XMLHttpRequest действительно ограничивают способы его использования, но компромисс с дополнительной безопасностью вполне оправдан. Большинство атак на приложения JavaScript сосредоточены вокруг внедрения вредоносного кода на веб-страницу. Если бы XMLHttpRequest разрешал запросы к любому веб-сайту, он стал бы основным игроком в этих атаках. Песочница безопасности уменьшает эти потенциальные проблемы. Кроме того, это упрощает модель программирования, поскольку код JavaScript может неявно доверять любым данным, которые он загружает из XMLHttpRequest. Он может доверять данным, потому что новые данные так же безопасны, как и страница, которая загрузила начальную страницу.
Несмотря на то, что XMLHttpRequest предоставляет только небольшой API и всего несколько методов и свойств, он имеет свои различия между браузерами. Эти различия в основном связаны с обработкой событий и созданием объектов (в IE XMLHttpRequest на самом деле является объектом ActiveX), поэтому их не сложно обойти. В следующем обзоре API XMLHttpRequest используется синтаксис Mozilla для создания экземпляра XMLHttpRequest. Если вы хотите запустить примеры в IE, вам необходимо заменить новый XMLHttpRequest(); с любым новым ActiveXObject ("MSXML2.XMLHTTP.3.0"); или метод полного кросс-браузерного создания.
XMLHttpRequest::Open()
Метод open используется для установки типа запроса (GET, POST, PUT или PROPFIND), URL запрашиваемой страницы и будет ли вызов асинхронным. Имя пользователя и пароль для HTTP-аутентификации также могут быть переданы по желанию. URL-адрес может быть относительным путем (например, page.html) или полным путем, включающим адрес сервера. Подпись основного метода:
open(type,url,isAsync,username,password)
В среде JavaScript существуют ограничения безопасности. Эти ограничения безопасности приводят к тому, что метод open генерирует исключение, если URL принадлежит другому домену, чем текущая страница. В следующем примере используется open для настройки синхронного GET-запроса к index.html:
XMLHttpRequest::Send()
Метод send устанавливает соединение с URL, указанным в open. Если запрос асинхронный, вызов вернет его немедленно; в противном случае вызов заблокирует дальнейшее выполнение, пока страница не будет загружена. Если тип запроса POST, полезная нагрузка будет отправлена как тело запроса, отправляемого на сервер. Подпись метода:
send(payload)
Когда вы делаете запрос POST, вам нужно установить заголовок Content-type. Таким образом, сервер знает, что делать с загруженным контентом. Чтобы имитировать отправку формы с использованием HTTP POST, вы устанавливаете тип контента на application/x-www-form-urlencoded. URLencoded данные – это тот же формат, который вы видите в URL-адресе после "?". Вы можете увидеть пример этих закодированных данных, создав форму и установив для нее метод GET. В следующем примере показан синхронный POST-запрос к index.php, который отправляет полезную нагрузку с кодом URL. Если index.php содержит <?Php var_dump ($ _ POST);?>, вы можете увидеть отправленные данные, переведенные, как будто это обычная форма в предупреждении:
XMLHttpRequest::setRequestHeader()
Существует много разных случаев, когда установка заголовка запроса может быть полезной. Наиболее распространенное использование setRequestHeader() – установить тип контента, потому что большинство веб-приложений уже знают, как работать с определенными типами, такими как URLencoded. Сигнатура метода setRequestHeader принимает два параметра: устанавливаемый заголовок и его значение:
setRequestHeader(header,value)
Поскольку запросы, отправленные с использованием XMLHttpRequest, отправляют те же стандартные заголовки, включая заголовки cookie и заголовки HTTP-аутентификации, что и обычный запрос браузера, имя заголовка обычно будет именем заголовка HTTP, который вы хотите переопределить. В дополнение к переопределению заголовков по умолчанию, setRequestHeader полезен для установки пользовательских заголовков, специфичных для приложения.