ЗАМЕТКИ

REST API Node.js заметки

Общие сведенья (кратко). Основными компонентами архитектуры REST являются ресурсы (web страницы, изображения, сервисы, отчеты). Структура ресурсов приведена в Таблице 1.

Таблица 1 Структура ресурсов

Свойства Описание
Представление (Representation Бинарный данные, JSON, XML. Каждый ресурс может иметь несколько представлений
Идентификатор (ID) URL возвращающий один ресурс в нужное время
Мета-данные (Metadata) Тип содержимого, время последнего изменения и т.д.
Управление данным (Control data) Модификация данных, управление кэшем

Cогласование контента (Content Negotiation) — это механизм используемый для отображения различных представлений ресурса по тому же URI (unique resource identifier — уникальный идентификатор ресурса), так чтобы клиент мог указать, что лучше подходит для пользователя (например, желаемый язык документа, формат изображения, или кодировку текста) ссылка

Архитектурный принцип проектирования API HATEOAS (Hypermedia as the Engine of Application State), публикация на сайте mxsmirnov.com ссылка и введение в разметку языка HAL (Hypertext Application Language), публикация на сайте coderlessons.com ссылка

Коды ответа (состояния) HTTP показывает, был ли успешно выполнен определённый запрос ссылка

REST API Best Practices публикация на habr.com ссылка

RESTful Web-сервисы подборка публикаций на habr.com ссылка

Аторизация сервисов, использование протоколов OAuth. Ниже, на Рис.1 приведена диаграмма описывающая принцип работы протокола OAuth 1.0a, подробная информация на ресурсе ссылка

Рис. 1 OAuth 1.0a принцип работы протокола

Consumer (потребитель данных) запрашивает token (токен — «цифровой ключ») у поставщика данных Service Provieder. В запросе (HTTP POST) указываются следующие праметры:

  • oauth_consumer_key (ключ потребителя данных), выдается поставщиком (сервисом) данных после регистрации приложения (потребителя данных);
  • oauth_signature_method метод шифрования сигнатуры, их существует три для данного протокола это PLAINTEXT, HMAC-SHA1 и RSA-SHA1. Метод используется в подписании запроса со стороны Consumer;
  • oauth_signature параметр значением которого является сгенерированная сигнатура (генерируется методом oauth_signature_method);
  • oauth_timestamp метка времени отправления запроса, если такое время будет значительно отличаться от времени поступления запроса поставщику данных, такой запрос может быть отклонен (необходимо проверить серверное время);
  • oauth_nonce строковое значение, используемое для связи сеанса Consumer с идентификатором токена и для предотвращения атак воспроизведения. Значение передается неизмененным из запроса аутентификации на токен идентификатора;
  • oauth_version версия протокола, для данного протокола 1.0;
  • oauth_callback параметр подтверждающий обратный ответ от поставщика данных об обработке запроса.

Поставщик данных Service Provieder проверяет целостность сигнатуры, проверят токен запроса для токена доуступа на изменения, проверяет токен запроса и ключ Consumer и возвращает ответ, включающий следующие параметры:

  • oauth_token токен доступа (access token);
  • oauth_token_secret токен зашифрованный для доступа (секретный токен, secret token);
  • oauth_callback_confirmed параметр подтверждающий обработку запроса от Consumer.

Далее, выполняется процесс авторизации Consumer, выполняется верификация токенов (ключей) — согласование доступа. Потребителю данных требуется токен запроса (request token) который предоставляет сервер (источник данных) по определнному URL-адресу. После того как токен запроса будет получен, потребитель данных делает запрос по определнному URL-адресу для авторизации. После авторизации, потребитель данных запрашивает у поставщика данных токен доступа (access token) и секретный ключ (secret token), после получения которых, потребитель данных может получать доступ к защизенным ресурсам. Суть работы данного протокола заключается в необходимости подписания каждого запроса исходящего со стороны потребителя данных уникальным цифровым ключем (токеном).

Принципиальное отличие работы протокола OAuth 2.0 заключается в отсутствии необходимости подписания запросов со стороны потребителя данных. Реализация протокола основана на защищенном соединении потребителя и поставщика данных с шифрованием SSL (или TSL). Для реализации запроса необходим только токен запроса. Подробная спецификация данного протокола приведена на ресурсе ссылка

Event Loop позволяет выполнять асинхронные не блокирующие операций ввода вывода (I/O) в Node.js при этом сам по себе JavaScript является однопоточным. Подробное опсиание оператора приведено на ресурсе ссылка Далее, приведен пример описывающий работу этого оператора:

Реализация в Express