Вольный перевод главы диссертации Roy Thomas Fielding "Representational State Transfer (REST)"
Representational State Transfer (REST)
Эта глава представляет и конкретизирует Representational State Transfer (REST) - архитектурный стиль для распределенных гипермедийных систем, описывает принципы разработки программного обеспечения, следуя REST, а также описывает ограничения взаимодействия для сохранения этих принципов, в то же время сопоставляя их с ограничениями других архитектурных стилей. REST - это гибридный стиль, полученный из описанных в третьей лаве архитектурных стилей и определяющий единый интерфейс соединителя коннектора в сочетании с дополнительными ограниченияеми. Структура архитектуры ПО из первой главы используется для определения архитектурных элементов REST изучения примеров просессов, коннекторов и представлений данных прототипных архитектур.
5.1 Процесс выведения REST
Обоснование проектирования, лежащее в основе веб архитектуры, может быть описано архитектурым стилем, который состоит из набора применяемых к элементам ограничений. Изучая влияние каждого ограничения по мере го добавления к развивающемуся стилю, мы может определять свойства, индуцированные ограничениями веба. Затем для формирования нового архитектурного стиля, который лучше отражает свойства современной веб архитектуры, могут быть применены дополнительные ограничения. Эта секция предоставляет общий обзор REST путём рассмотрения процесса выведения его как архитектурного стиля. Конкретные ограничения, из которых состоит REST, будут описаны в последующих разделах .
5.1.1 Начиная с Нулевого Стиля
Как для построек, так и для программного обеспечения существует два общих взгляда на процесс архитектурного проектирования. Первый: проектировщик начинает с пустого состояния, рисовальной или чертежной доски и, пока потребности предполагаемой системы не будут удовлетворены, выстраивает архитектуру из уже знакомых компонентов. Второй: проектировщик отталкивается от потребностей системы без ограничений, после чего постепенно определяет и применяет ограничения к её элементам, чтобы разграничить область проектирования и позволить силам, влияющим на поведение системы, течь естественным образом, в гармонии с системой. Первый взгляд подразумевает креативное и неограниченное видение, второй - сдержанность и понимание контекста нужной системы. REST был разработан с помощью последнего. Фигуры с 5-1 по 5-8 графически описывают, как примененные ограничения разграничивают процесс представления архитектуры в качестве инкрементального набора ограничений.
Нулевой стиль (Изображение 5-1) - это просто пустой набор ограничений. С точки зрения архитектуры, нулевой стиль описывает систему, в которой четкая граница между компонентами не установлена. Это начальная точка для нашего описания REST.
5.1.2 Клиент-сервер
Первыми добавленными к нашему гибридному стилю ограничениями будут ограничения клиент-серверного архитектурного стиля (Изображение 5-2), описанные в Секции 3.4.1. Принцип, лежащий в основе клиент-серверных ограничений, заключается в разделении интересов. Разделением интересов пользовательского интерфейса от интересов хранилища данных, мы улучшаем портативность пользовательского интерфейса на несколько платформ и улучшаем масшабируемость, упрощая серверные компоненты. Для веба наиболее важным, пожалуй, является то, что разделение позволяет компонентам развиваться независимо, тем самым поддерживая требования расширяемости интернета для нескольких организационных доменов.
5.1.3 Отсутствие состояния (Stateless)
Следующее ограничение клиент-серверного взаимодействия: коммуникация должна не иметь состояния по своей природе, следуя стилю client-stateless-server (CSS) из Секции 3.4.3 (Изображение 5-3), что подразумевает, что каждый запрос от клиента к серверу должен содержать всю необходимую для его понимания информацию и не может использовать хранящийся на сервере контекст. Потому состояние сессии полностью хранится на клиенте.
Это ограничение индуцирует свойства видимости, надежности и расширяемости. Видимость улучшается за счет того, что системе мониторинга не нужно выходить за пределы данных запроса, чтобы определить его полную природу. Надежность улучшается, потому что облегчается задача по восстановлению после частичных сбоев. Расширяемость улучшается, потому что отсуствие необходимости хранения состояния между запросами позволяет серверному компоненту быстрее освобождать ресурсы и еще больше упрощает реализацию, потому что серверу не приходится управлять использованием ресурсов между запросами.
Как и большинство архитектурных решений, ограничение в виде отсутствия состояния является компромиссом проектирования. Недостатком может быть то, что этот способ может снизить производительность сети из-за увеличения количества повторяющихся данных (per-interaction overhead), отправляемых в сериях запросов, поскольку эти данные нельзя оставлять на сервере в общем контексте. К тому же, хранение состояния приложения на стороне клиента уменьшает возможность контроля за поведением приложения со стороны сервера, поскольку приложение становится зависимым от правильности реализации семантики для нескольких версияй клиента.
5.1.4 Кэш
Для того, чтобы улучшить эффективность сети, мы добавляем ограничения кэша для формирования стиля client-cache-stateless-server из секции 3.4.4 (Изображение 5-4). Ограничения кэша требуют, чтобы данные внутри ответа на запрос были явно или неявно отмечены, как кэшируемые или некэшируемые. Если ответ кэшируемый - клиентскому кэшу дается право переиспользовать данные ответа для последующих эквивалентных запросов.
Преимущество от добавления ограничения кэша в том, что появляется возможность частично или полностью исключить некоторые взаимодействия за счет уменьшения средней задержки их серии, тем самым улучшая эффективность, расширяемость и воспринимаемую пользователем производительность. Компромисс, однако, заключается в том, что кэш может снизить надежность, если устаревшие данные в кэше значительно отличаются от данных, полученных при отправке запроса на непосредственно сервер.
Ранняя веб архитектура, как показано на изображении 5-5, определялась client-cache-stateless-server набором ограничений. Таким образом, для обмена статическими документами через интернет представленное для веб архитектуры до 1994 обоснование проектирования было сфокусировано на клиент-серверном взаимодействии без состояния. Протоколы для взаимного взаимодействия имели рудиментарную поддержку для кэшей без общего доступа, но не ограничивали интерфейс согласованным набором семантики для всех ресурсов. Вместо того, в вебе использовалась общая библиотека клиент-серверной реализации (CERN libwww) для обеспечения согласованности между веб приложениями.
Разработчики веб реализаций уже превзошли ранние методы проектирования. Кроме статических документов, запросы могли идентифицировать сервисы, которые динамически генерировали ответы, вроде image-maps [Кевин Хьюз] и server-side scripts [Роб МакКул]. Также была начата работа над промежуточными компонентами в виде прокси-серверов и общих кэшей, но для надежной связи те нуждались в расширених протоколов. Следующие разделы описывают ограничения, которые были добавлены к архитектурному стилю веба, для указания расширений, формирующих современную веб архитектуру.
5.1.5 Унифицированный интерфейс
Главной отличительной чертой REST стиля от остальных является, акцент на единый интерфейс между компонентами (Изображение 5-6). Применение такого принципа к интерфейсу компонент улучшает видимость взаимодействий и позволяет упростить архитектуру системы в целом. Реализации отделены от сервисов, которые они предоставляют, что способствует их независимому развитию. Компромисс в том, что унифицированный интерфейс снижает эффективность, поскольку информацию передается в стандартизированном виде, а не в виде, определенном под нужды приложения. Интерфейс REST был спроектирован для эффективной передачи крупного количества гипермедиа данных, частого случая в вебе, но не оптимален для других видов архитектурного взаимодействия.
Чтобы достчиь унифицированного интерфейса, на поведение компонентов должны быть наложены некоторые архитектурные ограничения. REST определяется четырьмя интерфейсными ограничениями: идентификация ресурсов; управление ресурсами через представления; самоописывающиеся сообщения; и гипермедиа, как двигатель состояния приложения. Эти ограничения будут обсуждены в секции 5.2.
5.1.6 Многоуровневая система
Для последующего улучшения поведения и требований расширяемости интернета, мы добавили ограчения уровневой системы (Изображение 5-7). Как описано в секции 3.4.2, уровневый системный стиль позволяет архитектуре состоять их иерархичных слоев путем особого поведения компонентов - каждый компонент не может "смотреть" за пределы уровня, с которым взаимодействует. Ограничивая знание о системе до одного уровня, мы обеспечиваем подложке незавимость и ограничиваем сложность системы в целом. Уровни могут быть использованы, чтобы оборачивать legacy сервисы и огорождать от них новые, упрощая компоненты за счет перемещения редкоиспользуемых функций в общий промежуточный уровень. Такие уровни также могут использоваться для улучшения расширяемости системы, обеспечивая балансировку нагрузки служб между несколькими сетями и процессорами.
Главным недостатом уровненой системы является то, что они увеличивают расходы и, соответстно, задержку при обработке данных, снижая воспринимаемую пользователем производительность. Для сетевой системы, поддерживающей ограничения кэширования, эти издержки можно компенсировать преимуществами общего кэширования в промежуточном уровне. Размещение общиъ кэшей на границах организационного домена может привести к значительному повышению производительности. Такие уровни также позволяют применять политики безопасности к данным, пересекающим эти границы, как того требуют файрволлы.
Комбинация многоуровневой системы и ограничений унифицированного интерфейса приводит архитектурные свойства к виду pipe-and-filter (секция 3.2.2). Хотя REST взаимодействие является двусторонним, потоки данных большого размера гипермедиа взаимодействия могут обрабатываться как сеть потоков данных с фильтрующими компонентами, выборочно примеяемыми к потокам для преобразования их содержимого. Внутри REST промежуточные компоненты могут активно преобразовывать содержимое сообщений, потому что сообщения самоописывающиеся и их семантика видна на промежуточных уровнях.
5.1.7 Код по требованию
Последним дополнением к нашему набору ограничений будет стиль code-on-demand из секции 3.5.3 (Изображение 5-8). REST позволяет клиенту расширяться функциональности клиента и выполнять код в виде апплетов или скриптов. Это упрощает клиентов, уменьшая количество необходимых для предварительной реализации фич. Благодаря возможности загрузки фич после деплоя, улучшается расширяемость системы. Однако, видимость также уменьшается, потому это ограничение внутри REST является опциональным.
Понятие опционального ограничения может показаться оксюмороном. Тем не менее, оно имеет предназначение при проектировании системы, охватывающей несколько организационных границ. Это значит, что, когда опциональное ограничение действует только для некоторой области системы, архитектура получает преимущество. Например, если все клиентское ПО внутри организации поддерживает Java-апплеты, то сервисы в этой организации могут быть сконструированы таким образом, чтобы они получали преимущества расширенной функциональности с помощью загружаемых классов Java. Однако, файрволл организации может не допустить передачу Java-апплетов из внешних источников, и, следовательно, для остальной части Интернета это будет выглядеть так, как будто эти клиенты не поддерживают код по требованию. Опциональное ограничение позволяет нам проетировать архитектуру, которая в общих случаях поддерживает желаемое поведение, но может быть отключена в некоторых контекстах.
5.1.8 Summary
REST состоит из набора рахитектурных ограничений, выбранных из-за присущих им свойст. В то же время, каждое из этих ограничений можно рассматривать отдельно, а описание их с точки зрения происхождения из общих архитектурных стилей облегчает понимание обоснования их выбора. Изображение 5-9 отображает ответвления ограничений REST в терминах сетевых архитектурных стилей, описанных в главе 3.
5.2 Архитектурные элементы REST
Стиль REST является абстракцией архитектурных элементов внутри распределенной гипермедийной системы. REST игнорирует детали реализации компонента и синтаксис протокола для лучшего фокусирования на ролях компонентов, их интерпретации значимых элементов данных, ограничений их взаимодействия с другими компонентами. REST охватывает фундаментальные ограничения компонентов, коннекторов и данных, которые определяют основу веб архитектуры и, таким образом, сущность его поведения как сетевого приложения.
5.2.1 Элементы данных
В отличие от распределенного объектного стиля, где все данные скрываются внутри компонентами обработки, природа и состояние архитектурных элементов данных - ключевой аспект REST. Обоснование такого проектирования можно увидеть в природе самих распределенных гипермедиа. Когда выбирается ссылка, информация должна переместиться из места хранения в место, где она будет использоваться пользователем. В отличие от многих других парадигм распределенной обработки, где возможно и обычно более эффективно перемещать сам «агент обработки» (например, мобильный код, хранимую процедуру, выражение поиска и т. д.) к данным, а не перемещать данные в процессор.
Распределенная гипермедийная архитектура имееть только три основных свойства: 1) отрисовка данных в месте их хранения и отправка получателю изображений фиксированного формата; 2) инкапсуляция данных с помощью рендер движка и отправка обоих получателю; 3) отправка raw данных получателю вместе с метаданными, описывающими тип данных, чтобы получатель мог выбрать свой собственный движок рендеринга.
Каждой свойство имеет как преимущества, так и недостатки. Первое свойство, традиционно клиент-серверного стиля, позволяет всей информации о настоящей природе данных оставаться скрытой внутри отправителя, упрощая реализацию клиента и предотвращая неточные суждения о структуре данных. Однако, оно также серьезно ограничивает возможности получателя и накладывает большую часть нагрузки на отправителя, что может привести к проблемам расширяемости. Второе свойство, стиля мобильного объекта, предоставляет сокрытие информации, позволяя особым образом обрабатывать данные с помощью уникального движка рендеринга, но ограничивает возможность получателя определить, чего нужно ожидать от движка рендеринга и может значительно увеличить объем передаваемых данных. Третье свойство позволяет отправителю оставаться простым и расширяемым, минимизируя передаваемые байты, но теряет преимущества сокрытия информации и обязывает отправителя и получателя понимать одинаковые типы данных.
REST предоставляет гибрид этих трех свойств, фокусируясь на совместном понимании типов данных с метаданными, но ограничивает объем раскрываемых для стандартизированного интерфейса данных. REST компоненты взаимодействую между собой путем передачи представления ресурса в формате, соответсвующем одному из развивающихся наборов стандартных типов данных, отобранных динамически на основе природы самого ресурса и возможностей или требований получателя. Представление будет скрываться за интерфейсом внезавимости от того, находится ли оно в том же формате, что и необработанный источник, или получено из него. Преимущества стиля мобильного объекта достигаются посредством отправки представления, состоящего из инструкций в стандартном формате данных инкапсулированного движка рендеринга (например, как в Java). Потому REST достигает разделения интересов клиент-серверного стиля, не мешая расширяемости системы, и позволяет скрывать информацию через основной интерфейс, чтобы обеспечить инкапсуляцию и эволюцию сервисов, и обеспечивает разнообразный набор функций через загружаемые движки.
Элементы данных REST обобщены в таблице 5-1.
5.2.1.1 Ресурсы и идентификаторы ресурса
Ключевой асбтракцией информации в REST является ресурс. Любая информация, которая может быть названа, может являться ресурсом: документ или изображение, временный сервис (например, "погода в Лос Анджелес на сегодня"), коллекция других ресурсов, невиртуальный объект (например, человек) и так далее. Другими словами, любой концепция, которая может быть целью гипертекстовой ссылки автора, должна попадать под определение ресурса. Ресурс - это концептуальное отображение набора сущностей, а не сущности, которая соответствует сопоставлению в любой конкретный момент времени.
Точнее, ресурс R является изменяющейся функцией M*R(t), которая за время *t mapsотображает набор сущностей или значений, который эквивалентны. Значения в наборе могут быть представлениями ресурсов и/или идентификаторами ресурсов. Ресурс может отображаться на пустой набор, который позволяет создавать ссылки на концепцию перед любой реализацией этой концепции - понятие, которое было чуждо большинству гипертекстовых систем до появления веба. Некоторые ресурсы являются статическими в том смысле, что при рассмотрении в любое время после их создания они всегда соттветствуют одному и тому же набору значений. Другие имеют высокую степень расхождений в занчениях с тчечением времени. Единственное, что требуется для статинчости ресурса - семантика, поскольку именно она отличает один ресурс от другого.
Например, "предпочтительной версией авторов" академической статьи является отображение, значение которого меняется со временем, тогда как "статьи, опубликованные в материалах конференции X" статичны. Это два разных ресурса, даже если они оба отображают одно и то же значение в определенный момент времени. Различие необходимо для того, чтобы оба ресурса можно было идентифицировать и ссылаться независимо. Аналогичным примером из разработки будет являться раздельный идентификатор файла исходного кода с управлением версиями при образении к "последней версии", "версии 1.2.7" или "версии, включенной в релиз Orange".
Это абстрактное определение ресурса включает ключевые особенности веб архитектуры. Первое: оно обеспечивает универсальность, охватывая множество источников информации без искусственного их различения по типу или реализации. Второе: оно допускает позднюю привязку ссылки к представлению, позволяя осуществлять согласование содержимого на основе характеристик запроса. И, наконец, позволяет автору ссылаться на концепцию, а не на какое-то единичное представление этой концепции, тем самым устраняя необходимость менять все существующие ссылки при изменении представления (при условии, что автор использовал правильный идентификатор).
REST использует идентификатор ерсурса для идентификации конкретного ресурса, участвующего во взаимодействии между компонентами. REST коннекторы предоставляют общий интерфейс для доступа к набору значений ресурса и манипулирования им независимо от того, как определена функция членства или от типа программного обеспечения, которое обрабатывает запрос. Инструмент, который назначил идентификатор ресурса, позволяющий ссылаться на ресурс, отвечает за поддержание семантической достоверности отображения с течением времени (т.е. гарантирует, что функция членства не изменяется).
Традиционные гипертекстовые системы, которые обычно действуют в закрытых или локальных окружениях, используеют уникальные идентификаторы узов или документов, которые изменяются сразу после изменения информации, полагаясь на серверы ссылок, чтобы поддреживать отдельно ссылки от контента. Поскольку централизованные серверы ссылок - это анафема для огромного масштаба и многопрофильных сетевых требований, вместо этого REST полагается на то, что автор выбирает идентификатор ресурса, который наилучшим образом соответствует природе идентифицируемой концепции. Естественно, качество идентификатора часто пропорционально сумме денег, потраченной на сохранение его валидности, что приводит к разрыву ссылок, когда эфемерная (или плохо поддерживаемая) информация перемещается или исчезает со временем.
5.2.1.2 Представления
REST компоненты выполняют действия с ресурсом, используя представление для захвата текущего или предполагаемого состояния этого ресурса и передачи этого представления между компонентами.. Представление - это последовательность байтов плюс метаданные представления для их описания. Другие часто используемые, но менее точные имена для представления включают: документ, файл, и экземпляр или сущность HTTP сообщения.
Представление состоит из данных, метаданных, описывающих данные, и, иногда, метаданных для описания метаданных (обычно для проверки целостности сообщения). Метаданные представлены в форме пар имя-значение, где имя соответствует стандарту, который определяет структуру и семантику значения. Сообщения ответов могут включать как метаданные представления, так и метаданные ресурса: информацию о ресурсе, которая не является специфичной для поставляемого представления.
Между компонентами управляющие данные определяют цель сообщения, например запрашиваемое действие или значение ответа. Он также используется для параметризации запросов и переопределения поведения некоторых дефолтных соединительных элементов. Например, поведение кэша может быть изменено управляющими данными, включенными в сообщение запроса или ответа.
В зависимости от данных управления сообщениями данное представление может указывать текущее состояние запрошенного ресурса, желаемое состояние запрошенного ресурса или значение некоторого другого ресурса, такого как представление входных данных в форме запроса клиента, или представление некоторого состояния ошибки для ответа. Например, удаленная разработка ресурса требует, чтобы автор отправлял представление на сервер, устанавливая таким образом значение для этого ресурса, которое может быть получено последующими запросами. Если набор значений ресурса в данный момент времени состоит из нескольких представлений, согласование контента может использоваться для выбора наилучшего представления для включения в данное сообщение.
Формат данных представления известен как медиа тип. Представление может быть включено в сообщение и обработано получателем в соответствии с контрольными данными сообщения и характером типа носителя. Некоторые типы мультимедиа предназначены для автоматической обработки, некоторые предназначены для просмотра пользователем, а некоторые способны на оба. Составные типы мультимедиа могут использоваться для включения нескольких представлений в одно сообщение.
Конструкция мультимедийного типа может напрямую влиять на воспринимаемую пользователем производительность распределенной гипермедиа-системы. Любые данные, которые должны быть получены до того, как получатель сможет начать рендеринг, увеличивают задержку взаимодействия. Формат данных, который помещает наиболее важную информацию рендеринга вперед, так что исходная информация может быть постепенно увеличена, пока остальная информация принимается, приводит к гораздо лучшей воспринимаемой пользователем производительности, чем формат данных, который должен быть полностью получен до рендеринг может начаться.
Например, веб-браузер, который может постепенно визуализировать большой HTML-документ во время его получения, обеспечивает значительно лучшую воспринимаемую пользователем производительность, чем та, которая ожидает, пока весь документ полностью не будет получен перед рендерингом, даже если производительность сети одинакова. Обратите внимание, что на возможность визуализации представления также может повлиять выбор контента. Если размеры динамически изменяемых таблиц и встроенных объектов должны быть определены до того, как они могут быть отображены, их появление в области просмотра страницы гипермедиа увеличит ее задержку.
5.2.2 Коннекторы
REST использует различные типы коннекторов, приведенные в таблице 5-2, для инкапсулирования доступа к ресурсам и передачи их представлений. Коннекторы представляют собой абстрактный интерфейс для взаимодействия компонентов, упрощая его четким разделением проблем и сокрытием базовой реализации ресурсов и механизма связи. Универсальность интерфейса также обеспечивает заменяемость: если пользователь имеет доступ к системе только с помощью абстрактного интерфейса, реализация омжет быть заменена без влияния на пользователей. Поскольку коннектор управляет сетевым взаимодействием для компонента, информация может быть доступна через несколько взаимодействий для улучшения эффективности и отзывчивости.
Все REST взаимодействия не имею состояния. То есть, каждый запрос содержит всю необходимую информацию для того, чтобы коннектор понял запрос вне зависимости от любых запросов, которые могли предшествовать ему. Это ограничение выполняет четыре функции: 1) устраняет необходимость коннекторам сохранять состояние между запросами, что, тем самым, сокращает потребление физических ресурсов и улучшает расширяемость; 2) позволяет обрабатывать взаимодействия параллельно, не требуя, чтобы механизм обработки понимал семантику взаимодействия; 3) позволяет посреднику просматривать и понимать запрос изолированно, что может быть необходимо, если сервисы перестраиваются динамически; и 4) заставляет всю информацию, которая может влиять на переиспользуемость кэшированного ответа присутствовать в каждом запросе.
Интерфейс коннектора аналогичен процедурному вызову, но с несколькими важными различиями в передаче параметров и результатов. Входные параметры состоят из данных управления запросом, идентификатора указывающего на цель запроса ресурса и необязательного представления, выходные - из данных управления ответом, необязательных метаданных ресурса и необязательного представления. С абстрактной точки зрения вызов является синхронным, но оба вида параметров могут передаваться как потоки данных. Другими словами, обработка может вызываться перед тем, как значения параметров будут известны полностью, что позволяет избегать задержек пакетной обработки больших передач данных.
Основными типами коннектора является клиент и сервер. Существенная разница между этимти двумя в том, что клиент, отправляя запрос, инициирует взаимодействие, а сервер прослушивает соединения и отвечает на запросы. Компонент может содержать коннекторы как клиента, так и сервера.
Третий тип коннетора - коннектор кэша - может располагаться на интерфейсе клиента или сервера для сохранения кэшируемых ответов на текущие взаимодействия, чтобы их можно было повторно использовать для последующих запрошенных взаимодействий. Кэш может использоваться клиентом для избежания повторного сетевого взаимодействия, или сервером для избежания птовроного процесса генерации ответа, причем оба случая служат для уменьшения задержки взаимодействия. Кэш обычно реализуется в адресном пространстве соединителя, которые его использует.
Некоторые кэш коннекторы являются общими, что означает, что его кэшированные ответы могут использоваться в ответе клиенту, отличному от того, для которого ответ был получен первоначально. Такое совместное кэширование может быть эффективным для снижения влияния "flash crowds" на нагруженный сервер, особенно когда кэширование организовано иерархически для охвата больших групп пользователей, таких как пользователи внутренней сети компании, клиенты интернет-услуг, провайдера или университеты, разделяющие магистраль национальной сети. Однако, совместное кэширование также может приводить к ошибкам, если кэшированный ответ не совпадает с тем, что было бы получено новым запросом. REST пытается сбалансировать стремление к прозрачности в поведении кэша со стремлением к эффективнмоу использованию сети, а не предполагать, что абсолютная рпозрачность требуется всегда.
Кэш может определять кэшируемость запроса, поскольку интерфейс является общим, а не специфическим для каждого ресурса. По умолчанию, ответ на запрос поиска кэшируется, а ответы на другие запросы нет. Если какая-либо форма аутентификации пользователя является частью запроса, или если ответ указывает, что он не должен использоваться совместно, тогда ответ может быть кэширован только в кэш общего пользования. Компонент может переопределять эти значения по умолчанию, включив управляющие данные которые помечают взаимодействие как кэшируемое, не кэшируемое или кэшируемое только в течение ограниченного времени.
Средство распознавания преобразует частичные или полные идентификаторы ресурса в информацию о сетевом аддресе, необходимую для устноавления межкомпонентного соединения. например, большинство URI включают в себя имя хоста DNS в качетсве механизма идентификации полномочий ресурса по его именованию. Чтобы инициировать запрос, веб браузер извлечет имя хоста из URI и использует распознаватель DNS для получения адреса интернет-протокола. Другой пример: некоторые схемы идентификации (например, URN) требуют, чтобы посредник преобразовывал постоянный идентификатор в более переходный адрес для доступа к идентифицированному ресурсу. Использование одного или нескольких промежуточных распознавателей может увеличить долговечность ссылок на ресурсы за счет косвенного обращения, хотя это увеличить задержку запроса.
Последним типом коннектора является туннель, который просто передает взаимодействия через границу соединения, такую как межсетевой экран или сетевой шлюз более низкого уровня. Единственная причина, по которой он моделируется как часть REST и не абстрагируется как часть сетевой инфраструктуры, в том, что некоторые REST компоненты из поведения активного компонента на поведение туннеля могут переключаться динамически. Основным примером является HTTP прокси, который переключается на туннель в ответ на метод CONNECT запроса, что позволяетс его клиенту напрямую связываться с удаленным сервером используя другом протокол, такой как TLS, который не допускает прокси. Такой туннель исчезает, когда оба конца соединения прекращают связь.
5.2.3 Компоненты
REST компнонеты, выведенные в таблице 5-3, типизируются на основе принимаемых ими ролей в событиях приложения.
User agent использует клиентский коннектор для инициирования запроса и становится окончательным его получателем. Основной пример - веб браузер, который предоставляет доступ к информационным сервисам и отрисовывает ответы сервисов в соответсвии с потребностями приложения.
Origin server использует серверный коннектор для управления пространством имен для запрашиваемого ресурса. Является окончательным источником для представления своих ресурсов и должен быть окончательным получаетел любого запроса, если тот требует изменения значений своих ресурсов. Каждый origin server предоставляет общий интерфейс для своих сервисов в виде иерархии ресурсов. Детали реализации ресурса сокрыты за интерфейсом.
Для пересылки запросов и ответов промежуточные компоненты ведут себя и как клиент, и как сервер. Компонент proxy является посредником, выбранным клиентом для обеспечения интерфейса инкапсуляции для своих сервисов, трансляции данных, повышения производительности и защиты безопасности. Шлюзовый (a.k.a., reverse proxy) компонент - посредник, навязанный сетевым или исходным сервером для обеспечения инкапсуляции интерфейса других служб, для перевода данных, повышения производительности или обеспечения безопасности. Заметьте, что разница между proxy и шлюзом в том, что клиенту нужно явно определить, когда ему нужно использовать proxy.
5.3 Архитектурные представления REST
Теперь, когда у нас есть понимание архитектурных элементов REST в отдельности, мы можем использовать архитектурные представления, чтобы описать, как элементы работают вместе, чтобы сформировать архитектуру. Три типа представлений - процесс, коннектор и данные - полезны для освещения принципов проектирования REST.
5.3.1 Представление процесса
Процессное представление архитектуры в первую очередь эффективно для выявления взаимосвязей взаимодействия между компонентами, показывая путь данных, когда они проходят через систему. Процессное представление архитектуры в первую очередь эффективно для выявления взаимосвязей взаимодействия между компонентами, показывая путь данных, когда они проходят через систему. На изображении 5-10 приведен пример представления процесса из архитектуры на основе REST в конкретном случае во время обработки трех параллельных запросов.
Разделение интересов клиента и сервера REST упрощает реализацию компонентов, снижает сложность семантики коннекткоров, повышает эффективность настройки производительности и масштабируемость компонентов чистого сервера. Многоуровневые системные ограничения позволяют вводить посредников - прокси, шлюзы и межсетевые экраны - в различных точках обмена данными, не изменяя интерфейсы между компонентами, что позволяет им помогать в преобразовании обмена данными или повышать производительность посредством крупномасштабного общего кэширования. REST позволяет выполнять промежуточную обработку, ограничивая сообщения для самоописания: взаимодействие не требует состояния между запросами, стандартные методы и типы мультимедиа используются для указания семантики и обмена информацией, а ответы явно указывают на кешируемость.
Поскольку компоненты подключаются динамически, их расположение и функции для конкретного действия приложения имеют характеристики, аналогичные стилю конвейера (pipe) и фильтра. Хотя компоненты REST обмениваются данными через двунаправленные потоки, обработка каждого направления независима и поэтому восприимчива к преобразователям потока (фильтрам). Общий интерфейс соединителя позволяет размещать компоненты в потоке на основе свойств каждого запроса или ответа.
Сервисы могут быть реализованы с использованием сложной иерархии посредников и нескольких серверов распределенного происхождения. Природа REST без сохранения состояния позволяет каждому взаимодействию быть независимым от других, устраняя необходимость в понимании общей топологии компонентов, невыполнимую задачу для архитектуры масштаба веба и позволяя компонентам выступать в качестве пунктов назначения или посредников, определяемых динамически по цели каждого запроса. Коннекторы должны знать о существовании друг друга только во время их взаимодействия, хотя они могут кэшировать существование и возможности других компонентов по соображениям производительности.
5.3.2 Представление коннектора
Представление архитектуры соединителя концентрируется на механике связи между компонентами. Для архитектуры на основе REST нас особенно интересуют ограничения, которые определяют общий интерфейс ресурсов.
Клиентские коннекторы проверяют идентификатор ресурса, чтобы выбрать подходящий механизм связи для каждого запроса. Например, клиент может быть сконфигурирован для соединения с конкретным прокси-компонентом, возможно, таким, который действует как фильтр аннотаций, когда идентификатор указывает, что это локальный ресурс. Аналогично, клиент может быть настроен на отклонение запросов для некоторого подмножества идентификаторов.
REST не ограничивает связь конкретным протоколом, но ограничивает интерфейс между компонентами и, следовательно, дополняет область предположений о взаимодействии и реализации, которые могли бы быть сделаны между компонентами. Например, основным протоколом передачи в Интернете является HTTP, но в архитектуру также входит беспрепятственный доступ к ресурсам, которые создаются на уже существующих сетевых серверах, включая FTP, Gopher и WAIS. Взаимодействие с этими службами ограничено семантикой коннектора REST. Это ограничение жертвует некоторыми из преимуществ других архитектур, таких как взаимодействие с состоянием протокола обратной связи по релевантности, такого как WAIS, чтобы сохранить преимущества единого универсального интерфейса для семантики коннектора. В свою очередь, общий интерфейс позволяет получить доступ к множеству сервисов через один прокси. Если приложению требуются дополнительные возможности другой архитектуры, оно может реализовать и вызвать эти возможности как отдельную систему, работающую параллельно, подобно тому, как веб-архитектура взаимодействует с ресурсами "telnet" и "mailto".
5.3.3 Представление данных
Представление данных раскрывает состояние приложения при прохождении информации через компоненты. Поскольку REST специально нацелен на распределенные информационные системы, он рассматривает приложение как связную структуру информации и альтернатив управления, с помощью которых пользователь может выполнять желаемую задачу. Например, поиск слова в онлайн-словаре - это одно из приложений, как, например, путешествие по виртуальному музею или просмотр набора заметок для подготовки к экзамену. Каждое приложение определяет цели для базовой системы, по которым можно измерить производительность системы.
Взаимодействие компонентов происходит в форме сообщений динамического размера. Сообщения малого или среднего размера используются для семантики управления, но основная часть работы приложения выполняется через сообщения большого размера, содержащие полное представление ресурса. Наиболее частой формой семантики запроса является извлечение представления ресурса (например, метода «GET» в HTTP), который часто можно кэшировать для последующего повторного использования.
REST концентрирует все состояние управления в представлениях, полученных в ответ на взаимодействия. Цель состоит в том, чтобы повысить расширяемость сервера, устраняя необходимость для сервера поддерживать осведомленность о состоянии клиента за пределами текущего запроса. Поэтому состояние приложения определяется его ожидающими запросами, топологией подключенных компонентов (некоторые из которых могут быть фильтрацией буферизованных данных), активными запросами на этих коннекторах, потоком данных представлений в ответ на эти запросы и обработкой этих представления, как они получены агентом пользователя.
Приложение достигает устойчивого состояния, когда у него нет невыполненных запросов; то есть он не имеет ожидающих запросов, и все ответы на его текущий набор запросов были полностью получены или получены до такой степени, что их можно рассматривать как поток данных представления. Для приложения браузера это состояние соответствует «веб-странице», включающей первичное представление и вспомогательные представления, такие как встроенные изображения, встроенные апплеты и таблицы стилей. Важность стационарных состояний приложений проявляется в их влиянии как на воспринимаемую пользователем производительность, так и на интенсивность трафика сетевых запросов.
Воспринимаемая пользователем производительность приложения браузера определяется задержкой между установившимися состояниями: периодом времени между выбором гипермедиа-ссылки на одной веб-странице и моментом представления полезной информации для следующей веб-страницы. Поэтому оптимизация производительности браузера сосредоточена на уменьшении этой задержки связи.
Поскольку основанные на REST архитектуры обмениваются данными главным образом посредством передачи представлений ресурсов, на задержку могут влиять как структура протоколов связи, так и конструкция форматов данных представления. Возможность постепенной визуализации данных ответа по мере их получения определяется конструкцией типа носителя и доступностью информации макета (визуальные размеры встроенных объектов) в каждом представлении.
Важное наблюдение: наиболее эффективный сетевой запрос - это тот, который не использует сеть. Другими словами, возможность многократного использования кэшированного ответа приводит к значительному улучшению производительности приложения. Хотя использование кэша добавляет некоторую задержку к каждому отдельному запросу из-за накладных расходов на поиск, средняя задержка запроса значительно уменьшается, когда даже небольшой процент запросов приводит к используемым обращениям к кешу.
Следующее состояние управления приложением находится в представлении первого запрошенного ресурса, поэтому получение этого первого представления является приоритетом. Поэтому взаимодействие REST улучшается с помощью протоколов, которые «сначала отвечают, а потом думают». Другими словами, протокол, который требует множественных взаимодействий для каждого действия пользователя, для того, чтобы выполнить такие вещи, как согласование возможностей функции перед отправкой ответа на контент, будет значительно медленнее, чем протокол, который сначала отправляет то, что наиболее вероятно будет оптимальным, а затем обеспечивает список альтернатив, которые клиент может получить, если первый ответ неудовлетворителен.
Состояние приложения контролируется и сохраняется пользовательским агентом и может состоять из представлений от нескольких серверов. В дополнение к освобождению сервера от проблем расширяемости сохранения состояния, это позволяет пользователю напрямую манипулировать состоянием (например, историей веб-браузера), предвидеть изменения в этом состоянии (например, карты ссылок и предварительную выборку представлений) и выполнять переход из одного приложения в другое (например, закладки и диалоги ввода URI).
Следовательно, модельное приложение представляет собой механизм, который перемещается из одного состояния в другое путем изучения и выбора среди альтернативных переходов состояний в текущем наборе представлений. Не удивительно, что это точно соответствует пользовательскому интерфейсу гипермедиа браузера. Однако стиль не предполагает, что все приложения являются браузерами. Фактически, детали приложения скрыты от сервера с помощью универсального интерфейса коннектора, и, таким образом, пользовательский агент может в равной степени быть автоматическим роботом, выполняющим поиск информации для службы индексирования, личным агентом, который ищет данные, которые соответствуют определенным критериям, или обслуживанием. Паук занят патрулированием информации на предмет неработающих ссылок или измененного контента.
Top comments (0)