REST: различия между версиями

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Интерактивная навигация по истории
(Показать все непатрулированные изменения)
[непроверенная версия][непроверенная версия]
← Предыдущая правкаСледующая правка →
Содержимое удалено Содержимое добавлено
ВизуальныйВики-текст
Нет описания правки
Строка 35: Строка 35:
Существует '''шесть''' обязательных ограничений для построения распределённых REST-приложений по Филдингу. <ref name="Fielding-Ch5" /><ref name="SOAwithREST">{{книга|автор=Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian|часть=5.1|заглавие=SOA with REST|издательство=Prentice Hall|год=2013|isbn=978-0-13-701251-0}}</ref>.
Существует '''шесть''' обязательных ограничений для построения распределённых REST-приложений по Филдингу. <ref name="Fielding-Ch5" /><ref name="SOAwithREST">{{книга|автор=Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian|часть=5.1|заглавие=SOA with REST|издательство=Prentice Hall|год=2013|isbn=978-0-13-701251-0}}</ref>.


Выполнение этих ограничительных требований обязательно для REST-систем.<ref name="SOA with REST">{{cite book|title=SOA with REST|year=2013|publisher=Prentice Hall|isbn=978-0-13-701251-0|authors=Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian|editor=Thomas Erl|chapter=5.1}}</ref><ref name="Richardson 2007">{{Citation|last1=Richardson|first1=Leonard|title=RESTful Web service|year=2007|publisher=O'Reilly Media|isbn=978-0-596-52926-0|url=https://books.google.com/books?id=XUaErakHsoAC|first2=Sam|last2=Ruby|accessdate=18 January 2011|quote=The main topic of this book is the web service architectures which can be considered RESTful: those which get a good score when judged on the criteria set forth in Roy Fielding's dissertation.}}</ref> Накладываемые ограничения определяют работу сервера в том как он может обрабатывать, и отвечать на запросы клиентов. Действуя в рамках этих ограничений, система приобретает такие желательные свойства как производительность, масштабируемость, простота, способность к изменениям, переносимость, отслеживаемость и надежность.
Выполнение этих ограничительных требований обязательно для REST-систем.<ref name="SOA with REST">{{cite book|title=SOA with REST|year=2013|publisher=Prentice Hall|isbn=978-0-13-701251-0|authors=Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian|editor=Thomas Erl|chapter=5.1}}</ref><ref name="Richardson 2007">{{Citation|last1=Richardson|first1=Leonard|title=RESTful Web service|year=2007|publisher=O'Reilly Media|isbn=978-0-596-52926-0|url=https://books.google.com/books?id=XUaErakHsoAC|first2=Sam|last2=Ruby|accessdate=18 January 2011|quote=The main topic of this book is the web service architectures which can be considered RESTful: those which get a good score when judged on the criteria set forth in Roy Fielding's dissertation.}}</ref> Накладываемые ограничения определяют работу сервера в том, как он может обрабатывать и отвечать на запросы клиентов. Действуя в рамках этих ограничений, система приобретает такие желательные свойства как производительность, масштабируемость, простота, способность к изменениям, переносимость, отслеживаемость и надежность.


Если сервис-приложение нарушает <nowiki>''</nowiki>любое<nowiki>''</nowiki> из этих ограничительных условий, данную систему нельзя считать REST-системой <ref name="Fielding-Ch52" />.
Если сервис-приложение нарушает <nowiki>''</nowiki>любое<nowiki>''</nowiki> из этих ограничительных условий, данную систему нельзя считать REST-системой <ref name="Fielding-Ch52" />.
Строка 42: Строка 42:


===1. Модель клиент-сервер ===
===1. Модель клиент-сервер ===
Первым ограничением применимым к нашей гибридной модели является приведение архитектуры к модели клиент-сервер, описанной в параграфе 3.4.1.<ref name="Fielding-Ch5" /> <nowiki>''</nowiki>(<nowiki>''</nowiki>прим. <nowiki>''</nowiki>диссертации Филдинга)<nowiki>''</nowiki> Разграничение потребностей является принципом лежащим в основе данного накладываемого ограничения. Отделение потребности интерфейса [[Клиент (информатика)|клиента]] от потребностей [[Сервер (приложение)|сервера, хранящего данные]], повышает переносимость [[Программный код|кода]] клиентского [[интерфейс|интерфейса]] на другие платформы, а упрощение [[Сервер (приложение)|серверной части]] улучшает масштабируемость. Наибольшее же влияние на [[Всемирная паутина|всемирную паутину]] пожалуй имеет само разграничение, которое позволяет отдельным частям развиваться независимо друг от друга, поддерживая потребности в развитии интернета со стороны различных организаций.<ref name="Fielding-Ch5" />
Первым ограничением применимым к нашей гибридной модели является приведение архитектуры к модели клиент-сервер, описанной в параграфе 3.4.1.<ref name="Fielding-Ch5" /> <nowiki>''</nowiki>(<nowiki>''</nowiki>прим. <nowiki>''</nowiki>диссертации Филдинга)<nowiki>''</nowiki>. Разграничение потребностей является принципом, лежащим в основе данного накладываемого ограничения. Отделение потребности интерфейса [[Клиент (информатика)|клиента]] от потребностей [[Сервер (приложение)|сервера, хранящего данные]], повышает переносимость [[Программный код|кода]] клиентского [[интерфейс|интерфейса]] на другие платформы, а упрощение [[Сервер (приложение)|серверной части]] улучшает масштабируемость. Наибольшее же влияние на [[Всемирная паутина|всемирную паутину]], пожалуй, имеет само разграничение, которое позволяет отдельным частям развиваться независимо друг от друга, поддерживая потребности в развитии интернета со стороны различных организаций.<ref name="Fielding-Ch5" />


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


Во время обработки клиентских запросов, считается что клиент находится в ''переходном состоянии''. Каждое отдельное ''состояние'' приложения представлено связями которые могут быть задействованы при следующем обращении клиента.
Во время обработки клиентских запросов считается, что клиент находится в ''переходном состоянии''. Каждое отдельное ''состояние'' приложения представлено связями, которые могут быть задействованы при следующем обращении клиента.


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


===4. Единообразие интерфейса ===
===4. Единообразие интерфейса ===

Версия от 14:58, 27 января 2017

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-системы:

  • Производительность - взаимодействие компонентов системы может являться доминирующим фактором производительности и эффективности сети с точки зрения пользователя
  • Масштабируемость для обеспечения большого числа компонентов и взаимодействий компонентов.

Рой Филдинг - один из главных авторов спецификации протокола HTTP, описывает влияние архитектуры REST на масштабируемость следующим образом:

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

Требования к архитектуре REST

Существует шесть обязательных ограничений для построения распределённых REST-приложений по Филдингу. [2][6].

Выполнение этих ограничительных требований обязательно для REST-систем.[7][8] Накладываемые ограничения определяют работу сервера в том, как он может обрабатывать и отвечать на запросы клиентов. Действуя в рамках этих ограничений, система приобретает такие желательные свойства как производительность, масштабируемость, простота, способность к изменениям, переносимость, отслеживаемость и надежность.

Если сервис-приложение нарушает ''любое'' из этих ограничительных условий, данную систему нельзя считать REST-системой [9].

Обязательными условиями-ограничениями являются:

1. Модель клиент-сервер

Первым ограничением применимым к нашей гибридной модели является приведение архитектуры к модели клиент-сервер, описанной в параграфе 3.4.1.[2] ''(''прим. ''диссертации Филдинга)''. Разграничение потребностей является принципом, лежащим в основе данного накладываемого ограничения. Отделение потребности интерфейса клиента от потребностей сервера, хранящего данные, повышает переносимость кода клиентского интерфейса на другие платформы, а упрощение серверной части улучшает масштабируемость. Наибольшее же влияние на всемирную паутину, пожалуй, имеет само разграничение, которое позволяет отдельным частям развиваться независимо друг от друга, поддерживая потребности в развитии интернета со стороны различных организаций.[2]

2. Отсутствие состояния

Протокол взаимодействия между клиентом и сервером требует соблюдения следующего условия: в период между запросами клиента никакая информация о состоянии клиента на сервере не хранится. (Stateless protocol[англ.]*. Все запросы от клиента должны быть составлены так, чтобы сервер получил всю необходимую информацию для выполнения запроса. Состояние сессии при этом сохраняется на стороне клиента. [2]. Информация о состоянии сессии может быть передана сервером какому-либо другому сервису (например в службу базы данных) для поддержания устойчивого состояния, например с целью, и на период установления аутентификации. Клиент инициирует отправку запросов когда он готов (возникает необходимость) перейти в новое состояние.

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

3. Кэширование

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

4. Единообразие интерфейса

Наличие унифицированного интерфейса являются фундаментальным требованием дизайна REST-сервисов.[2] Унифицированные интерфейсы позволяют каждому из сервисов развиваться независимо.

К унифицированным интерфейсам предъявляются следующие четыре ограничительных условия[10][11]:

Идентификация ресурсов

  • Все ресурсы идентифицируются в запросах, например, с использованием URI в интернет-системах. Ресурсы концептуально отделены от представлений, которые возвращаются клиентам. Например, сервер может отсылать данные из базы данных в виде HTML, XML или JSON, ни один из которых не является типом хранения внутри сервера.

Манипуляция ресурсами через представление

  • Если клиент хранит представление ресурса, включая метаданные - он обладает достаточной информацией для модификации или удаления ресурса.

"Самоописываемые" сообщения

  • Каждое сообщение содержит достаточно информации, чтобы понять каким образом его обрабатывать. К примеру, обработчик сообщения (parser) необходимый для извлечения данных может быть указан в списке MIME-типов.[2]

Гипермедиа, как средство изменения состояния приложения (HATEOAS?!)

  • Клиенты изменяют состояние системы только через действия, которые динамически определены в гипермедиа на сервере (к примеру, гиперссылки в гипертексте). Исключая простые точки входа в приложение, клиент не может предположить что доступна какая-то операция над каким-то ресурсом, если не получил информацию об этом в предыдущих запросах к серверу. Не существует универсального формата для предоставления ссылок между ресурсами, RFC 5988 и JSON Hypermedia API Language являются 2мя популярными форматами предоставления ссылок в REST HYPERMEDIA сервисах.

5. Слои

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

6. Код по требованию (необязательное ограничение)

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

Преимущества

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

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

Примечания

  1. ↑ Машнин Тимур Сергеевич, Машнин Тимур Сергеевич. Технология Web-сервисов платформы Java. — БХВ-Петербург, 2012. — С. 115. — 560 с. — ISBN 978-5-9775-0778-3.
  2. ↑ 1 2 3 4 5 6 7 8 9 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. ↑ 5.1 // SOA with REST / Thomas Erl. — Prentice Hall, 2013. — ISBN 978-0-13-701251-0.
  8. ↑ Richardson, Leonard; Ruby, Sam (2007), RESTful Web service, O'Reilly Media, ISBN 978-0-596-52926-0, Дата обращения: 18 января 2011, The main topic of this book is the web service architectures which can be considered RESTful: those which get a good score when judged on the criteria set forth in Roy Fielding's dissertation.
  9. ↑ Ошибка в сносках?: Неверный тег <ref>; для сносок Fielding-Ch52 не указан текст
  10. ↑ Wilde, Pautasso, 2011, REST Definition.
  11. ↑ Н. Л. Подколодный, А. В. Семенычев, Д. А. Рассказов, В. Г. Боровский, Е. А. Ананько, Е. В. Игнатьева, Н. Н. Подколодная, О. А. Подколодная, Н. А. Колчанов Распределённая система RESTful-web-сервисов для реконструкции и анализа генных сетей. Вавиловский журнал генетики и селекции, т. 16, N 4/1, 2012
  12. ↑ 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.

Ссылки

Источник — https://ru.wikipedia.org/ruwiki/w/index.php?title=REST&oldid=83318161