HTTP, Ajax и jQuery

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

Однако с явлением Web 2.0 (каким бы одиозным этот термин ни был) многие умные люди все больше и больше находят применение потенциалу HTTP. RSS, Ajax, JSON, Atompub — все они так или иначе использует HTTP как транспорт, по пути затрагивая кеширование, авторизацию и "content negotiation" (есть уже русский термин?).

Этот самый "content negotiation" недавно нашел применение в нашем текущем проекте, и я хочу поделиться этой идейкой.

Я исповедую известный принцип "hijax", который диктует, что вся функциональность веб-приложения должна быть доступной без скриптования и ajax'а вообще — на простых формах и ссылках. Ajax на приложение навешивается уже потом, подменяя где нужно onclick'и и onsubmit'ы. В разработке по такому принципу сервер должен уметь обрабатывать по сути один и тот же запрос двояко: когда он сделан браузером по-обычному и когда он запрошен через XmlHttpRequest. Разница при этом обычно только в формате выдачи.

Простейший пример из текущего проекта. Есть "кнопка" (по сути просто стилизованный <a href>), по нажатию на которой должен всплывать некий диалог. В отсутствии ajax'а никакого диалога не появляется, а ссылка просто срабатывает обычным образом, и пользователь переходит на отдельную страницу, в которой нарисовано то же самое, что было бы нарисовано в диалоге. Конечно не точно так же, а с шапкой и всякой дополнительной шушерой по бокам, но середина — та же, что в диалоге. На сервере это обрабатывается одной и той же функцией приблизительно так:

def dialog(request):
  data = { .. } # данные диалога
  if is_ajax(request):
    return render_to_response('ajax_template.html', data)
  else:
    return render_to_response('full_template.html', data)

Функция is_ajax — то, о чем я веду речь. Нужно как-то понять по виду запроса, каким способом он пришел. Обычно это решают просто дописывание к ajax-запросам, формирующимся в javascript'е, признак типа "ajax=1". И, в общем-то, оно работает:

def is_ajax(request):
  return request.GET.get('ajax') or request.POST.get('ajax')

Однако теперь мы делаем по-другому. В HTTP есть специальный заголовок — Accept — который предназначен для того, чтобы клиент запрашивал у сервера, в каком конкретно виде он хочет ответ. Выглядит это как перечисление mime-типов, которые клиент умеет понимать, и по умолчанию в браузерах туда пишется длинная строчка со всякими "text/html", "application/xhtml+xml", "image/jpeg" и т.д.

Так вот, вызывая ajax-запрос, в этот заголовок как раз и можно написать, что javascript'овый код, ожидающий ответ, хочет получить его не в виде полноценного HTML-документа, а... в каком? В каком — это в принципе личное дело клиента и сервера, и о mime-типах они могут договориться сами. Мы сейчас в текущем проекте используем такие:

Это не магические значения, просто они мне кажутся достаточно понятными и предсказуемыми, кроме последнего, который я придумал за 30 секунд :-). Но главное, что они дают отличить ajax-запросы от обычных браузерных запросов:

def is_ajax(request):
  return request.META['HTTP_ACCEPT'] in ['application/xml', 'application/javascript', 'application/html+ajax']

Я пока еще не понял, лучше ли это или хуже, чем "ajax=1". Пока что мне нравится просто сам принцип использования вещи по ее прямому назначению, ну и кроме того это выглядит гораздо моднее. Однако теоретически пользу я предположить могу. Если информация о формате передается в самой ссылке, то она навязывает и контекст ее вызова. Грубо говоря, если ссылку http://server.com/service/?ajax=1 сохранить в закладки и вызвать, то она вернет какой-нибудь XML, JSON или кусок HTML, и это будет не то, что нужно. С заголовком таких проблем не возникает, потому что там тип ответа диктуется как раз контекстом вызова.

Причем же тут jQuery? А просто у ней есть замечательный метод ajaxSetup, который позволяет в одном месте сказать, чтобы во все ajax-запросы добавлялся нужный заголовок:

$(document).ready(function () {
  $.ajaxSetup({
    beforeSend: function (request) {
      request.setRequestHeader('Accept', 'application/html+ajax');
    }
  })
});