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

Допустим, мы посмотрели меню и нам нужно правильно сформулировать заказ. В ресторане есть правило: общаться вежливо и говорить подробно. Это и есть протокол передачи данных — HTTP/HTTPS. Соблюдая протокол, нужно сказать так: «Принесите, пожалуйста, говяжий стейк средней прожарки». Так официант нас точно поймет: мы вежливы и знаем, чего хотим. Если бы мы сказали просто «Мне стейк», то в лучшем случае получили бы стейк, но не говяжий. В худшем случае официант ничего не принесет.
HTTPS — это тот же HTTP, но с шифрованием, чтобы никто не подслушал наш заказ. По HTTP же данные передаются открыто, и сейчас почти все ресурсы используют HTTPS.

На этом можно было бы и закончить: ведь что такое HTTP я уже написала)
Далее опишу, как смотреть коды ошибок и зачем они нужны - что для проджекта может быть важно.

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

Как выглядит HTTP-запрос?
Запрос всегда включает в себя:
Метод — что мы хотим сделать. Те самые GET, POST, PUT, PATCH, DELETE из предыдущего поста - часть HTTP запроса.
URL — куда отправляем запрос. Например /menu/steaks— посмотреть стйнки в меню.
Версию протокола — указываем, какую версию протокола использовать. Например, HTTP/1.1 или HTTP/2.
Заголовки (Request headers) — дополнительные данные. Например: с какого браузера мы передаем запрос? User-Agent: Mozilla/5.0.
Тело запроса (Body) — содержимое запроса. В GET-запросах тело отсутствует (хотя технически его передать можно), а в POST и PUT оно требуется для передачи данных.

Если кажется что сайт не работает, форма обратной связи не отправляется, если кажется что проблема не на вашей стороне: стоит проверить, возможно вам не кажется. Для этого можно посмотреть, что ответил нам сервер по HTTP-протоколу.
Самый простой способ посмотреть ответ - открыть DevTools: в браузре нажать F12 → перейти во вкладку Network → там прописаны все данные, из которых состоит запрос и ответ.
Что мы там увидим? Нас интересует вкладка Response - ответ сервера.

Сервер отвечает тоже по правилам:
Статус (код ответа) — получилось или нет. Например, 200 OK — всё хорошо, заказ точно такой, как и просили.
Коды делятся на группы:
1xx — «Ожидайте». Например, запрос принят, но заказ еще готовят.
2xx — «Всё хорошо». 200 OK: Вот ваш стейк.
3xx — «Редирект». К примеру 301: ресурс переехал. Куда? Нужно смотреть в заголовке, в поле Location.
4xx — «Ошибка клиента» (Мы ошиблись!). 400 Bad Request: тот случай, когда мы сказали «Мне стейк» и официант не понял, что мы хотим.
5xx — «Ошибка сервера» (Не мы ошиблись!). 500 Internal Server Error: отключили свет, и заказ приготовить сейчас не могут, но всё обязательно починят.
Заголовки (Response headers) — дополнительные данные, например: Content-Type: text/html говорит о том, что в теле ответа мы получили HTML-разметку.
Тело ответа — сами данные. В ресторане бы нам просто отдали сам стейк.

Но! Если сайт не работает, не всегда можно увидеть ответ. Сайт может просто не достучаться до сервера и на это могут быть разные причины - плохая настройка сервера, недоступность сети и другие, но не об этом сейчас)

Получилось очень объемно, и многое осталось без внимания, но своими постами я хочу не научить, а объяснить — всё-таки это разные вещи 🙂

Я начала вести тг канал, где рассказываю просто о сложном в IT.
Если вы дочитали этот пост, то скорее всего вас интересует тема, поэтому буду рада, если поддержите подпиской: https://t.me/jer_it