Из каких компонентов состоит HTTP-запрос в клиент-серверной архитектуре?

А, ну ты смотри, какая интересная хуйня! Сидишь ты, значит, в своём уютном приложении, и тебе вдруг понадобилось что-то от сервера попросить. Ну или наоборот, ему что-то сунуть. И ты, такой весь из себя продвинутый, не просто в трубу кричишь «Эй, сервак, дай!», а отправляешь ему целое, блядь, послание — HTTP-запрос. Это как письмо, только цифровое и без конверта.

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

Из чего же, из чего же, из чего же сделаны наши запросы?

1. Стартовая строка (Request Line) — она же «крик души» Это самая первая и самая важная строчка, ёпта. В ней всё, как в приказе: что сделать, где сделать и по каким правилам. Конкретно:

   • Метод (Что сделать): GET (дать посмотреть), POST (запихнуть), PUT (положить на место), DELETE (удалить нахуй) и прочие.
   • Путь (Где сделать): Это адресок на сервере, типа /api/v1/users или /cat-pictures/123. Представь, что это номер квартиры в огромном доме-сервере.
   • Версия протокола (По каким правилам): HTTP/1.1 (старая добрая классика) или HTTP/2 (более шустрая). Просто договорённость, как общаться.

   Выглядит эта строка просто, но ёмко, как удар кулаком по столу: GET /api/v1/users HTTP/1.1

2. Заголовки (Headers) — они же «инструкция и документы» Ну, стартовую строку отправили, а дальше-то что? А дальше серверу нужно объяснить как именно обрабатывать наш запрос. Вот для этого — заголовки. Это такие пары «ключ: значение», каждая из которых что-то уточняет.

   • Общие: Host: api.example.com (эй, мы к тебе обращаемся!), User-Agent: MyAwesomeApp/1.0 (а вот и я, узнаёшь?).
   • Специфичные для запроса: Authorization: Bearer token123 (смотри, у меня пропуск!), Accept: application/json (отвечай мне, пожалуйста, на JSON'е, а не на XML'е, а то я его не переварю).
   • Про тело: Content-Type: application/json (в теле, которое я тебе сейчас суну, лежит JSON, не пугайся), Content-Length: 56 (и этого добра там ровно 56 байт, считай).

3. Тело запроса (Body) — они же «посылка с данными» А вот это — опциональная, но часто самая сочная часть. Она есть не всегда, а только когда ты что-то отправляешь серверу: нового пользователя создать, пост написать, файл загрузить. Бывает у методов POST, PUT, PATCH. Внутри может быть что угодно: JSON, XML, картинка, простой текст — главное, в заголовке Content-Type честно признаться, что это.

А теперь, блядь, полный разбор полётов, чтобы вообще ни хуя не осталось непонятного:

POST /api/v1/users HTTP/1.1          // Эй, сервер! Засунь-ка (POST) данные по адресу /api/v1/users, говорим на HTTP/1.1!
Host: api.example.com                // Обращаюсь конкретно к тебе, api.example.com, не перепутай!
Content-Type: application/json       // В посылке у меня JSON, будь добр, распакуй соответственно.
Authorization: Bearer token123       // Вот мой токен, я свой, не бей!
Content-Length: 56                   // Посылка весит 56 байт, проверь, всё ли дошло.

{"name": "Alice", "email": "alice@example.com"} // А вот и сама посылка! Держи нового пользователя Алису.

И главный принцип, который надо выжечь на подкорке, ёбта: Запрос — это чёткое техническое задание. В нём есть что сделать (метод+путь), как сделать (заголовки) и исходные данные (тело, если есть). Сервер, получив эту простыню, её прочитает, обдумает и пришлет в ответ свою простыню — с кодом состояния (типа «окей» или «иди нахуй, ошибка 404») и, возможно, результатом. Вот и вся, блядь, магия!