Принципы взаимодействия клиента и сервера в вебе. HTTP

Принципы взаимодействия клиента и сервера в вебе

Веб работает в архитектуре клиент‑сервер. С одной стороны веб‑сервер, с другой — клиент: браузер, программа или даже другой веб‑сервер. Клиент и веб‑сервер понимают друг друга с помощью протокола HTTP (Hypertext Transfer Protocol) — специального языка и набора правил. Поэтому в адресной строке мы видим используемый протокол — http:// или его безопасную зашифрованную версию https://

Принципы взаимодействия клиента и сервера в вебе

Когда мы открываем сайт в браузере, браузер посылает запрос, буквально пишет серверу «Дай мне страницу index.html» или «Дай мне cat.jpg»:

GET /index.html HTTP/1.1
Host: example.com
User-Agent: Chrome

Здесь GET — это метод запроса, /index.html — путь к тому, что мы запрашиваем, а HTTP/1.1 — версия протокола. Дальше идут заголовки — набор строк в формате ключ: значение. Это дополнительная информация, которая помогает серверу узнать больше о клиенте и его запросе.

Сервер на это отвечает «Вот страница, держи» или «Вот cat.jpg»:

HTTP/1.1 200 OK
Content-Type: text/html

<!DOCTYPE html>
<html>
  ...
</html>

200 — это код, статус ответа. Браузеры опираются на эти коды, чтобы понять ответ сервера и решить, что делать дальше:

Коды в интервале от 200 до 299 — это ок, всё хорошо, можно показать пользователю.

Коды в интервале от 300 до 399 — это перенаправления, редиректы, указание браузеру перейти куда‑то ещё.

Коды в интервале от 400 до 499 — это ошибки на стороне клиента. Например, 404 Not Found — указанной страницы нет.

Коды в интервале от 500 до 599 — ошибки сервера. Например, 500 Internal Server Error — внутренняя ошибка сервера, проблема в коде.

Браузер и веб‑сервер обмениваются запросами и ответами под капотом, пользователь не видит этих сообщений. Но за диалогом браузера и веб‑сервера можно подсмотреть в веб‑инспекторе. Для этого нужно открыть веб‑инспектор с помощью ⌘+Option+I на Маке и Ctrl+Shift+I или F12 в других ОС. Переключиться во вкладку Сеть и выбрать запрос:

Кроме GET‑запросов «дай» бывают и другие: POST — «прими от меня», PUT — «замени», PATCH — «обнови», DELETE — «удали». Но браузеры используют только GET и POST для действий пользователя со страницей. Не получится воспользоваться другими методами без программирования и отправки запросов вручную.

Браузеры используют GET для получения данных от веб‑сервера — страниц и их ресурсов. Запросы POST используются для отправки данных на веб‑сервер, например, отправки формы или файла.

GET и POST принципиально отличаются тем, как с помощью них передаются данные, параметры на сервер. В случае с GET данные идут в адресе, урле, а в случае с POST — в теле запроса:

GET /search?text=динамические+опердени HTTP/1.1
Host: ya.ru

POST /search HTTP/1.1
Host: ya.ru
Content-Type: application/x-www-form-urlencoded

text=динамические+опердени

Отсюда и берутся их различия:

GET

Запрос данных с сервера

POST

Отправка данных на сервер

GET

Параметры передаются в урле, видны в адресе

POST

Параметры передаются в теле запроса, не видны в адресе

GET

Поиск, фильтрация, загрузка страниц и их ресурсов

POST

Отправка форм, например логина, регистрации или формы заказа, и загрузка файлов на сервер

GET

Остаётся в истории браузера, можно добавить в закладки

POST

Не остаётся в истории браузера, нельзя добавить в закладки

P. S. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.

Комментарии

Вячеслав Крампец

Остаётся запрос в истории браузера или нет, зависит не от типа запроса, а от кода ответа. Если на запрос POST ответить с кодом 200, 404, 500 и пр., он также останется в истории. Чтобы в историю не попало, нужно вернуть код перенаправления.

Правилом хорошего тона в веб‑программировании является всегда возвращать «временный редирект» (код 302), на запросы POST, независимо от результата обработки.

Василий Мишустин

Вячеслав, мне кажется, Василий имел ввиду, что get‑запрос с «полезной нагрузкой» (значениями формы или параметрами поиска) остаётся в истории браузера. Его можно повторить или поделиться им с коллегой и он сработает точно так же.

А post‑запрос не сохраняет «полезную нагрузку» в истории браузера. И им так легко не поделишься. Соответственно, без «полезной нагрузки» он не сработает или сработает не так.

Василий Мишустин

> Правилом хорошего тона в веб‑программировании является всегда возвращать «временный редирект» (код 302), на запросы POST, независимо от результата обработки.

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

Насколько я знаю, стандартом является ответ 201 «создано» и возможно возврат самого созданного объекта. Либо соответствующий ошибочный код и описание ошибки: например, код 403 «необходима аутентификация» и описание ошибки «только зарегистрированные пользователи могут оставлять комментарии».

На мой субъективный взгляд, возвращать код ответа 302 нелогично, особенно «независимо от результата обработки». Код ответа 302 сообщает, что ресурс, к которому обращался браузер, временно перемещён. Соответственно, в рамках этого одного запроса не удастся узнать, создался ли объект, не можем получить созданный объект, не можем понять, почему объект не создался, и т. д. Для всего этого придётся сделать как минимум один дополнительный get‑запрос. К тому же, придётся делать запрос всего списка объектов, а не конкретного объекта — мы не знаем никакого идентификатора объекта. И каким‑то образом сравнивать список до запроса и список после запроса. Плюс мы не можем быть уверены, что объект создали мы, а не кто‑то другой.

Поскольку post‑запрос не идемпотентный, то есть каждый post‑запрос приводит к новому результату, то при получении ответа 302 моим стандартным желанием будет отправить ещё один такой же запрос — я же не получил подтверждения создания или объекта. В итоге можно создать кучу одинаковых объектов, например.

Или вы предлагаете с 302 кодом ответа возвращать объект? А если ошибка — возвращать ошибку с 302 кодом?

Конечно, коды ответа и совершаемые действия при различных типах запросов — это только договорённость: и можно, отправляя delete‑запрос, возвращать объект, а при get‑запросе его удалять — никто не может запретить так настроить сервер. Но это будет максимально не удобно для любых внутренних или внешних систем и разработчиков.

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