Знакомьтесь, архитектура REST

Передача состояния представления (Representational State Transfer (REST)) — это стиль архитектуры программного обеспечения для распределенных гипермедиа систем, подобных Всемирной паутине. REST иллюстрирует развитие архитектуры Web, характеризуя и регулируя макровзаимодействие четырёх компонентов Web, а именно серверов происхождения, сетевых шлюзов, прокси и клиентов, без применения ограничений к индивидуальным участникам. Таким образом, REST по существу определяет правильное поведение участников.

Концепция

Архитектура в стиле REST состоит из клиентов и серверов. Клиенты инициируют запросы к серверам; серверы обрабатывают запросы и возвращают подходящие ответы. Запросы и ответы создаются на базе передачи представлений ресурсов.

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

Ограничения

Архитектурный стиль REST описывает следующие шесть ограничений, налагаемых на архитектуру, оставляя реализацию индивидуальных компонентов свободной:

Технология «клиент-сервер» - Клиенты отделены от сервера единым интерфейсом. Это разделение ответственности означает, например, что клиенты не отвечают за хранилище данных, являющееся внутренним для каждого сервера, так что переносимость кода клиента улучшается. Серверы не отвечают за пользовательский интерфейс или пользовательское состояние, поэтому серверы могут быть проще и более масштабируемыми. Серверы и клиенты могут разрабатываться и заменяться независимо, пока не изменится интерфейс.
Без состояния - Взаимодействие клиент-сервер ограничивается далее отсутствием сохранения контекста клиента на сервере между запросами. Каждый запрос от любого клиента содержит всю информацию, необходимую для его обслуживания, а любое состояние сессии хранится в клиенте. Сервер может быть с состоянием; это ограничение требует, чтобы состояние на стороне сервера было адресуемо через URL как ресурс. Это не только делает серверы более видимыми для мониторинга, но и делает их более надежными в случае частичного отказа сети, а также дополнительно улучшает их масштабируемость.
Кэшируемость - клиенты могут кэшировать ответы. Поэтому ответы должны, явно или неявно, определять себя кэшируемыми или нет, чтобы предотвратить использование клиентом старые или неподходящие данные при ответе на следующие запросы. Хорошо управляемое кэширование частично или полностью устраняет некоторые взаимодействия клиента и сервера, повышая далее масштабируемость и производительность.
Многоуровневая система - Клиент не может однозначно определить, подключается ли он непосредственно к серверу или к посреднику по пути подключения. Посредник сервера может улучшить масштабируемость системы, обеспечивая балансировку нагрузки и обеспечивая общий кэш. Он может также потребовать соблюдения политики безопасности.
Код по требованию (опционально) - Серверы могут временно расширить или настроить функциональность клиента, передавая ему исполняемую логику. Примерами этого могут служить скомпилированные компоненты, такие как Java-апплеты и клиентские сценарии, такие как JavaScript.
Единый интерфейс - Единый интерфейс между клиентами и серверами, обсуждаемый ниже, упрощает и разделяет архитектуру, позволяя каждой части развиваться самостоятельно. Четыре руководящих принципа такого интерфейса подробно описаны ниже.

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

Соблюдение этих ограничений, и, следовательно, соответствие архитектурному стилю REST, позволит любой распределенной системе гипермедиа иметь требуемые свойства, такие как производительность, масштабируемость, простота, модифицируемость, видимость, мобильность и надежность.

Ключевые цели REST включают:

Масштабируемость взаимодействия компонентов
Общность интерфейсов
Независимое внедрение компонентов
Промежуточные компоненты, снижающие задержку, усиливающие безопасность и инкапсулирующие устаревшие системы

Основной принцип

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

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

RESTful веб-службы

RESTful веб-служба (также называемая RESTful web API) — это простая веб-служба, реализованная с использованием HTTP и принципов REST. Она представляет собой набор ресурсов с тремя определенными аспектами:

базовый URI для веб-службы, например http://example.com/resources/
тип содержимого Интернет для данных, поддерживаемых веб-службой. Часто это JSON, XML или YAML, но можно использовать любой другой действительный тип содержимого Интернет.
множество операций, поддерживаемых веб-службой, используя основные механизмы протокола (то есть, POST, GET, PUT или DELETE).

Сравнительная таблица SOAP и REST

Просмотров: 33132 | Дата публикации: 09.01.2012