Страница защищена ожидающими изменениями
Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

Передача репрезентативного состояния ( REST ) - это стиль архитектуры программного обеспечения, который использует подмножество HTTP . [1] Он обычно используется для создания интерактивных приложений, использующих веб-службы . Веб-служба, которая следует этим рекомендациям, называется RESTful . Такая веб-служба должна предоставлять свои веб-ресурсы в текстовом представлении и позволять их читать и изменять с помощью протокола без сохранения состояния и предопределенного набора операций. Такой подход обеспечивает взаимодействие между компьютерными системами в Интернете.которые предоставляют эти услуги. REST - это альтернатива, например, SOAP как способ доступа к веб-сервису. [2]

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

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

Термин « репрезентативный государственный переход» был введен и определен в 2000 году Роем ​​Филдингом в его докторской диссертации. [1] [4] В диссертации Филдинга объясняются принципы REST, которые с 1994 года были известны как «объектная модель HTTP» и использовались при разработке стандартов HTTP 1.1 и унифицированных идентификаторов ресурсов (URI). [5] [6] Этот термин призван вызвать образ поведения хорошо спроектированного веб-приложения: это сеть веб-ресурсов (виртуальный конечный автомат), в которой пользователь перемещается по приложению, выбирая идентификаторы ресурсов, такие как http: // www. .example.com / article / 21 и операции с ресурсами, такие как GET или POST (переходы между состояниями приложения), в результате чего представление следующего ресурса (следующее состояние приложения) передается конечному пользователю для их использования.

История [ править ]

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

Рой Филдинг определил REST в своей докторской диссертации 2000 г. «Архитектурные стили и проектирование сетевых архитектур программного обеспечения» в Калифорнийском университете в Ирвине . [1] Он разработал архитектурный стиль REST параллельно с HTTP 1.1 в 1996–1999 годах, основываясь на существующем дизайне HTTP 1.0 [7] 1996 года.

Оглядываясь назад на развитие REST, Филдинг сказал:

На протяжении всего процесса стандартизации HTTP меня призывали защищать выбор дизайна Интернета. Это чрезвычайно сложно сделать в рамках процесса, который принимает предложения от кого-либо по теме, которая быстро становилась центром всей отрасли. У меня были комментарии от более чем 500 разработчиков, многие из которых были выдающимися инженерами с многолетним опытом, и мне пришлось объяснять все, от самых абстрактных понятий веб-взаимодействия до мельчайших деталей синтаксиса HTTP. Этот процесс довел мою модель до базового набора принципов, свойств и ограничений, которые теперь называются REST. [7]

Архитектурные свойства [ править ]

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

  • производительность при взаимодействии компонентов, которая может быть доминирующим фактором воспринимаемой пользователем производительности и эффективности сети; [9]
  • масштабируемость, позволяющая поддерживать большое количество компонентов и взаимодействия между компонентами. Рой Филдинг описывает влияние REST на масштабируемость следующим образом:

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

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

Архитектурные ограничения [ править ]

Шесть основных ограничений определяют систему RESTful. [8] [10] Эти ограничения ограничивают способы, которыми сервер может обрабатывать запросы клиентов и отвечать на них, так что, работая в рамках этих ограничений, система приобретает желаемые нефункциональные свойства , такие как производительность, масштабируемость, простота, модифицируемость, видимость. , портативность и надежность. [1] Если система нарушает какое-либо из требуемых ограничений, она не может считаться RESTful.

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

Клиент-серверная архитектура [ править ]

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

Принцип, лежащий в основе ограничений клиент-сервер, заключается в разделении ответственности. Разделение проблем пользовательского интерфейса и хранения данных улучшает переносимость пользовательских интерфейсов на нескольких платформах. Это также улучшает масштабируемость за счет упрощения серверных компонентов. Возможно, наиболее важным для Интернета является то, что разделение позволяет компонентам развиваться независимо, таким образом поддерживая требования в масштабе Интернета для нескольких доменов организации. [1]

Безгражданство [ править ]

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

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

Кешируемость [ править ]

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

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

Многоуровневая система [ править ]

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

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

Код по запросу (необязательно) [ редактировать ]

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

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

Единый интерфейс [ править ]

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

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

Модели классификации [ править ]

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

Применяется к веб-службам [ править ]

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

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

Семантика HTTP-методов [ править ]

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

Семантика HTTP-методов
HTTP методОписание
GET [3] : §4.3.1Получите представление о состоянии целевого ресурса.
ПОСТ [3] : §4.3.3Позвольте целевому ресурсу обработать представление, заключенное в запросе.
PUT [3] : §4.3.4Установите состояние целевого ресурса в состояние, определенное представлением, включенным в запрос.
УДАЛИТЬ [3] : §4.3.5Удалите состояние целевого ресурса.

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

Методы GET (чтение), PUT (создание и обновление) и DELETE (удаление) являются операциями CRUD, поскольку они имеют семантику управления хранилищем , что означает, что они позволяют пользовательским агентам напрямую манипулировать состояниями целевых ресурсов. Метод POST - это не операция CRUD, а операция процесса, которая имеет семантику, зависящую от целевого ресурса, за исключением семантики управления хранилищем, поэтому он не позволяет агентам пользователя напрямую манипулировать состояниями целевых ресурсов. [3] : §4.3.3 [18]

Обсуждение [ править ]

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

См. Также [ править ]

  • Атомарность, последовательность, изоляция, долговечность (ACID)
  • Чистые URL
  • Создание, чтение, обновление и удаление (CRUD)
  • Протокол приложений домена (DAP)
  • Микросервисы
  • Обзор языков описания RESTful API
    • OpenAPI Specification (ранее Swagger) - спецификация для определения интерфейсов
    • OData - протокол для REST API
    • RAML
    • RSDL (язык описания служб RESTful)
  • Ресурсо-ориентированная архитектура (ROA)
  • Ресурсо-ориентированные вычисления (ROC)
  • Сервисно-ориентированная архитектура (SOA)
  • Веб-ориентированная архитектура (WOA)

Ссылки [ править ]

  1. ^ Б с д е е г ч я Филдинг, Roy Thomas (2000). «Глава 5: Передача репрезентативного состояния (REST)» . Архитектурные стили и проектирование сетевых архитектур программного обеспечения (доктор философии). Калифорнийский университет в Ирвине. В этой главе был представлен архитектурный стиль передачи репрезентативного состояния (REST) ​​для распределенных гипермедийных систем. REST предоставляет набор архитектурных ограничений, которые при применении в целом подчеркивают масштабируемость взаимодействий компонентов, универсальность интерфейсов, независимое развертывание компонентов и промежуточные компоненты для уменьшения задержки взаимодействия, обеспечения безопасности и инкапсуляции унаследованных систем.
  2. ^ «Архитектура веб-сервисов» . Консорциум World Wide Web. 11 февраля 2004 г. 3.1.3 Связь с World Wide Web и REST-архитектурами . Проверено 29 сентября 2016 года .
  3. ^ a b c d e f g h i Филдинг, Рой (июнь 2014 г.). «Протокол передачи гипертекста (HTTP / 1.1): семантика и содержание, раздел 4» . IETF . Инженерная группа Интернета (IETF). RFC 7231 . Проверено 14 февраля 2018 . 
  4. ^ "Филдинг обсуждает определение термина REST" . groups.yahoo.com . Проверено 8 августа 2017 .
  5. ^ Филдинг, Рой; Геттис, Джим; Могул, Джеффри; Фристик, Хенрик; Масинтер, Ларри; Лич, Пол; Бернерс-Ли, Тим (июнь 1999 г.). «Протокол передачи гипертекста - HTTP / 1.1» . IETF . Инженерная группа Интернета (IETF). RFC 2616 . Проверено 14 февраля 2018 . 
  6. ^ Филдинг, Рой Томас (2000). «Глава 6: Опыт и оценка» . Архитектурные стили и проектирование сетевых архитектур программного обеспечения (доктор философии). Калифорнийский университет в Ирвине.С 1994 года архитектурный стиль REST используется для руководства проектированием и разработкой архитектуры для современной сети. В этой главе описывается опыт и уроки, извлеченные из применения REST при разработке Интернет-стандартов для протокола передачи гипертекста (HTTP) и унифицированных идентификаторов ресурсов (URI), двух спецификаций, которые определяют общий интерфейс, используемый всеми взаимодействиями компонентов в Интернете, как а также от развертывания этих технологий в форме клиентской библиотеки libwww-perl, проекта HTTP-сервера Apache и других реализаций стандартов протокола.
  7. ^ a b «Филдинг обсуждает развитие стиля REST» . Tech.groups.yahoo.com. Архивировано из оригинала на 11 ноября 2009 года . Проверено 14 сентября 2014 .
  8. ^ а б Эрл, Томас; Карлайл, Бенджамин; Паутассо, Чезаре; Баласубраманян, Радж (2012). «5.1». SOA с REST: принципы, шаблоны и ограничения для создания корпоративных решений с REST . Река Аппер Сэдл, Нью-Джерси: Prentice Hall. ISBN 978-0-13-701251-0.
  9. ^ a b Филдинг, Рой Томас (2000). «Глава 2: Архитектуры сетевых приложений» . Архитектурные стили и проектирование сетевых архитектур программного обеспечения (доктор философии). Калифорнийский университет в Ирвине.
  10. ^ Ричардсон, Леонард; Руби, Сэм (2007). Веб-службы RESTful . Севастополь, Калифорния: O'Reilly Media. ISBN 978-0-596-52926-0.
  11. ^ «Филдинг говорит о состояниях приложений» . Tech.groups.yahoo.com . Проверено 7 февраля 2013 .
  12. ^ Ланге, Кеннет (2016). Маленькая книга об услугах REST . Копенгаген. п. 19 . Проверено 18 августа 2019 .
  13. ^ "ОТДЫХ НЕНАВИЖИМОСТИ" . RESTfulAPI.net.
  14. ↑ Иван Сальвадори, Фрэнк Сикейра (июнь 2015 г.). «Модель зрелости для семантических RESTful Web API» . Конференция: Веб-службы (ICWS), Международная конференция IEEE 2015 г. в г. Нью-Йорк - США - через Researchgate.
  15. ^ «Что такое REST API» . Учебное пособие по RESTful API . Проверено 29 сентября 2016 года .
  16. ^ a b Ричардсон, Леонард; Амундсен, Майк (2013), RESTful Web API , O'Reilly Media, ISBN 978-1-449-35806-8
  17. ^ a b Рой Т. Филдинг (2008-10-20). «API REST должны быть гипертекстовыми» . roy.gbiv.com . Проверено 6 июля 2016 .
  18. ^ Рой Т. Филдинг (2009-03-20). «Можно использовать POST» . roy.gbiv.com . Проверено 14 апреля 2020 .

Дальнейшее чтение [ править ]

  • Паутассо, Чезаре; Уайльд, Эрик; Аларкон, Роза (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 .