Передача репрезентативного состояния ( REST ) - это стиль архитектуры программного обеспечения, который был создан для руководства проектированием и разработкой архитектуры для World Wide Web . REST определяет набор ограничений того , как должна вести себя архитектура распределенной гипермедийной системы Интернет- масштаба , такой как Интернет. Архитектурный стиль REST подчеркивает масштабируемость взаимодействий между компонентами, единообразные интерфейсы , независимое развертывание компонентов и создание многоуровневой архитектуры для облегчения кэширования компонентов, чтобы уменьшить воспринимаемое пользователемзадержка , обеспечение безопасности и инкапсуляция устаревших систем . [1] REST используется во всей индустрии программного обеспечения и представляет собой широко признанный набор руководящих принципов для создания надежных веб-сервисов без сохранения состояния.
Любая веб-служба , подчиняющаяся ограничениям REST, неформально описывается как RESTful . Такая веб-служба должна предоставлять свои веб-ресурсы в текстовом представлении и позволять их чтение и изменение с помощью протокола без сохранения состояния и предопределенного набора операций. Такой подход обеспечивает максимальную функциональную совместимость между клиентами и серверами в долговременной среде масштаба Интернета, которая пересекает организационные (доверительные) границы.
«Веб-ресурсы» впервые были определены во всемирной паутине как документы или файлы, идентифицируемые по их URL-адресам . Сегодня это определение является гораздо более общим и абстрактным и включает в себя каждую вещь, сущность или действие, которые могут быть идентифицированы, названы, адресованы, обработаны или выполнены каким-либо образом в сети. В веб-службе RESTful запросы к URI ресурса вызывают ответ с полезными данными, отформатированными в HTML , XML , JSON или другом формате. Например, ответ может подтвердить, что состояние ресурса было изменено. Ответ также может включать гипертекстовые ссылки на связанные ресурсы. Наиболее распространенным протоколом для этих запросов и ответов является HTTP. Он предоставляет операции ( методы HTTP ), такие как GET, POST, PUT и DELETE. [2] Используя протокол без сохранения состояния и стандартные операции, системы RESTful стремятся к высокой производительности, надежности и возможности роста за счет многократного использования компонентов, которыми можно управлять и обновлять, не затрагивая систему в целом, даже во время ее работы.
Целью REST является повышение производительности, масштабируемости, простоты, модифицируемости, видимости, переносимости и надежности. Это достигается за счет соблюдения таких принципов REST, как архитектура клиент-сервер, отсутствие состояния, кэшируемость, использование многоуровневой системы, поддержка кода по запросу и использование унифицированного интерфейса. Эти принципы должны соблюдаться, чтобы система была классифицирована как REST.
Термин « репрезентативная государственная передача» был введен и определен в 2000 году Роем Филдингом в его докторской диссертации. [1] [3] В диссертации Филдинга объясняются принципы REST, которые с 1994 года были известны как «объектная модель HTTP» и использовались при разработке стандартов HTTP 1.1 и унифицированных идентификаторов ресурсов (URI). [4] [5] Этот термин призван вызвать образ поведения хорошо спроектированного веб-приложения: это сеть веб-ресурсов (виртуальный конечный автомат), в которой пользователь перемещается по приложению, выбирая идентификаторы ресурсов, такие как как http://www.example.com/articles/21 и операции с ресурсами, такие как GET или POST (переходы между состояниями приложения), в результате чего представление следующего ресурса (следующее состояние приложения) передается конечному пользователю для их использования.
История
Интернет начал входить в повседневное использование в 1993-4 годах, когда стали доступны веб-сайты для общего пользования . [6] В то время существовало лишь фрагментарное описание архитектуры Интернета, и в отрасли было давление, чтобы согласовать некий стандарт для протоколов веб-интерфейса. Например, несколько экспериментальных расширений были добавлены к протоколу связи (HTTP) для поддержки прокси-серверов , и было предложено больше расширений, но была потребность в формальной веб-архитектуре, с помощью которой можно было бы оценить влияние этих изменений. [7]
Вместе W3C и IETF рабочих групп , начали работу по созданию формальных описаний три основных стандартов Интернета: URI , HTTP и HTML . Рой Филдинг принимал участие в создании этих стандартов (в частности, HTTP 1.0 и 1.1 и URI), и в течение следующих шести лет он разработал архитектурный стиль REST, проверяя его ограничения на стандарты протокола Интернета и используя его как средство для определения архитектурные улучшения - и выявление архитектурных несоответствий. Филдинг определил REST в своей докторской диссертации 2000 г. «Архитектурные стили и проектирование сетевых архитектур программного обеспечения» в Калифорнийском университете в Ирвине .
Архитектурные свойства
Ограничения архитектурного стиля REST влияют на следующие архитектурные свойства: [1] [8]
- производительность при взаимодействии компонентов, которая может быть доминирующим фактором воспринимаемой пользователем производительности и эффективности сети; [9]
- масштабируемость, позволяющая поддерживать большое количество компонентов и взаимодействия между компонентами. Рой Филдинг описывает влияние REST на масштабируемость следующим образом:
- простота единого интерфейса;
- возможность модификации компонентов для удовлетворения меняющихся потребностей (даже во время работы приложения);
- видимость связи между компонентами сервисными агентами;
- переносимость компонентов за счет перемещения программного кода вместе с данными;
- надежность в устойчивости к сбоям на системном уровне при наличии сбоев в компонентах, разъемах или данных. [9]
Архитектурные ограничения
Шесть основных ограничений определяют систему RESTful. [8] [10] Эти ограничения ограничивают способы, которыми сервер может обрабатывать запросы клиентов и отвечать на них, так что, работая в рамках этих ограничений, система приобретает желаемые нефункциональные свойства , такие как производительность, масштабируемость, простота, модифицируемость, видимость. , портативность и надежность. [1] Если система нарушает какое-либо из требуемых ограничений, она не может считаться RESTful.
Формальные ограничения REST следующие:
Клиент-серверная архитектура
Безгражданство
В вычислениях протокол без сохранения состояния - это протокол связи, в котором информация о сеансе не сохраняется получателем, обычно сервером. Соответствующие данные сеанса отправляются получателю клиентом таким образом, что каждый переданный пакет информации может быть понят изолированно, без контекстной информации из предыдущих пакетов в сеансе. Это свойство протоколов без сохранения состояния делает их идеальными для приложений большого объема, повышая производительность за счет устранения нагрузки на сервер, вызванной сохранением информации о сеансе.
Кешируемость
Как и во всемирной паутине, клиенты и посредники могут кэшировать ответы. Ответы должны, неявно или явно, определять себя как кэшируемые или некэшируемые, чтобы клиенты не предоставляли устаревшие или несоответствующие данные в ответ на дальнейшие запросы. Хорошо управляемое кэширование частично или полностью исключает некоторые взаимодействия клиент-сервер, дополнительно улучшая масштабируемость и производительность.
Многослойная система
Обычно клиент не может определить, подключен ли он напрямую к конечному серверу или к посреднику по пути. Если между клиентом и сервером размещен прокси-сервер или балансировщик нагрузки , это не повлияет на их обмен данными, и не потребуется обновлять код клиента или сервера. Промежуточные серверы могут улучшить масштабируемость системы за счет включения балансировки нагрузки и предоставления общих кешей. Кроме того, безопасность может быть добавлена в виде слоя поверх веб-сервисов, отделяя бизнес-логику от логики безопасности. [11] Добавление безопасности в качестве отдельного уровня обеспечивает соблюдение политик безопасности . Наконец, промежуточные серверы могут вызывать несколько других серверов для генерации ответа клиенту.
Код по запросу (необязательно)
Серверы могут временно расширять или настраивать функциональные возможности клиента, передавая исполняемый код: например, скомпилированные компоненты, такие как апплеты Java , или сценарии на стороне клиента, такие как JavaScript .
Единый интерфейс
Единообразное ограничение интерфейса является фундаментальным для проектирования любой системы RESTful. [1] Он упрощает и разделяет архитектуру, что позволяет каждой части развиваться независимо. Четыре ограничения для этого унифицированного интерфейса:
- Идентификация ресурсов в запросах - отдельные ресурсы идентифицируются в запросах, например, с использованием URI в веб-службах RESTful. Сами ресурсы концептуально отделены от представлений, возвращаемых клиенту. Например, сервер может отправлять данные из своей базы данных в формате HTML , XML или JSON, ни один из которых не является внутренним представлением сервера.
- Манипулирование ресурсами посредством представлений. Когда клиент хранит представление ресурса, включая любые прикрепленные метаданные , он имеет достаточно информации для изменения или удаления состояния ресурса.
- Самоописательные сообщения - каждое сообщение содержит достаточно информации, чтобы описать, как его обрабатывать. Например, вызываемый анализатор может быть указан типом носителя . [1]
- Гипермедиа как механизм состояния приложения ( HATEOAS ) - получив доступ к начальному URI для приложения REST - аналогично веб-пользователю, обращающемуся к домашней странице веб-сайта, - клиент REST должен иметь возможность динамически использовать предоставляемые сервером ссылки для откройте для себя все необходимые ресурсы. По мере доступа сервер отвечает текстом, который включает гиперссылки на другие ресурсы, доступные в данный момент. Клиенту не нужно жестко запрограммировать информацию о структуре или динамике приложения. [12]
Классификационные модели
Было разработано несколько моделей, помогающих классифицировать REST API в соответствии с их приверженностью различным принципам проектирования REST, например, модели зрелости Ричардсона . [13]
Применяется к веб-сервисам
API-интерфейсы веб-служб, которые соответствуют архитектурным ограничениям REST , называются API-интерфейсами RESTful. [14] API-интерфейсы RESTful на основе HTTP определены со следующими аспектами: [15]
- базовый URI , например
http://api.example.com/
; - стандартные методы HTTP (например, GET, POST, PUT и DELETE);
- тип носителя , который определяет состояние переходных элементов данных (например, атом, микроформаты, применение / vnd.collection + JSON, [15] : 91-99 и т.д.). Текущее представление сообщает клиенту, как составлять запросы на переходы ко всем следующим доступным состояниям приложения. Это может быть как простой URI, так и сложный, как Java-апплет. [16]
Семантика HTTP-методов
В следующей таблице показано, как методы HTTP предназначены для использования в API HTTP, включая RESTful.
HTTP метод | Описание |
---|---|
GET [2] : §4.3.1 | Получите представление о состоянии целевого ресурса. |
ПОСТ [2] : §4.3.3 | Позвольте целевому ресурсу обработать представление, заключенное в запросе. |
PUT [2] : §4.3.4 | Создайте или замените состояние целевого ресурса на состояние, определенное представлением, включенным в запрос. |
УДАЛИТЬ [2] : §4.3.5 | Удалите состояние целевого ресурса. |
Метод GET безопасен , это означает, что его применение к ресурсу не приводит к изменению состояния ресурса (семантика только для чтения). [2] : §4.2.1 Методы GET, PUT и DELETE являются идемпотентными , что означает, что их многократное применение к ресурсу приводит к тому же изменению состояния ресурса, что и однократное их применение, хотя ответ может отличаться. [2] : §4.2.2 Методы GET и POST кэшируются , что означает, что ответы на них могут быть сохранены для повторного использования в будущем. [2] : §4.2.3
Сравнение с CRUD
Методы GET (чтение), PUT (создание и обновление) и DELETE (удаление) являются операциями CRUD, поскольку они имеют семантику управления хранилищем , что означает, что они позволяют пользовательским агентам напрямую манипулировать состояниями целевых ресурсов. Метод POST - это не операция CRUD, а операция процесса, которая имеет семантику, зависящую от целевого ресурса, за исключением семантики управления хранилищем, поэтому он не позволяет пользовательским агентам напрямую манипулировать состояниями целевых ресурсов. [ необходима цитата ] [ оригинальное исследование? ]
Обсуждение
В отличие от веб-сервисов на основе SOAP, для веб-API RESTful не существует «официального» стандарта. Это потому, что REST - это архитектурный стиль, а SOAP - это протокол. REST сам по себе не является стандартом, но реализации RESTful используют такие стандарты, как HTTP , URI , JSON и XML . Многие разработчики описывают свои API как RESTful, хотя эти API не удовлетворяют всем архитектурным ограничениям, описанным выше (особенно ограничению единого интерфейса). [16]
Смотрите также
- Атомарность, последовательность, изоляция, долговечность (ACID)
- Чистые URL
- Протокол приложений домена (DAP)
- Микросервисы
- Обзор языков описания RESTful API
- OpenAPI Specification (ранее Swagger) - спецификация для определения интерфейсов
- OData - протокол для REST API
- RAML
- RSDL (язык описания служб RESTful)
- Ресурсо-ориентированная архитектура (ROA)
- Ресурсо-ориентированные вычисления (ROC)
- Сервисно-ориентированная архитектура (SOA)
- Веб-ориентированная архитектура (WOA)
Рекомендации
- ^ a b c d e f Филдинг, Рой Томас (2000). «Глава 5: Передача репрезентативного состояния (REST)» . Архитектурные стили и проектирование сетевых архитектур программного обеспечения (доктор философии). Калифорнийский университет в Ирвине.
В этой главе был представлен архитектурный стиль передачи репрезентативного состояния (REST) для распределенных гипермедийных систем. REST предоставляет набор архитектурных ограничений, которые при применении в целом подчеркивают масштабируемость взаимодействий компонентов, универсальность интерфейсов, независимое развертывание компонентов и промежуточные компоненты для уменьшения задержки взаимодействия, обеспечения безопасности и инкапсуляции унаследованных систем.
- ^ Б с д е е г ч Филдинг, Рой (июнь 2014 г.). «Протокол передачи гипертекста (HTTP / 1.1): семантика и содержание, раздел 4» . IETF . Инженерная группа Интернета (IETF). RFC 7231 . Проверено 14 февраля 2018 .
- ^ «Филдинг обсуждает определение термина REST» . groups.yahoo.com . Проверено 8 августа 2017 .
- ^ Филдинг, Рой; Геттис, Джим; Могол, Джеффри; Фристик, Хенрик; Масинтер, Ларри; Лич, Пол; Бернерс-Ли, Тим (июнь 1999 г.). «Протокол передачи гипертекста - HTTP / 1.1» . IETF . Инженерная группа Интернета (IETF). RFC 2616 . Проверено 14 февраля 2018 .
- ^ Филдинг, Рой Томас (2000). «Глава 6: Опыт и оценка» . Архитектурные стили и проектирование сетевых архитектур программного обеспечения (доктор философии). Калифорнийский университет в Ирвине.
С 1994 года архитектурный стиль REST используется для руководства проектированием и разработкой архитектуры для современной сети. В этой главе описывается опыт и уроки, извлеченные из применения REST при разработке Интернет-стандартов для протокола передачи гипертекста (HTTP) и унифицированных идентификаторов ресурсов (URI), двух спецификаций, которые определяют общий интерфейс, используемый всеми взаимодействиями компонентов в Интернете, как а также от развертывания этих технологий в форме клиентской библиотеки libwww-perl, проекта HTTP-сервера Apache и других реализаций стандартов протокола.
- ^ Кулдри, Ник (2012). СМИ, общество, мир: социальная теория и практика цифровых медиа . Лондон: Polity Press. п. 2. ISBN 9780745639208.
- ^ Филдинг, Рой Томас (2000). «Глава 6: Опыт и оценка» . Архитектурные стили и проектирование сетевых архитектур программного обеспечения (доктор философии). Калифорнийский университет в Ирвине.
- ^ а б Эрл, Томас; Карлайл, Бенджамин; Паутассо, Чезаре; Баласубраманян, Радж (2012). «5.1». SOA с REST: принципы, шаблоны и ограничения для создания корпоративных решений с REST . Река Аппер Сэдл, Нью-Джерси: Prentice Hall. ISBN 978-0-13-701251-0.
- ^ а б Филдинг, Рой Томас (2000). «Глава 2: Архитектуры сетевых приложений» . Архитектурные стили и проектирование сетевых архитектур программного обеспечения (доктор философии). Калифорнийский университет в Ирвине.
- ^ Ричардсон, Леонард; Руби, Сэм (2007). Веб-службы RESTful . Севастополь, Калифорния: O'Reilly Media. ISBN 978-0-596-52926-0.
- ^ Ланге, Кеннет (2016). Маленькая книга об услугах REST . Копенгаген. п. 19 . Проверено 18 августа 2019 .
- ^ «ОТДЫХ НЕНАВИСТИ» . RESTfulAPI.net. 2 июня 2018.
- ^ Иван Сальвадори, Фрэнк Сикейра (июнь 2015 г.). «Модель зрелости для семантических RESTful Web API» . Конференция: Веб-службы (ICWS), Международная конференция IEEE 2015 г. OnAt: Нью-Йорк - США - через Researchgate.
- ^ «Что такое REST API» . Учебное пособие по RESTful API . Проверено 29 сентября 2016 года .
- ^ а б Ричардсон, Леонард; Амундсен, Майк (2013), RESTful Web API , O'Reilly Media, ISBN 978-1-449-35806-8
- ^ а б Рой Т. Филдинг (2008-10-20). «API REST должны быть гипертекстовыми» . roy.gbiv.com . Проверено 6 июля 2016 .
дальнейшее чтение
- Паутассо, Чезаре; Уайльд, Эрик; Аларкон, Роза (2014), REST: Темы передовых исследований и практические приложения , Springer, ISBN 9781461492986
- Паутассо, Чезаре; Циммерманн, Олаф; Лейманн, Франк (апрель 2008 г.), «Веб-сервисы RESTful против больших веб-сервисов: принятие правильного архитектурного решения» , 17-я Международная конференция World Wide Web (WWW2008)
- Феррейра, Отавио (ноябрь 2009 г.), Семантические веб-службы: подход RESTful , IADIS, ISBN 978-972-8924-93-5
- Фаулер, Мартин (18 марта 2010 г.). «Модель зрелости Ричардсона: шаги к славе REST» . martinfowler.com . Проверено 26 июня 2017 .