HTTP

Что это

HTTP(HyperText Transfer Protocol) - является протоколом клиент-серверного взаимодействия без сохранения промежуточного состояния. В роли клиента чаще всего выступает веб-браузер. Для обмена информацией протокол HTTP в большинстве случаев использует TCP/IP.

Основные разделы

• Протоколы передачи данных
• HTTP запрос структура
• HTTP методы
• Коды состояния
• REST
• Robustness principle(Postel’s Law)
• Идемпотентность
• Http сессия

Протоколы передачи данных

HTTP(Hypertext Transfer Protocol) - протокол прикладного уровня передачи данных, изначально — в виде гипертекстовых документов в формате HTML, в настоящее время используется для передачи произвольных данных. Если не указывать порт будет использован стандартный - "80".

HTTPS(HyperText Transfer Protocol Secure) - расширение протокола HTTP для поддержки шифрования в целях повышения безопасности. Данные в протоколе HTTPS передаются поверх криптографических протоколов TLS или устаревшего в 2015 году SSL. Если не указывать порт будет использован стандартный - "443". Для проверки качества TLS/SSL защиты можно использовать ресурс "ssllabs.com/ssltest/index.html"

HTTP запрос структура

1. Стартовая строка
2. Заголовки
3. Request Payload(Request Body) - есть у POST, PUT, PATCH. Нет у HEAD, GET, DELETE.

Заголовки(Headers)

Значение header не может быть null.

1. Host - для указания к какому приложению обращаться, если на сервере есть несколько приложений.
2. Content-Type - сообщает передаваемый тип данных с помощью MIME отметок.

HTTP методы

1. GET - получение ресурса. Передает данные серверу используя URL(1024 символами).
2. POST - создание ресурса.
3. PUT - обновление ресурса.
4. PATCH - обновляет часть ресурса.
5. DELETE - удаление ресурса.
6. HEAD - используется для получения метаинформации об объекте без пересылки тела HTTP сообщения.
7. OPTIONS - для получения параметров текущего HTTP соединения.
8. TRACE - используется для получения информации о том, что происходит с сообщением на промежуточных узлах.

Кеширование

GET и HEAD - кешируемые.

POST - по умолчанию не кэшируются, но можно кэшировать, если к ответу добавить заголовок Expires или заголовок Cache-Control с директивой, явно разрешающей кэширование.

Коды состояния

• 200 - OK.
• 201 - Created.
• 204 - No Content.
• 400 - Bad Request.
• 401 - Unauthorized - необходима авторизация.
• 403 - Forbidden - нет прав доступа к содержимому.
• 404 - Not Found - ресурс не найден.

REST

REST(Representational State Transfer) - архитектурный стиль(набор правил, подход) для создания API в HTTP.

Правила REST:

1. Модель взаимодействия - клиент-сервер. Клиент - л.бой пользователь, сервер - API.
2. Многослойность(многоуровневость) - применение промежуточных серверов способно повысить: масштабируемость, балансировки нагрузки, кэширования и тд. Пример: MVC или микросервисы.
3. Отсутствие состояния(клиента) - сервер не хранит данные о запросах. Клиент каждый раз авторизуется.
4. Кэширование - для GET и POST(если есть Expires header or a Cache-Control header).
5. Единообразие интерфейса.
6. Код по требованию(необязательный) - исполнение кода на стороне клиента.

Единообразие интерфейса.

Пример корректного url: http://localhost:9999/restfulservices/v1/users/{id}

В url не должно быть глаголов.

Robustness principle(Postel’s Law)

Robustness principle - принцип объясняющий почему лучше не делать проверку на строгую схему протокола передачи. Коротко в запросе могут быть другие параметры которые будут проигнорированы системой. Коротко - не нужно проверять JSON на отсутствие других полей. Убирает необходимость синхронизировать релизы зависимых сервисов.

Идемпотентность

Идемпотентность(Idempotency) - это запрос, который выполняется всегда с одним эффектом, но ответ на запрос может быть разный. Пример "DELETE" первый запрос возвращает 200, а последующие 404. Не идемпотентный HTTP метод - POST.

Http сессия

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

Данные получаются и сохраняются в сессии при помощи соответствующего "ключа".

Контейнер сервлетов при любом запросе проверяет, есть ли в запросе параметр ID сессии. Если Да(например, клиент первый раз обращается к серверу), тогда контейнер сервлетов создает новый объект HttpSession, а также присваивает ему уникальный ID. Объект сессии сохраняется на сервере, а ID отправляется в ответе клиенту и по умолчанию сохраняется на клиенте в куках. Затем, когда приходит новый запрос от того же клиента, то контейнер сервлетов достает из него ID, и по этому ID находит правильный объект HttpSession на сервере.

Получить объект сессии можно из запроса (объект HttpServletRequest), у которого нужно вызвать метод getSession(). Он возвращает объект HttpSession.

Способы обеспечения уникального идентификатора сессии:

1. User Authentication – предоставление учетных данных самим пользователем в момент аутентификации. Переданная таким образом информация в дальнейшем используется для поддержания сеанса. Это метод не будет работать, если пользователь вошёл в систему одновременно из нескольких мест.
2. HTML Hidden Field – присвоение уникального значения скрытому полю HTML страницы, в момент когда пользователь начинает сеанс. Этот метод не может быть использован со ссылками, потому что нуждается в подтверждении формы со скрытым полем каждый раз во время формирования запроса. Кроме того, это не безопасно, т.к. существует возможность простой подмены такого идентификатора.
3. URL Rewriting – добавление идентификатора сеанса как параметра URL. Достаточно утомительная операция, потому что требует постоянного отслеживания этого идентификатора при каждом запросе или ответе.
4. Cookies – использование небольших фрагментов данных, отправленных web-сервером и хранимых на устройстве пользователя. Данный метод не будет работать, если клиент отключает использование cookies.
5. Session Management API – использование специального API для отслеживания сеанса, построенный на основе и на методах, описанных выше. Который решает частные проблемы перечисленных способов - чаще всего недостаточно просто отслеживать сессию, необходимо ещё и сохранять какие-либо дополнительные данные о ней. Которые могут потребоваться при обработке последующих запросов. Осуществление такого поведения требует много дополнительных усилий.

Webhook

Webhook - способ оповещения клиента о событиях с помощью пользовательских обратных вызовов по HTTP.

HTTP POST запрос. Иногда GET.

Основной формат - JSON.

В основной, клиент сам указывает адрес на котором будет ожидать ответ.

Отличение от API

API - требует постоянных вызовов для обновления информации, а Webhook пришлет информацию когда она будет готова.