Основы REST API и OAuth2

Игорь Стариков / idle sign

Видео выступления

Автор

  • Несу Python в массы:
    • Рассказываю о нём
    • Поддерживаю сайт — pythonz.net
    • Перевожу и озвучиваю доклады с PyCon US
  • Пишу код и отдаю его людям — idlesign

Архитектурный стиль REST

Representational State Transfer — передача репрезентативного состояния.

Передаётся представление ресурса в некотором состоянии.

Рой Томас Филдинг

У истоков HTTP, HTML, URI.

Диссертация Architectural Styles and the Design of Network-based Software Architectures, 2000 г.

Описаны принципы, лежащие в основе всемирной паутины. REST — главы 5, 6.

REST — свод требований

  • Единообразный интерфейс
  • Клиент-сервер
  • Нет хранению состояния на сервере
  • Слоистая система
  • Кешируемость (возможна)
  • Код по требованию (возможен)

Клиент-сервер

Разделение ответственности.

Пример: пользовательский интерфейс — хранилице данных.

Нет хранению состояния на сервере

Каждый запрос целостен не зависит от предыдущих, содержит всю необходимую для ответа на него информацию.

  • Состояние сессии не хранится на сервере, но может хранится на клиенте.
  • Одинаковые запросы с разных клиентов должны приводить к одинаковым представлениям.

Слоистая система

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

Кешируемость

Средство повышения производительности.

По умолчанию ответ на запрос получения данных может кешироваться, ответы на другие типы запросов не кешируются.

Ответ сервера должен содержать явное указание, разрешено ли кеширование.

Код по требованию

Скрипты могут загружаться на клиенты,
исполняться ими.

Ресурсы

  • Ресурсом может быть всё, что можно именовать.
  • Имена выбирает хозяин ресурса. Цельнтрализация считается злом.
  • Формат (тип медиа) зависит от нужд и возможностей клиента.
    Не все для автообработки.
  • Степень идентичности представления исходному объекту скрыта за интерфейсом.
  • Одновременно два разных русурса могут иметь одно значение (представление).

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

для взаимодействия компонентов системы
Требования к ресурсам:
  • Идентификация
    URI должны быть постоянными.
  • Манипуляция через представления
    Действия HTTP: OPTIONS, GET, PUT, POST, DELETE, PATCH.
  • Cамоописание
    Заголовки HTTP: host, status, accept-encoding, content-type, cache-control.
  • ГКДСП (HATEOAS)
    Гипермедиа, как двигатель состояния приложения. Гиперссылки — основа паутины.

Плюсы и минусы REST

  1. Простота архитектуры
  2. Понижение сложности системы
  3. Удобство мониторинга
  4. Увеличение надёжности
  5. Расположенность к масштабируемости
  1. Снижение производительности
    *Нивелируется кешированием.
  2. Снижение контроля со стороны сервера
    Необходимость поддержки разных версий клиентов.
  3. Снижение продуктивности
    Оптимизирован для общих случаев.

Гипермедиа и JSON

JSON — не является гипермедийным форматом

Пишем. Часть 1

OAuth2 — каркас для авторизации

Переосмысление оригинального OAuth.

Спецификация: The OAuth 2.0 Authorization Framework (RFC 6749). Разработка: 2010-2012.

Основные шаги

  1. Регистрация клиента
    для получения его идентификатора (не являющегося секретным)
    • Указание типа (доверенный / публичный)
    • Указание URI переадресации (для возвращения ответа с реквизитами)
    • Указание пароля (не обязательно)
  2. Получение токена доступа
    Токен — временный идентификатор. Выдаётся для пользователя и/или клиента.
  3. Использование токена доступа
    При каждом обращении к нужным ресурсам вместо связки логин + пароль пользователя.

Точки сообщения

  • Точка авторизации (TLS). На сервере
    Для получения допуска от владельца ресурса.
  • Точка получения токена (TLS). На сервере
    Для обмена реквизитов допуска на токен доступа, обычно с аутентификацией клиента.
  • Точка переадресации. На получателе
    Используется сервером для возвращения ответа, содержащего реквизиты доступа.

Варианты получения допуска

  • Код авторизации (доверенные, веб)
    1. Точка авторизации: ID Клиента + URI Аутентификация Код на URI
    2. Точка токена: ID Клиента + URI + Код Токен на URI
  • Неявный (публичные, мобильные)
    Точка авторизации: ID Клиента + URI Аутентификация Токен на URI
  • Реквизиты пользователя (наследство)
    (только в случае доверия к клиенту и недоступности других способов)
    Точка токена: Реквизиты пользователя Токен
  • Реквизиты клиента (только доверенные, серверные)
    Точка токена: Реквизиты клиента Токен

Использование токена типа Предъявитель (Bearer)

OAuth 2.0 Bearer Token Usage (RFC 6750)

  • Заголовок Authorization 
    Authorization: Bearer dnU7qj7wgd
  • POST 
    access_token=dnU7qj7wgd
  • GET, только если иначе нельзя 
    ?access_token=dnU7qj7wgd

Пишем. Часть 2

Ссылки

Спасибо за внимание!

Вопросы?

idlesign   idlesign   idlesign  

Эти слайды можно найти тут — http://bit.ly/ist_002