HTTP/REST. Клиентское приложение

1.

HTTP/REST
astondevs.ru

2.

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

3.

HTTP Request
HTTP запросы - это сообщения, отправляемые клиентом, чтобы инициировать реакцию со стороны сервера.
Запрос состоит из:
1.
2.
3.
4.
Request-Line (Method SP Request-URI SP HTTP-Version CRLF)
Заголовки
Пустой линии
Произвольного тела, содержащего пересылаемые с запросом данные (например, содержимое HTML-формы )
или отправляемый в ответ документ. Наличие тела и его размер определяется стартовой строкой и
заголовками HTTP. Тела может и не быть, такие методы, как GET, HEAD, DELETE, или OPTIONS, в нем обычно не
нуждаются.

4.

HTTP Response
Ответ состоит из:
1. Message Status-Line (HTTP-Version SP Status-Code SP Reason-Phrase CRLF)
Статус коды:
2. Полей заголовка
3. Пустой линии
4. Последней частью ответа является его тело. Оно есть не у всех ответов: у ответов с кодом состояния, например, 201 или 204,
оно обычно отсутствует.

5.

HTTP Methods
1. GET запрашивает представление ресурса. Запросы с использованием этого метода могут только извлекать
данные
2. HEAD запрашивает ресурс так же, как и метод GET, но без тела ответа.
3. POST используется для отправки сущностей к определённому ресурсу. Часто вызывает изменение
состояния или какие-то побочные эффекты на сервере.
4. PUT заменяет все текущие представления ресурса данными запроса.
5. DELETE удаляет указанный ресурс.
6. CONNECT устанавливает "туннель" к серверу, определённому по ресурсу.
7. OPTIONS используется для описания параметров соединения с ресурсом.
8. TRACE выполняет вызов возвращаемого тестового сообщения с ресурса.
9. PATCH используется для частичного изменения ресурса.
HTTP определяет множество методов запроса, которые указывают, какое желаемое действие выполнится для
данного ресурса. Несмотря на то, что их названия могут быть существительными, эти методы запроса иногда
называются HTTP глаголами. Каждый реализует свою семантику, но каждая группа команд разделяет общие
свойства: так, методы могут быть безопасными, идемпотентными или кешируемыми.

6.

HTTP Methods
HTTP методы бывают 3 типов:
1. Безопасные методы - метод которые не меняет состояние сервера. Другими словами, безопасный метод
проводит операции "только чтение" (read-only). GET, HEAD, OPTIONS
2. Идемпотентные методы - метод HTTP является идемпотентным, если повторный идентичный запрос,
сделанный один или несколько раз подряд, имеет один и тот же эффект, не изменяющий состояние сервера.
Другими словами, идемпотентный метод не должен иметь никаких побочных эффектов (side-effects), кроме
сбора статистики или подобных операций. Корректно реализованные
методы GET, HEAD, PUT, DELETE, OPTIONS идемпотентны, но не метод POST. Также все безопасные методы
являются идемпотентными.
3. Все остальные.

7.

Вопрос на 1 балл
Чем отличаются методы PUT/PATCH/POST?

8.

POST vs PUT vs PATCH
• POST - используется для создания нового ресурса (даже если новый ресурс будет дубликатом – операция
создания)
• PUT - используется в следующем стиле: если ресурс существует – обновляем его, если нет – создаем
(операция замены).
• PATCH - всегда используется для обновления ресурса (операция обновления).

9.

HTTP headers
Заголовки HTTP позволяют клиенту и серверу отправлять дополнительную информацию с HTTP запросом или
ответом. В HTTP-заголовке содержится не чувствительное к регистру название, а затем после (:)
непосредственно значение.
Заголовки могут быть сгруппированы по следующим контекстам:
1. Основные заголовки применяется как к запросам, так и к ответам, но не имеет отношения к данным,
передаваемым в теле.
2. Заголовки запроса содержит больше информации о ресурсе, который нужно получить, или о клиенте,
запрашивающем ресурс.
3. Заголовки ответа (en-US) содержат дополнительную информацию об ответе, например его
местонахождение, или о сервере, предоставившем его.
4. Заголовки сущности содержат информацию о теле ресурса, например его длину содержимого или
тип MIME (en-US).

10.

HTTP statuses
Код ответа (состояния) HTTP показывает, был ли успешно выполнен определённый HTTP запрос. Коды
сгруппированы в 5 классов:
• Информационные 100 - 199
• Успешные 200 - 299
• Перенаправления 300 - 399
• Клиентские ошибки 400 - 499
• Серверные ошибки 500 - 599
Если вы получили код ответа (состояния), которого нет в данном списке, в таком случае он является не
стандартизированным кодом ответа (состояния), вероятней всего он кастомный сервера.

11.

HTTP caching
Производительность веб-сайтов и приложений можно значительно повысить за счёт повторного использования
ранее полученных ресурсов. Веб-кеши сокращают задержку и снижают сетевой трафик, уменьшая тем самым
время, необходимое для отображения ресурсов. Используя HTTP-кеширование, сайты становятся более
отзывчивыми.
Техника кеширования заключается в сохранении копии полученного ресурса для возврата этой копии в ответ на
дальнейшие запросы. Запрос на ресурс, уже имеющийся в веб-кеше, перехватывается, и вместо обращения к
исходному серверу выполняется загрузка копии из кеша.
Однако, кеш надо правильно сконфигурировать: ресурсы редко остаются неизменными, так что копию требуется
хранить только до того момента, как ресурс изменился, но не дольше.
Подробнее читайте здесь:
https://developer.mozilla.org/ru/docs/Web/HTTP/Caching

12.

HTTP ресурсы
Ресурс — это ключевая абстракция, на которой концентрируется протокол HTTP. Ресурс — это все, что вы хотите показать
внешнему миру через ваше приложение. Например, если мы пишем приложение для управления задачами, экземпляры
ресурсов будут следующие:
• Конкретный пользователь
• Конкретная задача
• Список задач
Способ, которым мы идентифицируем ресурс для предоставления, состоит в том, чтобы назначить ему URI — универсальный
идентификатор ресурса. Например:
• Создать пользователя: POST /users
• Удалить пользователя: DELETE /users/1
• Получить всех пользователей: GET /users
• Получить одного пользователя: GET /users/1

13.

14.

REST
Что нужно знать о REST API:
• REST (Representational State Transfer) — это способ создания API с помощью протокола HTTP. На русском его
называют «передачей состояния представления».Технологию REST API можно применятьвезде, где пользователю
сайта или веб-приложения нужно предоставить данные с сервера.
• У RESTful нет единого стандарта работы: его называют «архитектурным стилем» для операций по работе с
серверов. Есть несколько принципов и best practices.
• При написании RESTful сервисов вам нужно думать о приложении с точки зрения ресурсов:
Определите, какие ресурсы вы хотите открыть для внешнего мира. Используйте глаголы, уже определенные
протоколом HTTP, для выполнения операций с этими ресурсами.
• REST это о ресурсах, не действиях, о существительных, не о глаголах.

15.

Вопрос на 0.5 балла
Что такое API?

16.

REST
У RESTful есть 7 принципов написания кода интерфейсов.
1. Единство интерфейса (Uniform Interface). Между клиентом и сервером должен быть единый и понятный
интерфейс. Все данные должны запрашиваться через один URL-адрес стандартными протоколами,
например, HTTP. Это упрощает архитектуру сайта или приложения и делает взаимодействие с сервером
понятнее. Для реализации этого принципа, необходимо обеспечить следующие ограничения:
> Resource-Based – отдельные ресурсы уникально идентифицируется за счет uri. Ресурсы концептуально
отделены от репрезентаций, которые возвращаются клиенту (Сервер не возвращает сущность из бд,
скорее какой-нибудь json с частью этих данных)
> Self-descriptive Messages – с response сервер отправляет всю необходимую информацию, для
манипуляций с ресурсом (удаление/обновление и тд)
> Манипуляции с ресурсами происходят через репрезентации
2. Отделение клиента от сервера (Client-Server). REST API разделяет клиента и сервер. Код запросов остается на
стороне клиента, а код для доступа к данным — на стороне сервера. Подобное разделение ответственностей
позволяет независимо разрабатывать клиент/серверную части, безболезненно заменять реализации, а также
масштабировать приложения.

17.

REST
3. Отсутствие записи состояния клиента (Stateless). Сервер не должен хранить информацию о состоянии
(проведенных операций) клиента. Каждый запрос от клиента должен содержать только ту информацию,
которая нужна для получения данных от сервера. Вся необходимая инфа для обработки запроса должна
храниться в самом запросе.
4. Кэшируемость (Casheable). RESTful приложения поддерживают кеширование.
5. Многоуровневость системы (Layered System). Между клиентом и сервером может быть множество
прокси-сервиров. В микросервисной архитектуре, каждый отдельный сервис – по сути сервер. Так же могут
быть балансировщики нагрузок (load balancer), сервисы кеширование и тд.
6. Предоставление кода по запросу (Code on Demand). Серверы могут отправлять клиенту код (например,
скрипт для запуска видео). Так общий код приложения или сайта становится сложнее только при
необходимости.

18.

REST – зачем все это?
Следование этим ограничения дает ряд преимуществ:
Возможность масштабирования
Системы, реализующие REST API, могут эффективно масштабироваться благодаря оптимизации взаимодействия
между сервером и клиентом по REST. Отсутствие сохранения состояния снимает нагрузку с сервера: серверу не
нужно сохранять информацию о предыдущих запросах клиента. Отлаженное кэширование частично или
полностью устраняет некоторые взаимодействия между клиентом и сервером.
Гибкость
RESTful Веб-службы поддерживают полное разделение клиента и сервера. Они упрощают и разделяют
различные серверные компоненты, чтобы каждая часть могла развиваться независимо. Изменения платформы
или технологии в серверном приложении не влияют на клиентское приложение.
Независимость
REST API не зависит от используемой технологии. Вы можете создавать как клиентские, так и серверные
приложения на разных языках программирования, не затрагивая структуру API. Также можно изменить базовую
технологию на любой стороне, не влияя на обмен данными.

19.

Полезные ссылки
https://habr.com/ru/articles/590679/
https://habr.com/ru/companies/yandex/articles/265569/