HTTP

Проработать

  1. Типы HTTP-запросов и философия REST
  2. RESTful API Design
  3. gRPC-- Альтернатива REST от google
  4. Синхронизируем понимание REST
  5. Что такое RESTful на самом деле
  6. REST API Best Practices
  7. Лучшие практики проектирования REST API
  8. REST: простым языком
  9. Типы HTTP-запросов и философия REST
  10. REST API (HTTP) vs Websockets - Concept Overview With Example
  11. HTTP-куки
  12. Понимание REST
  13. Что такое Rest API (http)? Soap? GraphQL? Websockets? RPC (gRPC, tRPC). Клиент - сервер. Вся теория
  14. When RESTful architecture isn't enough...
  15. то такое Web3?
  16. Web 2 vs. Web 3: What’s the Difference and Why It Matters
  17. Top 6 Most Popular API Architecture Styles

    18. MIME - header - Content-Type

  18. Список MIME-типов
  19. MIME types

    20. Нейминг

  20. REST API Naming Conventions and Best Practices

Что это

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

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

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

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 - используется для получения информации о том, что происходит с сообщением на промежуточных узлах.

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

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 не должно быть глаголов.

ОперацияURIHTTP methodStatus codeТело ответа
Добавить элементPOST/PUT/products201Созданный элемент
Получить элементGET/products/{id}200Найденный элемент
Получить все элементыGET/products200Найденные элементы
Обновить часть данных элементаPATCH/products/{id}204/200(есть тело ответа)Обновленный элементы
Обновить все данные элементаPUT/products/{id}200Обновленный элементы
Удалить элементDELETE/products/{id}204/200(есть тело ответа, не рекомендуется.)-

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 пришлет информацию когда она будет готова.