что такое серверная часть сайта

Клиентская и серверная веб-разработка

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

Клиентская веб-разработка

Разработчики на стороне клиента используют свои навыки программирования для создания визуально привлекательных, функциональных и полезных веб-приложений и динамических веб-сайтов. Эти программисты несут ответственность за каждую часть веб-сайта, которую пользователи видят или с которой взаимодействуют. Домашние страницы, страницы покупок, слайд-шоу — практически любая видимая функция, которая отображается в веб-браузере или требует ввода данных пользователем, попадает под эту дисциплину.

Всё это программное обеспечение работает на клиентском устройстве. Разработчики на стороне клиента также известны как программисты «переднего плана», поскольку «передняя часть» веб-страницы — это то, что получает взаимодействие с пользователем. Эти разработчики получают хорошую оплату за свою работу, зарабатывая в США в среднем 100 208 долларов в год. Конечно, заработная плата может варьироваться в зависимости от местоположения и компании.

Общие языки сценариев, используемые разработчиками интерфейса для создания клиентского кода, включают JavaScript, HTML и CSS.

Серверная веб-разработка

Чтобы понять, что делает разработчик на стороне сервера, мы должны сначала рассмотреть, как работает веб-сайт и чем он отличается от изображения или интерактивного текстового документа. Клиентская часть веб-сайта — это просто платформа для отображения и сбора информации. Сайт взаимодействует с веб-серверами, используя их для получения и отправки данных из баз данных, чтобы предоставить вам необходимые услуги.

Эти разработчики программного обеспечения проектируют, создают и обслуживают серверный код, который делает возможным такой обмен данными. Эти программисты также известны как разработчики серверной части. Они работают за кадром, следя затем, чтобы на серверах приложений всё работало должным образом. Бэкенд-программистам также очень хорошо платят, их зарплата в США составляет в среднем 117 284 долларов.

Эти программисты обычно владеют серверными языками, такими как Python, SQL, Ruby on Rails, PHP и Java.

Как стать клиентским или серверным веб-разработчиком

Технологическая отрасль необычайно целостна в своих методах найма, и они принимают во внимание гораздо больше, чем просто степень. Фактически, для выполнения многих заданий по фронтенд-разработке даже не требуется учёная степень. Для многих людей достаточно короткого пребывания в одном из многочисленных национальных учебных курсов по программированию. Курсы для начинающих по программированию — это форма профессионального и технического образования, которая учит студентов только тому, что им нужно, чтобы получить работу в сфере технологий. К тому же, эти новые программы уже зарекомендовали себя в отрасли.

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

Источник

Введение в серверную часть

Добро пожаловать на курс для начинающих по программированию серверной части сайта! В этой первой статье мы рассмотрим программирование на стороне сервера с высокого уровня, отвечая на такие вопросы, как «что это»?, «как это отличается от программирования на стороне клиента»? и «почему это так полезно»? После прочтения этой статьи вы поймёте дополнительные возможности, доступные веб-сайтам посредством программирования на стороне сервера.

Большинство крупных веб-сайтов используют программирование серверной части чтобы динамично отображать различные данные при необходимости, в основном взятые из базы данных, располагающейся на сервере и отправляемые клиенту для отображения через некоторый код (например, HTML и JavaScript).

Возможно, самая значительная польза программирования серверной части в том, что оно позволяет формировать контент веб-сайта под конкретного пользователя. Динамические сайты могут выделять контент, который более актуален в зависимости от предпочтений и привычек пользователя. Это также может упростить использование сайтов за счёт сохранения личных предпочтений и информации, например, повторного использования сохранённых данных кредитной карты для оптимизации последующих платежей.

Это также даёт возможность взаимодействовать с пользователем сайта, посылая уведомления и обновления по электронной почте или по другим каналам. Все эти возможности позволяют глубже взаимодействовать с пользователями.

В современном мире веб-разработки настоятельно рекомендуется узнать о разработке на стороне сервера.

Что такое программирование серверной части сайта?

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

Запрос включает в себя URL, определяющий затронутый ресурс, метод, определяющий требуемое действие (например, получить, удалить или опубликовать ресурс) и может включать дополнительную информацию, закодированную в параметрах URL (пары поле-значение, оправленные как строка запроса), как POST запрос (данные, отправленные методом HTTP POST) или в куки-файлах.

Веб-серверы ожидают сообщений с клиентскими запросами, обрабатывают их по прибытию и отвечают веб-браузеру при помощи ответного HTTP сообщения (HTTP-ответ). Ответ содержит строку состояния, показывающую, был ли запрос успешным или нет (например, «HTTP/1.1 200 OK» в случае успеха).

Тело успешного ответа на запрос может содержать запрашиваемые данные (например, новую HTML-страницу или изображение, и т. п.), который может отображаться через веб-браузер.

Статические сайты

Схема ниже показывает базовую архитектуру веб-сервера для статического сайта (статический сайт — это тот, который возвращает одно и то же жёстко закодированное содержимое с сервера всякий раз, когда запрашивается конкретный ресурс). Когда пользователь хочет перейти на страницу, браузер отправляет HTTP-запрос «GET» с указанием его URL.

Сервер извлекает запрошенный документ из своей файловой системы и возвращает HTTP-ответ, содержащий документ и успешный статус (обычно 200 OK). Если файл не может быть извлечён по каким-либо причинам, возвращается статус ошибки (смотри ошибки клиента и ошибки сервера).

Одинаково ли программирование серверной части и клиентской?

Динамические сайты

Динамический веб-сайт — это тот, где часть содержимого ответа генерируется динамически только при необходимости. На динамическом веб-сайте HTML-страницы обычно создаются путём вставки данных из базы данных в заполнители в HTML-шаблонах (это гораздо более эффективный способ хранения большого количества контента, чем использование статических сайтов).

Динамический сайт может возвращать разные данные для URL-адреса на основе информации, предоставленной пользователем или сохранёнными настройками, и может выполнять другие операции, как часть возврата ответа (например, отправку уведомлений).

Большая часть кода для поддержки динамического веб-сайта должна выполняться на сервере. Создание этого кода известно, как «программирование серверной части» (или иногда «программирование бэкенда»).

Схема ниже показывает простую архитектуру динамического сайта. Как и на предыдущей схеме, браузеры отправляют HTTP-запросы на сервер, затем сервер обрабатывает запросы и возвращает соответствующие HTTP-ответы.

Запросы статических ресурсов обрабатываются так же, как и для статических сайтов (статические ресурсы — это любые файлы, которые не меняются, обычно это: CSS, JavaScript, изображения, предварительно созданные PDF-файлы и прочее).

Запросы динамических данных отправляются (2) в код серверной части (показано на диаграмме как Веб-приложение). Для «динамических запросов» сервер интерпретирует запрос, читает необходимую информацию из базы данных (3), комбинирует извлечённые данные с шаблонами HTML и возвращает ответ, содержащий сгенерированный HTML (5, 6).

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

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

Код клиентской части написан с использованием HTML, CSS и JavaScript — он запускается в веб-браузере и практически не имеет доступа к базовой операционной системе (включая ограниченный доступ к файловой системе).

Веб-разработчики не могут контролировать, какой браузер может использовать каждый пользователь для просмотра веб-сайта — браузеры обеспечивают противоречивые уровни совместимости с функциями кода на стороне клиента, и одной из задач программирования на стороне клиента является изящная обработка различий в поддержке браузера.

Код серверной части может быть написан на любом количестве языков программирования — примеры популярных языков серверной части включают в себя PHP, Python, Ruby, C# и NodeJS (JavaScript). Код серверной части имеет полный доступ к операционной системе сервера, и разработчик может выбрать какой язык программирования (и какую версию) он хотел бы использовать.

Разработчики обычно пишут свой код, используя веб-фреймворки. Веб-фреймворки — это наборы функций, объектов, правил и других конструкций кода, предназначенных для решения общих проблем, ускорения разработки и упрощения различных типов задач, стоящих в конкретной области.

И снова, поскольку и клиентская и серверная части используют фреймворки, области очень разные и, следовательно, фреймворки тоже разные. Фреймворки клиентской части упрощают вёрстку и представление данных, тогда как фреймворки серверной части обеспечивают много «обычной» функциональности веб-сервера, которую вы, возможно, в противном случае, должны были осуществлять самостоятельно (например, поддержка сессий, поддержка пользователей и аутентификация, простой доступ к базе данных, шаблонам библиотек и т. д.).

На заметку: Фреймворки клиентской части часто используются для ускорения написания кода клиентской части, но вы также можете решить писать весь код руками; на самом деле, написание кода руками может быть более быстрым и эффективным, если вам нужен небольшой простой веб-сайт UI.

И, наоборот, вы практически никогда не посмотрите в сторону написания кода серверной части веб-приложения без фреймворка: осуществление жизненно важной функции, такой как HTTP сервер действительно сложно сделать с нуля, скажем, на Python, но веб-фреймворки для Python, такие как Django, обеспечивают это из коробки наряду с другими полезными инструментами.

Что можно сделать в серверной части?

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

Компании, такие как Amazon, используют программирование серверной части для построения исследовательских результатов для товаров, формирования целевого предложения, основанного на предпочтениях клиента и предыдущих покупках, упрощения заказов и т. д. Банки используют программирование серверной части, чтобы хранить учётную информацию и позволять только авторизованным пользователям просматривать и совершать транзакции. Другие сервисы, такие как Facebook, Twitter, Instagram и Wikipedia используют бэкенд, чтобы выделять, распространять и контролировать доступ к интересному контенту.

Некоторые типичные применения и выгоды бэкенда перечислены ниже. Вы заметите, что есть некоторое пересечение!

Эффективное хранение и доставка информации

Представьте, сколько товаров доступно на Amazon, и представьте, сколько постов было написано на Facebook? Создание статической страницы для каждого товара или поста было бы абсолютно неэффективным.

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

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

Из-за того, что информация находится в базе данных, её также можно легко передать и обновить через другие бизнес системы (например, отслеживание).

На заметку: вам не нужно сильно напрягать своё воображение, чтобы увидеть достоинства кода серверной части для эффективного хранения и передачи информации:

Для обычного поиска (например, «рыба») вы можете увидеть буквально миллионы найденных значений. Использование базы данных позволяет им храниться и передаваться эффективно, и это позволяет контролировать представление информации всего в одном месте.

Настраиваемый пользовательский опыт взаимодействия

Серверы могут хранить и использовать информацию о клиентах чтобы поставлять удобный и сделанный индивидуально пользовательский опыт взаимодействия. Например, многие сайты хранят данные кредитных карт, чтобы не нужно было вводить их повторно. Сайты, наподобие Google Maps, могут использовать сохранённое и текущее местоположение для предоставления информации о маршруте, а также историю поиска или путешествий для выделения местных предприятий в результатах поиска.

Более глубокий анализ привычек пользователя может быть использован для прогнозирования их интересов и дальнейших настроек ответов и уведомлений, например, предоставление списка ранее посещённых популярных мест, которые вы, возможно, захотите найти на карте.

На заметку: Google Maps сохраняет вашу историю поиска и посещений. Часто посещаемые или часто вводимые в поиск локации выделяются больше, чем остальные.

Результаты поиска Google оптимизируются на основе предыдущего поиска.

Стечение обстоятельств? Нет!

Контролируемый доступ к контенту

Программирование серверной части позволяет сайтам ограничивать доступ авторизованным пользователям и предоставлять только ту информацию, которую пользователю разрешено видеть.

На заметку: Рассмотрим другие реальные примеры, где доступ к контенту контролируется. Например, что вы можете увидеть, если зайдёте на сайт вашего банка? Авторизуйтесь через вашу учётную запись, и какую дополнительную информацию вы можете просматривать и редактировать? Что за информацию вы можете увидеть, которую может редактировать только банк?

Хранение информации о сессии/состоянии

Программирование серверной части позволяет разработчикам использовать сессии – изначально это механизм, позволяющий серверу хранить информацию о текущем пользователе сайта и отправлять разные ответы, основанные на этой информации.

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

На заметку: Посетите новостной сайт, у которого есть подписка и откройте ветку тегов (например, The Age). Продолжайте посещать сайт в течение нескольких часов/дней. В итоге вас начнёт перенаправлять на страницы, объясняющие, как оформить платную подписку, а сами статьи станут вам недоступны. Эта информация является примером сессии, сохранённой в куки-файлах.

Уведомления и средства связи

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

Вот несколько примеров:

На заметку: Самый распространённый вид уведомлений – это «подтверждение регистрации». Возьмите почти любой интересующий вас крупный сайт (Google, Amazon, Instagram и т. п.) и создайте новую учётную запись, используя ваш адрес электронной почты. Вскоре вы получите письмо, подтверждающее факт вашей регистрации или содержащее информацию о необходимости активировать вашу учётную запись.

Анализ данных

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

Например, и Amazon, и Google рекламируют товары на основании предыдущих поисков (и покупок).

На заметку: Если вы пользуетесь Facebook, зайдите на вашу стену и посмотрите на ряд постов. Заметьте, что некоторые посты не идут по порядку: в частности, посты с большим количеством «лайков» часто находятся выше по списку, чем остальные. Также взгляните на рекламу, которую вам показывают, вы вероятно увидите рекламу товаров, которые искали на других сайтах. Алгоритм Facebook для выделения контента и рекламы может казаться мистикой, но очевидно, что он зависит от ваших лайков и запросов поиска!

Подведение итогов

Поздравляем, вы дошли до конца первой статьи о программировании серверной части.

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

Наконец, вы должны понимать, что код серверной части может быть написан на разных языках программирования, и что вам следует использовать веб-фреймворк для упрощения процесса написания кода.

В следующей статье мы поможем вам выбрать лучший фреймворк для вашего первого сайта; затем мы изучим несколько основных взаимодействий с клиентской частью более подробно.

Источник

Архитектура взаимодействия клиентской и серверной частей Web приложения

Хотел рассказать, как я вижу устройство архитектуры взаимодействия серверной и клиентской частей. И хотел бы узнать спросить хабровчан, чем плоха или хорошо такая архитектура.

Клиентская структура

Даже устаревшие браузеры предлагают нам набор возможностей для создания полнофункциональных интерактивных Web-приложений. А благодаря таким библиотекам как jQuery, которые предлагают не скромные кроссбраузерные и мультиплатформенные решения, разработка клиентских частей ускоряется во много раз. Чем веб-мастера и пользуются на полную катушку, используя при этом самые разнообразные интерфейсы для взаимодействия серверной и клиентской частей.

Конечно, многие из нас начинали изучение jquery с циклов статей для новичков, внедряя на свои сайты и динамическую подгрузку содержимого, и проверку форм на серверной части, и многое другое.

Со временем размер кода вырос: в проекте появилось множество обработчиков ответов от серверной части. Где-то запрашивается целая страница и из нее вырывается кусок контента, где-то идет запрос на различные файлы, где-то ожидается JSON, а кое-где XML. Все это надо прибирать, чтобы и кода было меньше, и работал он быстрее, и работать с ним было проще.

Во-вторых, надо сократить количество точек входа для AJAX запросов. Если запросы отправлялись и на index.php, и на request.pl, и на upload.xml, то это огромный объем работы, и нередко бывает, что сделать это невозможно не переписав заново всю серверную часть. Хотя это надо сделать, если хочется быстро и просто расширять клиентскую часть. Как и у всех правил, у этого есть исключения. О них чуть ниже.

В третьих, самое главное: необходимо унифицировать обработчик ответа.

Например, у нас в проекте все ajax-запросы идут только на файл ajax.php. Он всегда возвращает некоторые данные в виде XML, довольно просто структурированные.

Единый обработчик ответа парсит XML и раскладывает по полочкам:

• Список js-файлов, которые необходимы для обработки ответа.
• Сallback-функции, которые необходимо запустить, и какие аргументы в эти функции надо передать.
• Куски HTML-кода, которые будут применены в вышеуказанных функциях.
• Список css файлов, которые нужны для украшения html кода.

Когда все разложено, загружаем недостающие js-файлы. Возможно, один или несколько запрошенных скриптов уже были загружены ранее загружены, поэтому сначала проверяем это. Методы проверки зависят от общей архитектуры javascript кода.

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

Когда все скрипты загружены, запускаем callback-функции.

Надо обратить внимание, что для ускорения загрузки все js файлы загружаются асинхронно, и соответственно здесь может возникнуть проблема с запуском callback-функций. Ведь они могут быть в этих файлах.
Решением этой проблемы может стать создание зависимостей функций от js файлов. Это, в свою очередь, порождает проблемы контроля этих зависимостей программистом и передаче их вместе с ответом клиентской стороне.
Второе решение — это дождаться загрузки абсолютно всех запрошенных файлов и уже потом начать выполнения функций.
Как сделать это красиво, можно послушать в этом чудесном подкасте habrahabr.ru/blogs/hpodcasts/138522

Я для своих проектов выбрал самое простое решение — второе. Я исходил и того, что подгрузка необходимых js файлов нужна крайне редко, потому что все скрипты объединяются на серверной стороне в пакеты. И обычно пакет заранее содержит все необходимые callback`и. А если подгрузка файлов и будет нужна, то потребует максимум один-два файла, что не сильно задержит обработку ответа.

Напомню, что пользователь к этому моменту все еще не видит изменений на экране. Что ж, покажем ему их — начнем выполнять функции. Главное, что стоит учитывать — все функции-обработчики ответа должны быть независимыми друг от друга. Они могут зависеть от одного крупного компонента (например, функций ядра проекта), но не должны друг от друга. Это позволит перемещать и интегрировать callback`и в другие части проекта без каких-либо особых заморочек. Например, выводить всплывающие окна с сообщениями об ошибках может потребоваться на всех страницах.

Функции выполнены, пользователь работает дальше.

Обработка запросов сервером

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

У нас все запросы не только посылаются на один файл, но и все данные в нем посылаются методом POST. На серверной стороне ожидается некоторый POST-параметр «action». Значение этого параметра определяет то, какой модуль сайта должен отработать. Сами пары с ожидаемыми значениями и именами модулей записаны в конфигурационном файле. Если в конфигурации есть соответствующий модуль – он запускается, если нет — запускается дефолтный модуль, который настроен на возврат сообщения об ошибке.
Также, мы можем записать в серверный лог все параметры запроса. Анализ лога потом позволит быстро отследить и исправить ошибку. Или во время выполнения скрипта забанить IP пользователя на минут 15 за перебор значений, если есть уверенность, что ошибок в нашем приложении нет. Но это уже крайность.

Обработка ошибочных запросов на клиентской стороне

Нельзя забывать про обработку сорвавшихся запросов, например по таймауту или внезапному отключению пользователя от сети.

Кэширование

Вернемся к вопросу про точки входа. C точки зрения написания красивого кода, указывание только одного адреса для точки входа не совсем правильное решение. Это ни в коем случае не противоречит моему второму совету. Попробую разобрать все стороны данного вопроса.

Как можно было бы сделать все красиво? — Отправлять запросы на определенные адреса. Например, ajax.php?action=feedback или ajax.example.com/feedback. Это избавило бы запрос от лишнего мусора. Когда определен модуль, который будет обрабатывать данные, эта информация ему уже не нужна. Мухи отдельно, котлеты отдельно. Красиво? Красиво.

Если POST параметров в запросе вообще нет, то это хорошая возможность использовать возможности кэширования на промежуточных проксях или кэш браузера.
В рекомендациях от Google для Web-мастеров сказано, что отсутствие GET-параметров в http-запросе провоцирует прокси-сервера использовать кэш. Поэтому запрос без POST и GET параметров, например ajax.mysite.com/footer, будет идеальным для добавления его в кэш прокси сервером. Из дополнительных плюсов отмечу, что если ответ будет от прокси сервера, то это немного разгрузит и наш сервер.
Когда это вообще может понадобится? Когда мы подгружаем части страницы через ajax. При этом они являются неизменными в течение долгого времени.

Но использовать ajax-запрос без GET или POST параметров не стоит, раз существует вероятность получения не актуальных данных.
Предположим, что у нас чат и мы не используем веб-сокеты. Каждую секунду долбимся на сервер, чтобы посмотреть новые сообщения. Пользователь попался за каким-то прокси сервером. Первый запрос пройдет удачно и вернет, что сообщений нет. На все последующие запросы, прокси сервер будет возвращать первоначальный ответ. А это нарушит всю работу чата. Проблем поможет избежать добавление параметра в запрос. Что, в свою очередь, создаст тот самый мусор, которого мы так старались избежать.

В вопросах кэширования каждый раз нужно подходить индивидуально и использовать то, что необходимо для проекта.

Изобретая велосипед

В нашем проекте данные в запросе отправляется только методом POST, потому что механизм кэширования у нас заложен в том самом едином интерфейсе отправки ajax-запросов. По умолчанию абсолютно каждый запрос и ответ на него запоминается на 3600 секунд. При последующем аналогичном запросе отработает кэш, возьмет из коробочки ответ и запустит сразу все механизмы по его анализу, без отправки непосредственно запроса на сервер. Ведь мы уже уверены, что все стили и скрипты уже на месте.
Если запоминать пару запрос-ответ не нужно или надо просто уменьшить время жизни кэша, то серверная сторона сообщает об этом в первоначальном ответе, изменяя время кэша на 0 или другое количество секунд.

Почему только POST, а не совмещенный вариант? Так проще сравнивать запросы.
Данные отправляемые через функцию ajax в jQuery, это js-объект.
Запрошенные данные довольно быстро сравниваются перебором с объектами в кэше, конечно, если у клиента современный браузер. Если браузер старый, приходится принудительно отключать кэш.

В итоге

В итоге мы получаем устойчиво работающую связку клиентской и серверной частей. И эта связка позволяет нам создавать безопасные и простые для дальнейшего расширения Web приложения.

Пост написан во имя спасения наносекунд и множества нервных клеток программистов, создающих свои прекрасные творения.

Источник