
Do ut facias
Вроде бы, тема совсем для начинающих. Как клиент (браузер) общается с сервером (сайтом) в вебе? Но готов поспорить, что процентов 80 пиэмов не смогут внятно об этом рассказать. Для них и статья. Оставшиеся 20, выросшие из технарей, вряд ли извлекут из этой публикации что-то новое.
Полетели.
Веб работает в архитектуре клиент‑сервер. С одной стороны веб‑сервер, с другой — клиент: браузер, приложение (например, для андроида или айфона) или даже другой веб‑сервер. Клиент и веб‑сервер общаются с помощью протокола HTTP (Hypertext Transfer Protocol) — специального языка и набора правил. Раньше в начале любого адреса в адресной строке мы видели http://, потом как-то все перешли на безопасную зашифрованную версию https:// А сейчас этот префикс, по крайней мере хром, не отображает вовсе.
Когда мы открываем сайт в браузере, браузер посылает запрос, буквально пишет серверу «Дай мне страницу index.html» или «Дай мне goatse.jpg»:
GET /index.html HTTP/1.1
Host: bychko.ru
User-Agent: ChromeЗдесь GET — это метод запроса, /index.html — путь к тому, что мы запрашиваем, а HTTP/1.1 — версия протокола. Дальше идут заголовки — набор строк в формате ключ: значение. Это дополнительная информация, которая помогает серверу узнать больше о клиенте и его запросе.
Сервер на этот запрос отвечает «Забирай страницу» или «Вот goatse.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?
Гетом браузер забирает данные от сервера, постом отправляет данные — строчки из полей формочек или файлы. Когда вы откликаетесь на вакансию на сайте компании и прикрепляете резюме, всё содержимое формы, вместе с pdf отправляется на сервер именно POST-ом.
Ещё бывают:
- PUT — «замени»,
- PATCH — «обнови»,
- DELETE — «удали».
Но браузеры используют только GET и POST для действий пользователя со страницей, в целом, вам достаточно знать только их.
GET и POST принципиально отличаются тем, как с помощью них передаются данные, параметры на сервер. В случае с GET данные идут в адресе, урле, а в случае с POST — в теле запроса. Ну, вы понимаете — чтобы запросить данные, надо отправить урл с запросом, а чтобы отправить данные — засунуть их в тело и заслать на сервер. А именно:
GET /search?text=управление рисками HTTP/1.1
Host: bychko.ruPOST /search HTTP/1.1
Host: bychko.ru
Content-Type: application/x-www-form-urlencoded
text=управление рискамиВ остальном, детальные различия между GET и POST вот такие:
GET
Запрашивает данные с сервера.
Параметры передаются в URL-е, вы можете их видеть в адресной строке браузера.
Нужен для поиска, фильтрации, загрузки страничек.
Остаётся в истории браузера1, можно добавить в закладки
Post
Отправляет данные на сервер.
Параметры передаются в теле запроса, в адресной строке их не видно.
Нужен для отправки форм (например, данные заказа авиабилета), файлов.
Не остаётся в истории браузера, нельзя добавить в закладки.
- Умные люди подсказывают, что остаётся запрос в истории браузера или нет, зависит не от типа запроса, а от кода ответа. Если на запрос POST ответить с кодом 200, 404, 500 и пр., он также останется в истории. Чтобы в историю не попало, нужно вернуть код перенаправления. Правилом хорошего тона в веб‑программировании является всегда возвращать «временный редирект» (код 302), на запросы POST, независимо от результата обработки. ↩︎





Добавить комментарий