Просмотр отдельных изменений

''''REST''' (сокр. от {{lang-en|'''Representational State Transfer'''}} — «передача состояния представления») — [[Архитектура программного обеспечения|архитектурный стиль]] взаимодействия компонентов распределённого приложения в [[вычислительная сеть|сети]]. REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределённой [[гипермедиа]]-системы. В определённых случаях ([[интернет-магазин]]ы, [[Поисковая система|поисковые системы]], прочие системы, основанные на данных) это приводит к повышению производительности и упрощению архитектуры. В широком смысле{{уточнить}} компоненты в REST взаимодействуют наподобие взаимодействия клиентов и серверов во [[Всемирная паутина|Всемирной паутине]]. REST является альтернативой [[Удалённый вызов процедур|RPC]]<ref>{{книга | автор = Машнин Тимур Сергеевич, Машнин Тимур Сергеевич | заглавие = Технология Web-сервисов платформы Java | издательство = БХВ-Петербург | год = 2012 | страницы = 115 | страниц =560 | isbn = 978-5-9775-0778-3 }}</ref>. В сети [[Интернет]] [[Удалённый вызов процедур|вызов удалённой процедуры]] может представлять собой обычный [[HTTP]]-запрос (обычно «GET» или «POST»; такой запрос называют ''«REST-запрос»''), а необходимые данные передаются в качестве [[параметр]]ов запроса<ref name="Fielding-Ch5" /><ref name=autogenerated1>{{cite web|url=http://tech.groups.yahoo.com/group/rest-discuss/message/6735 |title=Fielding discussing the definition of the REST term |publisher=Tech.groups.yahoo.com |accessdate=2013-11-28}}</ref>. Для [[веб-служба|веб-служб]], построенных с учётом REST (то есть не нарушающих накладываемых им ограничений), применяют термин «'''RESTful'''». В отличие от веб-сервисов (веб-служб) на основе [[SOAP]], не существует «официального» стандарта для RESTful веб-API. Дело в том, что REST является '''архитектурным стилем''', в то время как SOAP является протоколом. Несмотря на то, что REST не является стандартом сам по себе, большинство RESTful-реализаций используют стандарты, такие как [[HTTP]], [[URL]], [[JSON]] и [[XML]]. == История термина == Хотя данная [[концепция]] лежит в самой основе [[Всемирная паутина|Всемирной паутины]], термин «REST» был введён {{нп2|Филдинг, Рой Томас|Роем Филдингом|en|Roy Fielding}}, одним из создателей протокола «[[HTTP]]», лишь в 2000 году<ref name=autogenerated1 />. В своей диссертации ''«Архитектурные стили и дизайн сетевых программных архитектур» («Architectural Styles and the Design of Network-based Software Architectures»)''<ref>{{Cite web|accessdate = 2015-12-01|title = Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST)|url = http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm|publisher = www.ics.uci.edu}}</ref> в [[Калифорнийский университет в Ирвайне|Калифорнийском университете в Ирвайне]]<ref name="Fielding-Ch5">Chapter 5 of Roy Fielding’s dissertation [http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm «Representational State Transfer (REST)»]</ref> он подвёл теоретическую основу под способ взаимодействия [[Клиент (информатика)|клиентов]] и [[Сервер (программное обеспечение)|серверов]] во [[Всемирная паутина|Всемирной паутине]], абстрагировав его и назвав «передачей представительного состояния». Филдинг описал концепцию построения распределённого приложения, при которой каждый запрос (REST-запрос) клиента к серверу содержит в себе исчерпывающую информацию о желаемом ответе сервера (желаемом представительном состоянии), и сервер не обязан сохранять информацию о состоянии клиента («клиентской сессии»). Стиль «REST» развивался параллельно с «[[HTTP 1.1]]», разработанным в 1996—1999 годах, основываясь на существующем дизайне «[[HTTP]] 1.0», разработанном в [[1996 год]]у<ref>{{Cite web|accessdate = 2015-12-01|date = 2009-11-11|title = rest-discuss : Message: Re: [rest-discuss] RFC for REST?|url = http://tech.groups.yahoo.com/group/rest-discuss/message/6757|deadurl = yes|archiveurl = https://web.archive.org/web/20091111012314/http://tech.groups.yahoo.com/group/rest-discuss/message/6757|archivedate = 2009-11-11}}</ref>. == Свойства Архитектуры REST == {{Нет источников в разделе|дата=2017-03-16}} Свойства архитектуры, которые зависят от ограничений, наложенных на REST-системы: * Производительность — взаимодействие компонентов системы может являться доминирующим фактором производительности и эффективности сети с точки зрения пользователя * Масштабируемость для обеспечения большого числа компонентов и взаимодействий компонентов. Рой Филдинг — один из главных авторов спецификации протокола HTTP, описывает влияние архитектуры REST на масштабируемость следующим образом: * Простота унифицированного интерфейса * Открытость компонентов к возможным изменениям для удовлетворения изменяющихся потребностей (даже при работающем приложении) * Прозрачность связей между компонентами системы для сервисных служб * Переносимость компонентов системы путем перемещения программного кода вместе с данными * Надежность, выражающаяся в устойчивости к отказам на уровне системы при наличии отказов отдельных компонентов, соединений, или данных == Требования к архитектуре REST == Существует '''шесть''' обязательных ограничений для построения распределённых 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="Fielding-Ch5" />. Обязательными условиями-ограничениями являются: === 1. Модель клиент-сервер === Первым ограничением, применимым к гибридной модели, является приведение архитектуры к модели клиент-сервер. Разграничение потребностей является принципом, лежащим в основе данного накладываемого ограничения. Отделение потребности интерфейса [[Клиент (информатика)|клиента]] от потребностей [[Сервер (приложение)|сервера, хранящего данные]], повышает переносимость [[Программный код|кода]] клиентского [[интерфейс]]а на другие платформы, а упрощение [[Сервер (приложение)|серверной части]] улучшает масштабируемость. Наибольшее же влияние на [[Всемирная паутина|всемирную паутину]], пожалуй, имеет само разграничение, которое позволяет отдельным частям развиваться независимо друг от друга, поддерживая потребности в развитии интернета со стороны различных организаций.<ref name="Fielding-Ch5" /> === 2. Отсутствие состояния === Протокол взаимодействия между клиентом и сервером требует соблюдения следующего условия: в период между запросами клиента никакая информация о ''состоянии'' клиента на сервере не хранится. ({{Нп3|Stateless protocol}}. Все запросы от клиента должны быть составлены так, чтобы сервер получил всю необходимую информацию для выполнения запроса. ''Состояние'' сессии при этом сохраняется на стороне клиента<ref name="Fielding-Ch5"/>. Информация о состоянии сессии может быть передана сервером какому-либо другому сервису (например в службу базы данных) для поддержания устойчивого состояния, например с целью, и на период установления аутентификации. Клиент инициирует отправку запросов, когда он готов (возникает необходимость) перейти в новое состояние. Во время обработки клиентских запросов считается, что клиент находится в ''переходном состоянии''. Каждое отдельное ''состояние'' приложения представлено связями, которые могут быть задействованы при следующем обращении клиента. === 3. Кэширование === {{Нет источников в разделе|дата=2017-03-16}} Как и во [[Всемирная паутина|Всемирной паутине]], клиенты, а также промежуточные узлы, могут выполнять [[кэширование]] ответов сервера. Ответы сервера, в свою очередь, должны иметь явное или неявное обозначение как кэшируемые или некэшируемые с целью предотвращения получения клиентами устаревших или неверных данных в ответ на последующие запросы. Правильное использование кэширования способно полностью или частично устранить некоторые клиент-серверные взаимодействия, ещё больше повышая производительность и расширяемость системы. === 4. Единообразие интерфейса === Наличие унифицированного интерфейса является фундаментальным требованием дизайна REST-сервисов<ref name="Fielding-Ch5" />. Унифицированные интерфейсы позволяют каждому из сервисов развиваться независимо. К унифицированным интерфейсам предъявляются следующие четыре ограничительных условия{{sfn|Wilde, Pautasso|2011|loc=REST Definition}}<ref>''Н. Л. Подколодный, А. В. Семенычев, Д. А. Рассказов, В. Г. Боровский, Е. А. Ананько, Е. В. Игнатьева, Н. Н. Подколодная, О. А. Подколодная, Н. А. Колчанов'' Распределённая система RESTful-web-сервисов для реконструкции и анализа генных сетей. Вавиловский журнал генетики и селекции, т. 16, N 4/1, 2012<!-- удачный перевод терминологии --></ref>: '''Идентификация ресурсов''' * Все ресурсы идентифицируются в запросах, например, с использованием URI в интернет-системах. Ресурсы концептуально отделены от представлений, которые возвращаются клиентам. Например, [[Сервер (программное обеспечение)|сервер]] может отсылать данные из [[База данных|базы данных]] в виде [[HTML]], [[XML]] или [[JSON]], ни один из которых не является типом хранения внутри сервера. '''Манипуляция ресурсами через представление''' * Если клиент хранит представление ресурса, включая метаданные — он обладает достаточной информацией для модификации или удаления ресурса. '''«Самоописываемые» сообщения''' * Каждое сообщение содержит достаточно информации, чтобы понять каким образом его обрабатывать. К примеру, обработчик сообщения (parser) необходимый для извлечения данных может быть указан в [[Список MIME-типов|списке MIME-типов]]<ref name="Fielding-Ch5" />. '''Гипермедиа, как средство изменения состояния приложения ([[HATEOAS]])''' * Клиенты изменяют состояние системы только через действия, которые динамически определены в гипермедиа на сервере (к примеру, [[Гиперссылка|гиперссылки]] в [[гипертекст]]е). Исключая простые точки входа в приложение, клиент не может предположить что доступна какая-то операция над каким-то ресурсом, если не получил информацию об этом в предыдущих запросах к серверу. Не существует универсального формата для предоставления ссылок между ресурсами, RFC 5988 и [https://tools.ietf.org/id/draft-kelly-json-hal-03.txt JSON Hypermedia API Language] являются двумя популярными форматами предоставления ссылок в REST HYPERMEDIA сервисах. === 5. Слои === Клиент обычно не способен точно определить, взаимодействует ли он напрямую с [[Сервер приложений|сервером]] или же с промежуточным узлом, в связи с иерархической структурой сетей (подразумевая, что такая структура образует [[Иерархия|слои]]). Применение промежуточных серверов способно повысить масштабируемость за счет [[Балансировка нагрузки|балансировки нагрузки]] и распределенного [[Кэширование|кэширования]]. Промежуточные узлы также могут подчиняться [[Политика безопасности|политике безопасности]] с целью обеспечения [[Конфиденциальная информация|конфиденциальности информации]]<ref>{{Статья|автор=Hartley Brody|заглавие=How HTTPS Secures Connections: What Every Web Dev Should Know|ссылка=https://blog.hartleybrody.com/https-certificates/|язык=en|издание=|тип=|год=|месяц=|число=|том=|номер=|страницы=|issn=}}</ref>. === 6. Код по требованию (необязательное ограничение) === {{Нет источников в разделе|дата=2017-03-16}} REST может позволить расширить функциональность клиента за счёт загрузки кода с сервера в виде [[апплет]]ов или [[Сценарный язык|сценариев]]. Филдинг утверждает, что дополнительное ограничение позволяет проектировать архитектуру, поддерживающую желаемую функциональность в общем случае, но возможно за исключением некоторых контекстов. == Преимущества == Филдинг указывал, что приложения, не соответствующие приведённым условиям, не могут называться REST-приложениями. Если же все условия соблюдены, то, по его мнению, приложение получит следующие преимущества<ref name="Fielding-Ch5"/><ref name="SOAwithREST" />: * Надёжность (за счёт отсутствия необходимости сохранять информацию о состоянии клиента, которая может быть утеряна); * Производительность (за счёт использования кэша); * Масштабируемость; * Прозрачность системы взаимодействия (особенно необходимая для приложений обслуживания [[Вычислительная сеть|сети]]); * Простота [[интерфейс]]ов; * Портативность компонентов; * Лёгкость внесения изменений; * Способность [[Эволюция|эволюционировать]], приспосабливаясь к новым требованиям (на примере [[Всемирная паутина|Всемирной паутины]]). == Примечания == {{примечания}} == Литература == * {{книга | автор = Erik Wilde, Cesare Pautasso | заглавие = REST: From Research to Practice | издательство = Springer Science & Business Media | год = 2011 | isbn = 978-1-4419-8303-9 | allpages = 528 | ref = Wilde, Pautasso }} == Ссылки == * {{cite web|url=http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm|title=Architectural Styles and the Design of Network-based Software Architectures|author=Roy Fielding|accessdate=2009-02-20|date=2000|lang=en|archiveurl=https://www.webcitation.org/67gOwyTek?url=http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm|archivedate=2012-05-15|deadurl=yes}} * {{cite web|url=http://www.jopera.org/docs/publications/2008/restws|title=RESTful Web Services vs. Big Web Services: Making the Right Architectural Decision|author=Cesare Pautasso|coauthors=Olaf Zimmerman; Frank Leymann|publisher=17th International World Wide Web Conference (WWW2008)|accessdate=2009-02-20|lang=en|archiveurl=https://www.webcitation.org/67gOxPVRw?url=http://www.jopera.org/docs/publications/2008/restws|archivedate=2012-05-15|deadurl=yes}} * {{cite web|url=http://msdn.microsoft.com/ru-ru/magazine/dd315413.aspx|title=Введение в службы RESTful с использованием WCF|author=Джон Фландерс|publisher=MSDN Magazine|accessdate=2009-02-20|date=январь 2009|archiveurl=https://www.webcitation.org/67gOy2qOM?url=http://msdn.microsoft.com/ru-ru/magazine/dd315413.aspx|archivedate=2012-05-15|deadurl=yes}} * {{cite web|url=http://www.ibm.com/developerworks/library/ws-restful/|title=RESTful Web services: The basics|author=Alex Rodriguez|accessdate=2015-12-15|lang=en|publisher=IBM}} * {{cite web|url=http://www.restapitutorial.com/|title=REST API Tutorial|author=Todd Fredrich|accessdate=2016-10-27|lang=en}} [[Категория:Архитектура программного обеспечения]] [[Категория:Веб 2.0]] [[Категория:Веб-программирование]] [[Категория:Всемирная паутина]]'