Архитектура: REST - требования

Существует шесть обязательных ограничений для построения распределенных REST-приложений

Выполнение этих ограничений обязательно для REST-системы. Накладываемы ограничение определяют работу сервера в том, как он может обрабатывать и отвечать на запросы клиентов. Действуя в рамках этих ограничений, система приобретает такие желательные свойства как производительность, масштабируемость, простота, способность к изменениях, переносимость, обслуживаемость и надежность

Если сервис-приложение нарушает любое из этих ограниченных условий, данную систему нельзя считать REST-системой

1. Модель клиент-сервер

Первым ограничением применимым к гибридной модели, является приведение архитектуры к модели клиент-сервер. Разграничение потребностей является принципом, лежащим в основе данного накладываемого ограничения. Отделение потребности интерфейса клиента от потребностей сервера (хранившего данные) повышает переносимость кода клиентского интерфейса на другие платформы, а упрощение серверной части улучшает масштабируемость.

2. Отсутствие состояния

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

3. Кеширование

Как и во всемирной паутине, клиенты а также промежуточные узлы, могут выполнять кеширование ответов сервера. Ответы сервера в свою очередь, должны иметь явно или не явное обозначение как кэшируемые или некэшируемые с целью предотвращения получения клиентами устаревших или неверных данных в ответах на последующие запросы. Правильное использование кеширования способно частично или полностью устранить некоторые клиент-серверные взаимодействия, еще больше повышая производительность и масштабируемость.

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

Наличии унифицированного интерфейса является фундаментальным требованием дизайна REST-сервисов. Унифицированные интерфейсы позволяют каждому из сервисов развиваться независимо.

Предъявляться следующие четыре ограничительных условия:

• Идентификация ресурсов - все ресурсы идентифицируются в запросах, на пример с использованием URI в интернет системах. Ресурсы концептуально отделены от представлений, который возвращают клиентам. Например, сервер может отсылать данные из базы данных в виде HTML, XML, JSON, но не один и которых не является типом хранения внутри сервера.
• Манипуляция ресурсами через представление - если клиент хранит представление ресурса, включая метаданные - он обдает достаточной информацией для модификации или удаления ресурса
• Самоописываемые сообщения - каждое сообщение содержит достаточно информации, чтобы понять, каким образом его обрабатывать. К примеру обработчик сообщения (parser) необходимый для извлечения данных может быть указана в списке MIME-типов
• Гипермедиа как средство изменения состояние приложения - Клиенты изменяют состояние системы только через действия, которые динамические определены в гипермедиа на сервере. Исключая простые точки входа в приложения, клиент не может предположить что для доступа какая-то операция над каким-то ресурсом, если не получил информации об этом в предыдущих запроса к серверу.

5. Слои

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

6. Код по требования (необязательное ограничение)

REST может позволить расширить функциональность клиента за счет загрузки кода с сервера в виде апплетов или скриптов.