Изобразительное State Transfer

редактировать
Это последняя принятая редакция, обзор по 9 октября 2021 года. "REST" перенаправляется сюда. Чтобы узнать о других значениях, см. Отдых.

Передача репрезентативного состояния ( REST) - это стиль архитектуры программного обеспечения, который был создан для руководства проектированием и разработкой архитектуры для World Wide Web. REST определяет набор ограничений того, как должна вести себя архитектура распределенной гипермедийной системы Интернет- масштаба, такой как Интернет. Архитектурный стиль REST подчеркивает масштабируемость взаимодействий между компонентами, единообразные интерфейсы, независимое развертывание компонентов и создание многоуровневой архитектуры для облегчения кэширования компонентов для уменьшения задержки, воспринимаемой пользователем, обеспечения безопасности и инкапсуляции устаревших систем.

REST используется во всей индустрии программного обеспечения и представляет собой широко признанный набор руководящих принципов для создания надежных веб-API без сохранения состояния. Веб-API, который подчиняется ограничениям REST, неофициально описывается как RESTful. Веб-API RESTful обычно основаны на методах HTTP для доступа к ресурсам через параметры в кодировке URL и использовании JSON или XML для передачи данных.

«Веб-ресурсы» впервые были определены во всемирной паутине как документы или файлы, идентифицируемые по их URL-адресам. Сегодня это определение является гораздо более общим и абстрактным и включает в себя каждую вещь, сущность или действие, которые могут быть идентифицированы, названы, адресованы, обработаны или выполнены каким-либо образом в сети. В веб-службе RESTful запросы к URI ресурса вызывают ответ с полезными данными, отформатированными в HTML, XML, JSON или другом формате. Например, ответ может подтвердить, что состояние ресурса было изменено. Ответ также может включать гипертекстовые ссылки на связанные ресурсы. Наиболее распространенным протоколом для этих запросов и ответов является HTTP. Он предоставляет операции ( методы HTTP ), такие как GET, POST, PUT и DELETE. Используя протокол без сохранения состояния и стандартные операции, системы RESTful стремятся к быстрой производительности, надежности и возможности роста за счет повторного использования компонентов, которыми можно управлять и обновлять, не затрагивая систему в целом, даже во время ее работы.

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

СОДЕРЖАНИЕ
  • 1 Этимология
  • 2 История
  • 3 Архитектурные концепции
  • 4 Архитектурные особенности
  • 5 Архитектурные ограничения
    • 5.1 Клиент-серверная архитектура
    • 5.2 Безгражданство
    • 5.3 Кэшируемость
    • 5.4 Многоуровневая система
    • 5.5 Код по запросу (необязательно)
    • 5.6 Единый интерфейс
  • 6 классификационные модели
  • 7 Применяется к веб-сервисам
    • 7.1 Семантика HTTP-методов
    • 7.2 Обсуждение
  • 8 См. Также
  • 9 ссылки
  • 10 Дальнейшее чтение
Этимология

Термин « репрезентативный государственный переход» был введен и определен в 2000 году Роем ​​Филдингом в его докторской диссертации. Этот термин призван вызвать образ поведения хорошо спроектированного веб-приложения: это сеть веб-ресурсов (виртуальный конечный автомат ), в которой пользователь перемещается по приложению, выбирая ссылки (например, http: //www.example.com / article / 21), в результате чего следующее представление ресурса (следующее состояние приложения) передается клиенту и отображается для пользователя.

История
Рой Филдинг выступает на OSCON 2008

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

Вместе W3C и IETF рабочих групп, начали работу по созданию формальных описаний три основных стандартов Интернета: URI, HTTP и HTML. Рой Филдинг принимал участие в создании этих стандартов (в частности, HTTP 1.0 и 1.1 и URI), и в течение следующих шести лет он разработал архитектурный стиль REST, проверяя его ограничения на стандарты протокола Интернета и используя его как средство для определения архитектурные улучшения - и выявление архитектурных несоответствий. Филдинг определил REST в своей докторской диссертации 2000 г. «Архитектурные стили и проектирование сетевых архитектур программного обеспечения» в Калифорнийском университете в Ирвине.

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

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

Архитектурные решения
Модель сущности-отношения концепций, выраженных в архитектурном стиле REST.

Архитектурный стиль REST разработан для сетевых приложений, в частности приложений клиент-сервер. Но более того, он разработан для использования в масштабе Интернета, поэтому связь между пользовательским агентом (клиентом) и исходным сервером должна быть как можно более легкой (слабой), чтобы облегчить широкомасштабное внедрение. Это достигается путем создания уровня абстракции на сервере путем определения ресурсов, которые инкапсулируют сущности (например, файлы) на сервере и, таким образом, скрывают основные детали реализации (файловый сервер, база данных и т. Д.). Но определение еще более общее: любая информация, которой можно дать имя, может быть ресурсом: изображением, запросом к базе данных, временной службой (например, «сегодняшняя погода в Лондоне») или даже набором других ресурсов. Такой подход обеспечивает максимальную функциональную совместимость между клиентами и серверами в долговременной среде масштаба Интернета, которая пересекает организационные (доверительные) границы.

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

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

Архитектурные свойства

Ограничения архитектурного стиля REST влияют на следующие архитектурные свойства:

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

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

Формальные ограничения REST следующие:

Клиент-серверная архитектура

См. Также: Модель клиент – сервер.

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

Безгражданство

См. Также: Протокол без сохранения состояния

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

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

См. Также: Веб-кеш

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

Многослойная система

См. Также: Многоуровневая система

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

Код по запросу (необязательно)

См. Также: Клиентские сценарии

Серверы могут временно расширять или настраивать функциональные возможности клиента, передавая исполняемый код: например, скомпилированные компоненты, такие как апплеты Java, или сценарии на стороне клиента, такие как JavaScript.

Единый интерфейс

Единообразное ограничение интерфейса является фундаментальным для проектирования любой системы RESTful. Он упрощает и разделяет архитектуру, что позволяет каждой части развиваться независимо. Четыре ограничения для этого унифицированного интерфейса:

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

Было разработано несколько моделей, помогающих классифицировать REST API в соответствии с их приверженностью различным принципам проектирования REST, например, модели зрелости Ричардсона.

Применяется к веб-сервисам

API-интерфейсы веб-служб, которые соответствуют архитектурным ограничениям REST, называются API-интерфейсами RESTful. API-интерфейсы RESTful на основе HTTP определяются со следующими аспектами:

  • базовый URI, например http://api.example.com/;
  • стандартные методы HTTP (например, GET, POST, PUT и DELETE);
  • а медиа - типа, который определяет состояния переходных элементов данных (например, атом, микроформаты, применение / vnd.collection + JSon и т.д.). Текущее представление сообщает клиенту, как составлять запросы на переходы ко всем следующим доступным состояниям приложения. Это может быть как простой URI, так и сложный, как Java-апплет.

Семантика HTTP-методов

В следующей таблице показано, как методы HTTP предназначены для использования в API HTTP, включая RESTful.

Семантика HTTP-методов
HTTP метод Описание
ПОЛУЧАТЬ Получите представление о состоянии целевого ресурса.
ПОЧТА Позвольте целевому ресурсу обработать представление, заключенное в запросе.
ПОЛОЖИЛ Создайте или замените состояние целевого ресурса на состояние, определенное представлением, включенным в запрос.
УДАЛЯТЬ Удалите состояние целевого ресурса.

Метод GET безопасен, это означает, что его применение к ресурсу не приводит к изменению состояния ресурса (семантика только для чтения). Методы GET, PUT и DELETE являются идемпотентными, что означает, что их многократное применение к ресурсу приводит к тому же изменению состояния ресурса, что и однократное их применение, хотя ответ может отличаться. Методы GET и POST кэшируются, что означает, что ответы на них могут быть сохранены для повторного использования в будущем.

Обсуждение

В отличие от веб-сервисов на основе SOAP, для веб-API RESTful не существует «официального» стандарта. Это потому, что REST - это архитектурный стиль, а SOAP - это протокол. REST сам по себе не является стандартом, но реализации RESTful используют такие стандарты, как HTTP, URI, JSON и XML. Многие разработчики описывают свои API как RESTful, хотя эти API не удовлетворяют всем архитектурным ограничениям, описанным выше (особенно ограничению унифицированного интерфейса).

Смотрите также
использованная литература
дальнейшее чтение
Последняя правка сделана 2023-03-27 05:42:54
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте