REST

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

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

В сети Интернет, вызов удалённой процедуры может представлять собой обычный HTTP-запрос (обычно «GET» или «POST»; такой запрос называют «REST-запрос»), а необходимые данные передаются в качестве параметров запроса[2][3].

Для веб-служб, построенных с учётом REST (то есть не нарушающих накладываемых им ограничений), применяют термин «RESTful».

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

История термина[править | править вики-текст]

Хотя данная концепция лежит в самой основе Всемирной паутины — термин «REST» был введён Роем Филдингом (англ. Roy Fielding), одним из создателей протокола «HTTP», лишь в 2000 году[3]. В своей диссертации «Архитектурные стили и дизайн сетевых программных архитектур» («Architectural Styles and the Design of Network-based Software Architectures»)[4] в Калифорнийском университете в Ирвайне[2] он подвёл теоретическую основу под способ взаимодействия клиентов и серверов во Всемирной паутине, абстрагировав его и назвав «передачей представительного состояния». Филдинг описал концепцию построения распределённого приложения, при которой каждый запрос (REST-запрос) клиента к серверу содержит в себе исчерпывающую информацию о желаемом ответе сервера (желаемом представительном состоянии), и сервер не обязан сохранять информацию о состоянии клиента («клиентской сессии»).

Стиль «REST» развивался параллельно с «HTTP 1.1», разработанным в 1996—1999 годах, основываясь на существующем дизайне «HTTP 1.0», разработанном в 1996 году[5].

Архитектура REST[править | править вики-текст]

Необходимые условия для построения распределённых REST-приложений по Филдингу:[2][6]

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

Единый интерфейс между клиентом и сервером. Такое разделение подразумевает отсутствие связи между клиентами и хранилищем данных. Это хранилище остаётся внутренним устройством сервера; таким образом, переносимость клиентского кода увеличивается, что способствует упрощению сервера и его масштабируемости. Серверы и клиенты могут быть мгновенно заменены независимо друг от друга, так как интерфейс между ними не меняется.

Отсутствие состояния[править | править вики-текст]

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

Кэширование[править | править вики-текст]

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

Единообразие интерфейса[править | править вики-текст]

Ограничения на унифицированный интерфейс являются фундаментальными в дизайне REST-сервисов. Каждый из сервисов функционирует и развивается независимо. Ограничения для унификации интерфейса[7][8]:

  1. Идентификация ресурсов. Все ресурсы идентифицируются в запросах, например, с использованием URI в интернет-системах. Ресурсы концептуально отделены от представлений, которые возвращаются клиентам. Например, сервер может отсылать данные из базы данных в виде HTML, XML или JSON, ни один из которых не является типом хранения внутри сервера.
  2. Манипуляция ресурсами через представление. Если клиент хранит представление ресурса, включая метаданные - он имеет достаточно данных для модификации или удаления ресурса.
  3. «Самоописываемые» сообщения. Каждое сообщение содержит достаточно информации, чтобы описать каким образом его обрабатывать. К примеру, какой парсер необходимо применить для извлечения данных может быть описано в Internet медиа-типе.[9]
  4. Гипермедиа, как средство изменения состояния приложения (HATEOAS). Клиенты изменяют состояние системы только через действия, которые динамически определены в гипермедиа на сервере (к примеру, гиперссылки в гипертексте). Исключая простые точки входа в приложение, клиент не может предположить что доступна какая-то операция над каким-то ресурсом, если не получил информацию об этом в предыдущих запросах к серверу. Не существует универсального формата для предоставления ссылок между ресурсами, RFC 5988 и JSON Hypermedia API Language являются 2мя популярными форматами предоставленя ссылок в REST HYPERMEDIA сервисах.

Слои[править | править вики-текст]

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

Код по требованию (необязательное ограничение)[править | править вики-текст]

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

Преимущества[править | править вики-текст]

Филдинг указывал, что приложения, не соответствующие приведённым условиям, не могут называться REST-приложениями. Если же все условия соблюдены, то, по его мнению, приложение получит следующие преимущества:[2][6]

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

Примечания[править | править вики-текст]

  1. Машнин Тимур Сергеевич, Машнин Тимур Сергеевич. Технология Web-сервисов платформы Java. — БХВ-Петербург, 2012. — С. 115. — 560 с. — ISBN 978-5-9775-0778-3.
  2. 1 2 3 4 Chapter 5 of Roy Fielding’s dissertation «Representational State Transfer (REST)»
  3. 1 2 Fielding discussing the definition of the REST term. Tech.groups.yahoo.com. Проверено 28 ноября 2013.
  4. Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST). www.ics.uci.edu. Проверено 1 декабря 2015.
  5. rest-discuss : Message: Re: [rest-discuss RFC for REST?] (11 ноября 2009). Проверено 1 декабря 2015.
  6. 1 2 Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian. 5.1 // SOA with REST. — Prentice Hall, 2013. — ISBN 978-0-13-701251-0.
  7. Wilde, Pautasso, 2011, REST Definition.
  8. Н. Л. Подколодный, А. В. Семенычев, Д. А. Рассказов, В. Г. Боровский, Е. А. Ананько, Е. В. Игнатьева, Н. Н. Подколодная, О. А. Подколодная, Н. А. Колчанов Распределённая система RESTful-web-сервисов для реконструкции и анализа генных сетей. Вавиловский журнал генетики и селекции, т. 16, N 4/1, 2012
  9. Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST). www.ics.uci.edu. Проверено 14 декабря 2015.
  10. Hartley Brody How HTTPS Secures Connections: What Every Web Dev Should Know (англ.).

Литература[править | править вики-текст]

  • Erik Wilde, Cesare Pautasso. REST: From Research to Practice. — Springer Science & Business Media, 2011. — 528 p. — ISBN 978-1-4419-8303-9.

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