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

'{{redirect|REST||Rest (disambiguation)}} Передача состояния представления ('''Representational State Transfer''' ('''REST''')) - это стиль [[Архитектура программного обеспечения|архитектуры программного обеспечения]] для [[Распределённые вычисления|распределенных]] [[Гипермедиа|гипермедиа]] систем, подобных [[Всемирная паутина|Всемирной паутине]]. Термин ''Передача состояния представления'' введен и определен в 2000 году [[Roy Fielding|Роем Филдингом]] в его кандидатской диссертации.<ref name="Fielding-Ch5">Chapter 5 of Fielding's dissertation is [http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm "Representational State Transfer (REST)"].</ref><ref>[http://tech.groups.yahoo.com/group/rest-discuss/message/6735 "Fielding discussing the definition of the REST term"]</ref> Филдинг является одним из основных авторов спецификации [[HTTP|протокола передачи гипертекста]] (HTTP) версий 1.0 и 1.1.<ref>RFC 1945</ref><ref>RFC 2616</ref> Соответствие ограничениям REST называется "RESTful".<ref>{{cite book|last=Richardson|first=Leonard|title=RESTful web service|year=2007|publisher=O'Reilly Media|isbn=978-0-596-52926-0|url=http://books.google.com/books?id=XUaErakHsoAC&printsec=frontcover#v=onepage&q&f=false|coauthors=Sam Ruby|accessdate=18 January 2011|chapter=Preface}}</ref> == История == Архитектурный стиль REST разработан параллельно с [[HTTP|HTTP]]/1.1, основываясь на существующем дизайне HTTP/1.0.<ref>[http://tech.groups.yahoo.com/group/rest-discuss/message/6757 Fielding discusses the development of the REST style]</ref> Крупнейшей реализацией системы, соответствующей архитектурному стилю REST является [[Всемирная паутина|Всемирная паутина]]. REST иллюстрирует развитие архитектуры Web, характеризуя и регулируя макровзаимодействие четырех компонентов Web, а именно [[Сервер происхождения|серверов происхождения]], [[Сетевой шлюз|сетевых шлюзов]], [[Прокси|прокси]] и [[Клиент(информатика)|клиентов]], без применения ограничений к индивидуальным участникам. Таким образом REST по существу определяет правильное поведение участников. == Концепция == Архитектура в стиле REST состоит из [[Клиент(информатика)|клиентов]] и [[Сервер(информатика)|серверов]]. Клиенты инициируют запросы к серверам; серверы обрабатывают запросы и возвращают подходящие ответы. Запросы и ответы создаются на базе передачи представлений ресурсов. [[Resource (Web)|Ресурс]] может являться практически любым понятным и значимым адресуемым объектом. [[Representation (systemics)|Представление]] ресурса - это обычно документ, отражающий текущее или требуемое состояние ресурса. В определенный момент времени клиент может находиться либо в состоянии перехода между [[State (computer science)|состояниями приложения]] или "в покое". Клиент в состоянии покоя способен взаимодействовать со своим пользователем, но не создает нагрузку и не потребляет места для хранения клиентов на серверах или в сети. Клиент начинает посылать запросы, когда он готов совершить переход в новое состояние. Пока один или более запросов не выполнены, клиент находится в состоянии перехода. Представление каждого состояния приложения содержит ссылки, котрые можно использовать в следующий раз, когда клиент инициирует новый переход в состояние.<ref>[http://tech.groups.yahoo.com/group/rest-discuss/message/5841 Fielding talks about application states]</ref> REST изначально описан в контексте [[HTTP|HTTP]], но не ограничен этом протоколом. Архитектуры типа RESTful могут быть основаны на других [[Протоколы прикладного уровня|протоколах прикладного уровня]], если они уже реализуют обширный и единый словарь для приложений, основанных на передаче значимых представлений состояний. Приложения RESTful увеличивают использование уже существующих хорошо определенных интерфейсов и других встроенных возможностей, предлагаемых выбранным сетевым протоколом, а также сокращают добавление к нему новых возможностей, специфичных для приложения. === Примеры HTTP === HTTP, к примеру, содержит очень обширный словарь глаголов (или "методов"), [[URI|унифицированных индикаторов ресурсов]], [[Internet media type| типов содержимого]], [[Список кодов состояния HTTP|кодов состояния запросов и ответов]] и.т.д. REST использует существующие возможности протокола HTTP, позволяя существующим многослойным компонентам прокси и сетевых шлюзов выполнять дополнительные функции в сети, например, кэширование и обеспечение безопасности HTTP. ==== Отличия SOAP RPC ==== [[SOAP]] [[Remote procedure call|удалённый вызов процедур]] над HTTP, с другой стороны, заставляет каждого разработчика приложений определять новый произвольный словарь существительных и глаголов (например <code>getUsers()</code>, <code>savePurchaseOrder(...)</code>), обычно накладывающихся на метод HTTP [[POST (HTTP)|POST]]. Это не учитывает многие существующие возможности HTTP, такие как проверка подлинности, кэширование и переговоры по типу содержимого, а также может оставить разработчику приложений возможность заново изобрести многие из этих функций в рамках новой лексики.<ref name="Scribner and Seely"/> Примерами может служить добавление таких методов, как <code>getNewUsersSince(Date date)</code>, <code>savePurchaseOrder(string customerLogon, string password, ...)</code>. ==== POX/HTTP ==== Существуют примеры интерфейсов, считающих себя "REST", но фактически использующих HTTP для туннелирования вызовов функций — их называют 'POX/HTTP', или [[Plain Old XML]] над HTTP: * [[Amazon.com]] предлагает "REST" версию его главного интерфейса разработчика 'E-Commerce' [http://developer.amazonwebservices.com/connect/kbcategory.jspa?categoryID=19]; * [[eBay]] предлагает "REST" интерфейс разработчика [http://developer.ebay.com/rest/]; * [[Facebook]] предлагает "REST" интерфейс разработчика [http://developers.facebook.com] Примечание: Facebook ведет процесс отмены его прикладного интерфейса{{citation needed|date=May 2011}}; * [[Yahoo!]] предлагает ряд "REST" интерфейсов разработчика [http://developer.yahoo.com]. * [[Youtube]] предлагает ряд "REST" интерфейсов разработчика [http://code.google.com/intl/nl/apis/youtube/overview.html]. * Система поиска видео [[Truveo]] предлагает ряд "REST" интерфейсов разработчика [http://developer.truveo.com]. * [[Newscloud]] предлагает ряд "REST" интерфейсов разработчика [http://www.newscloud.com/learn/apidocs/]. * [http://movideo.com movideo] предлагает ряд "REST" интерфейсов разработчика [http://code.movideo.com/Introduction_to_the_Media_API]. * [[SharePoint]] версии 2010 Некоторые из этих интерфейсов не соблюдают внутри архитектурные ограничения REST. Некоторые из них экспертами REST считаются [http://www.markbaker.ca/blog/2005/04/14/accidentally-restful/ Аварийно RESTful]. Аварии в основном происходят при выполнении автономных GETS, то есть, когда они не применяются для навигации по многим GET в стиле гипермедиа, и когда эти GETS просто извлекают данные, не изменяя их. ==== Статические веб-сайты ==== Используя очень свободное определение REST, можно ошибочно утверждать, что в Интернете огромное количество приложений являются RESTful (почти все, доступные через запрос HTTP GET или обновляемые через HTTP POST). Хотя теоретически можно классифицировать большинство или все статические веб-сайты, как REST "приложения", вызывает сомнение то, что статичный набор веб-страниц представляет собой интерактивное ''приложение''. Глядя более узко, в смысле альтернативы [[Веб-служба | Веб-службам]] в целом и стилю RPC в частности, REST можно обнаружить во многих местах публичной паутины: * '[[Блогосфера|Блогосфера]]' — вместилище [[Блог|блогов]] — в основном основана на REST, поскольку включает в себя скачивание файлов XML (в форматах [[RSS|RSS]] или [[Atom|Atom]]), содержащих списки ссылок на другие ресурсы; * [[OpenStreetMap]] предлагает интерфейс REST [http://wiki.openstreetmap.org/index.php/REST]; == Ограничения == Архитектурный стиль REST описывает следующие шесть ограничений, налагаемых на архитектуру, оставляя реализацию индивидуальных компонентов свободной: ; [[Технология «клиент-сервер»| Технология «клиент-сервер»]] : Клиенты отделены от сервера единым интерфейсом. Это [[Разделение ответственности|разделение ответственности]] означает, например, что клиенты не отвечают за хранилище данных, являющееся внутренним для каждого сервера, так что [[Software portability|переносимость]] кода клиента улучшается. Серверы не отвечают за пользовательский интерфейс или пользовательское состояние, поэтому серверы могут быть проще и более [[Масштабируемость|масштабируемыми]]. Серверы и клиенты могут разрабатываться и заменяться независимо, пока не изменится интерфейс. ; [[Stateless server|Без состояния]] : Взаимодействие клиент-сервер ограничивается далее отсутствием сохранения контекста клиента на сервере между запросами. Каждый запрос от любого клиента содержит всю информацию, необходимую для его обслуживания, а любое состояние сессии хранится в клиенте. Сервер может быть [[stateful|''с состоянием'']]; это ограничение требует, чтобы состояние на стороне сервера было адресуемо через URL как ресурс. Это не только делает серверы более [[Website monitoring|видимыми для мониторинга]], но и делает их более [Reliability (computer networking)|нажедными]] в случае частичного отказа сети, а также дополнительно улучшает их масштабируемость. ; [[Cache|Кэш]]ируемость : Как и во Всемирной паутине, клиенты могут кэшировать ответы. Поэтому ответы должны, явно или неявно, определять себя кэшируемыми или нет, чтобы предотвратить использование клиентом старые или неподходящие данные при ответе на следующие запросы. Хорошо управляемое кэширование частично или полностью устраняет некоторые взаимодействия клиента и сервера, повышая далее масштабируемость и производительность. ; [[Layered system|Слоистая система]] : Клиент не может однозначно определить, подключается ли он непосредственно к серверу или к посреднику по пути подключения. Посредник сервера может улучшить масштабируемость системы, обеспечивая балансировку нагрузки и обеспечивая общий кэш. Он может также потребовать соблюдения политики безопасности. ; [[Client-side scripting|Код по требованию (опционально)]] : Серверы могут временно расширить или настроить функциональность клиента, передавая ему исполняемую логику. Примерами этого могут служить скомпилированные компоненты, такие как [[Java-апплет|Java-апплет]]ы и клиентские сценарии, такие как [[JavaScript|JavaScript]]. ; [[#Руководящие принципы интерфейса REST|Единый интерфейс]] : Единый интерфейс между клиентами и серверами, обсуждаемый ниже, упрощает и разделяет архитектуру, позволяя каждой части развиваться самостоятельно. Четыре руководящих принципа такого интерфейса подробно описаны ниже. Единственным дополнительным ограничением архитектуры REST является код по требованию. Если служба нарушает какие-либо другие ограничения, она не может быть однозначно названа RESTful. Соблюдение этих ограничений, и, следовательно, соответствие архитектурному стилю REST, позволит любой распределенной системе гипермедиа иметь требуемые свойства, такие как производительность, масштабируемость, простота, модифицируемость, видимость, мобильность и надежность. == Руководящие принципы интерфейса {{anchor|Руководящие принципы интерфейса REST}} == Единый интерфейс, которому должен удовлетворять любой интерфейс REST считается фундаментальным для разработки любой службы REST.<ref name="Scribner and Seely">{{Citation |title=Effective REST Services via .NET |last=Scribner |first=Kenn |last2=Seely |first2=Scott |year=2009 |publisher=Addison-Wesley |location=Boston |isbn=978-0-321-61325-7 }}</ref> ; Идентификация ресурсов : Индивидуальные ресурсы идентифицируются в запросах, например, с помощью [[URI|URI]] в системах REST на основе Веб. Сами ресурсы концептуально отделены от представлений, возвращаемых клиенту. Например, сервер отправляет не свою базу данных, а, возможно, некоторый файл [[HTML]], [[XML]] или [[JSON]], представляющий некоторые записи базы данных, выраженные например, на финском и закодированные в [[UTF-8]], в зависимости от деталей запроса и реализации сервера. ; Манипуляция ресурсами через их представления : Когда клиент содержит представление ресурсов, включая любые присоединенные [Метаданные|метаданные], он имеет достаточно информации для того, чтобы изменить или удалить ресурс на сервере, если он имеет на это разрешение. ; Самоописывающие сообщения : Каждое сообщение содержит достаточно информации, чтобы описать способ обработки сообщения. Например, определение того, какой анализатор следует вызвать, можно выполнить через [[Internet media type|тип содержимого Интернет]] (ранее известный как тип [MIME]]). Ответы также явно указывают возможность кэширования. <ref Name="Fielding-Ch5"/> ; [[HATEOAS|Гипермедиа как машина состояния приложения]] : Клиенты выполняют переходы в состояния только с помощью действий, которые динамически определены в гипермедиа на сервере (например, [[Гиперссылка|ссылкой]] в структуре [[Гипертекст|гипертекста]]). Кроме простой фиксированной точки входа в приложение, клиент предполагает, что никакое конкретное действие, кроме описанных в представлениях, полученных ранее от сервера, не будет доступно для любого конкретного ресурса. == Ключевые цели == Ключевые цели REST включают: * [[Масштабируемость]] взаимодействия компонентов * Общность [[Интерфейс|интерфейсов]] * Независимое [[Внедрение программного обеспечения|внедрение]] компонентов * Промежуточные компоненты, снижающие [[Latency (engineering)|задержку]], усиливающие [[data security|безопасность]] и [[Инкапсуляция (программирование)|инкапсулирующие]] [[legacy system|устаревшие системы]] REST был применен для описания желаемой веб-архитектуры, чтобы помочь определить существующие проблемы, помочь сравнить альтернативные решения, и обеспечить ситуацию, когда расширения протокола не будут нарушать основные ограничения, которые делают Веб успешным. Филдинг так описывает влияние REST на масштабируемость: {{quote|Разделение задач клиента и сервера в REST упрощает реализацию компонентов, уменьшает сложность семантики [[соединения]], улучшает эффективность настройки производительности и увеличивает масштабируемость чистых компонентов сервера. Ограничения многоуровневой системы позволяют вводить посредников-[[Прокси-сервер|прокси]], [[Сетевой шлюз|шлюзы]] и [[Межсетевой экран|межсетевые экраны]] в различных точках связи, не меняя интерфейсов между компонентами, что позволяет им оказывать помощь в передаче сообщений или повысить производительность с помощью крупномасштабного общего кэширования. REST позволяет осуществить промежуточную обработку, ограничивая сообщения, которые будут самоописательными: взаимодействие между запросами не зависит от состояния, для обозначения семантики и обмена информацией используются стандартные методы и типы носителей, а ответы явно указывают кэширование. <ref>{{Harv |Fielding|2000| loc=&sect;5.3.1}}</ref>}} == Основной принцип == Важным понятием в REST является наличие [[Resource (Web)| ресурсов]] (источников конкретной информации), каждый из которых определяется ссылкой с глобальным идентификатором (например, [[URI]] в HTTP ). Для того, чтобы манипулировать этими ресурсами,''компоненты'' сети (пользовательских агенты и сервера происхождения) общаются через стандартизованный интерфейс (например, HTTP) и обмениваются ''представлениями'' этих ресурсов (фактическими документами для передачи информации). Например, ресурс, представляющий [[окружность]] может принимать и возвращать представление, которое определяет точку центра и радиус, отформатированное в [[SVG]], но также может принимать и возвращать представление, содержащее любые три различные точки вдоль кривой (так как это тоже однозначно определяет круг), как [[CSV]]. Любое количество ''соединений''(например, [[Клиент (информатика)| клиентов]], [[Сервер (программное обеспечение)| серверов]], [[кэш]] ей, [[Туннелирование (компьютерные сети)| туннелей]] и т.д.) может являться посредником запроса, но каждый делает это без «обращения в прошлое" к его собственным запросам (именуемого "слоистость", еще одно ограничение REST и общий принцип во многих других частях информационно-сетевой архитектуры). Таким образом, приложение может взаимодействовать с ресурсами, зная две вещи: идентификатор ресурса и требуемое действие - ему не нужно знать, присутствует ли кэш, прокси-сервер, шлюз, межсетевой экран, тоннель или что-нибудь еще между ним и сервером, владеющим реальной информацией. Приложение, тем не менее, должно понимать возвращаемый формат данных (''представление''), являющееся, как правило, документом [[HTML]], [[XML]] или [[JSON]], хотя это может быть изображение, текст или любое другое содержимое. == RESTful веб-службы == RESTful веб-служба (также называемая RESTful [[web API]]) - это простая веб-служба, реализованная с использованием HTTP и принципов REST. Она представляет собой набор ресурсов с тремя определенными аспектами: * базовый URI для веб-службы, например <code><nowiki>http://example.com/resources/</nowiki></code> * [[Internet media type|тип содержимого Интернет]] для данных, поддерживаемых веб-службой. Часто это [[JSON]], [[XML]] или [[YAML]], но можно использовать любой другой действительный тип содержимого Интернет. * множество операций, поддерживаемых веб-службой, используя [[HTTP#Основные механизмы протокола|основные механизмы протокола]] (т.е., POST, GET, PUT или DELETE). Следующая таблица показывает, как методы HTTP обычно используются для реализации веб-службы. {| class="wikitable" border="1" |+ Методы HTTP RESTful веб-службы <ref>{{Citation | last = Richardson | first = Leonard | last2 = Ruby | first2 = Sam | author2-link = Sam Ruby | publication-date = (May 8, 2007) | year = 2007 | title = RESTful Web Services | publisher = O'Reilly | isbn = 0596529260 }}</ref> ! Ресурс !! GET !! PUT !! POST !! DELETE |- ! URI коллекции, например <code><nowiki>http://example.com/resources/</nowiki></code> | '''Показать''' URI и возможно другие детали элементов коллекции. | '''Заменить''' существующую коллекцию другой коллекцией. | '''Создать''' новый элемент коллекции. URL нового элемента присваивается автоматически и обычно возвращается этой операцией. | '''Удалить''' всю коллекцию. |- ! URI элемента, например <code><nowiki>http://example.com/resources/ef7d-xj36p</nowiki></code> | '''Извлечь''' представление адресованного элемента коллекции, выраженное соответствующим типом содержимого Интернет. | '''Обновить''' адресованный элемент коллекции. | Воспринимать адресованный элемент как коллекцию и '''создать''' в нем новый элемент. | '''Удалить''' адресованный элемент коллекции. |} Методы PUT и DELETE являются [[HTTP#Idempotent methods and web applications|идемпотентными]]. Метод GET является [[HTTP#Safe methods|безопасным]], что означает, что его вызов не вызывает сторонних эффектов (это также влияет на идемпотентность). В отличие от [[SOAP]] веб-служб для RESTful веб-служб не существует ''официального'' стандарта.<ref>Elkstein, M. [http://rest.elkstein.org/2008/02/what-is-rest.html ''What is REST?'']. Retrieved on 2009-07-04.</ref> Так случилось потому, что REST является архитектурой, в то время как SOAP представляет собой протокол. Хотя REST не является стандартом, реализации RESTful, такие как Веб могут использовать стандарты HTTP, URI, XML, и.т.д. == Публичные реализации == REST можно обнаружить в некоторых местах публичного Веб-пространства: * [[Atom (standard)|Протокол Atom]] для публикации в блогах считается каноническим [http://tools.ietf.org/html/rfc5023 протоколом RESTful]. * [[Sun Microsystems]]' [http://kenai.com/projects/suncloudapis/pages/Home Cloud API] представляет хороший пример документации типа содержимого ресурса. * Инициатива [http://open-services.net/html/Home.html Open Services for Lifecycle Collaboration (OSLC)] устанавливает подход RESTful для интеграции артефактов разработки программного обеспечения. * [[CouchDB]] является документ-ориентированной базой данных, написанной на [[Erlang|Эрланге]], и предоставляет RESTful JSON API, доступный из любой среды, позволяющей запросы HTTP. * [[MySQL Cluster]] является масштабируемой по записи базой данных, также доступной через родной [http://code.google.com/p/mod-ndb/ REST/JSON] интерфейс в виде модуля apache. * [[Microsoft]]'s [http://code.msdn.microsoft.com/cannonicalRESTEntity канонический сервис сущности REST]. * [[Nuxeo]] - менеджер документов с открытым кодом, реализующий интерфейс автоматизации контента через [https://doc.nuxeo.com/display/NXDOC/REST+API REST API] * [[Sones GraphDB]] - граф-ориентированная база данных, написанная на C#, предлагающая RESTful интерфейс * [[Amazon AWS]] реализует RESTful API как опцию взаимодействия клиента и сервера. ** [[Amazon.com]] S3 единственная реализация [http://aws.amazon.com/documentation/s3/ REST]; == Реализации на платформах == * .NET Open-Source - [[OpenRasta]], [http://www.servicestack.net/ ServiceStack], [https://github.com/johnsheehan/RestSharp RestSharp] * [[ColdFusion]] - [[ColdFusion on Wheels]], [[Mach-II]], [http://atuttle.github.com/Taffy/ Taffy] * [[Ext (JavaScript library)|Ext JS]] * Grails [плагин http://www.grails.org/plugin/json-rest-api JSON-REST-API] * Java [http://www.ibm.com/developerworks/webservices/library/ws-designpattern Jt Design Pattern Framework], [http://incubator.apache.org/wink/ Wink] , [[Restlet]], [[JBoss application server|JBoss]] RESTEasy, [https://jersey.dev.java.net/ Jersey], [[Apache CXF]], [[NetKernel]], [[Apache Sling]], [http://restfulie.caelum.com.br/ Restfulie], [[Play Framework]] * Microsoft's [[WCF Data Services]], [http://wcf.codeplex.com/wikipage?title=WCF%20HTTP WCF Web Api] * Perl [[Catalyst (software)|Catalyst]], [[Dancer (software)|Dancer]], [[Mojolicious]] * PHP [[DooPHP]], [[Symfony]], [[Zend Framework]], [[CakePHP]], [[Kohana]], [[EllisLab#CodeIgniter|CodeIgniter]], [[Silverstripe#Software_Design|Sapphire]], [http://getfrapi.com FRAPI], [http://www.recessframework.org RECESS], [https://github.com/deepeshmalviya/simple-rest Simple-REST] * Python [http://toastdriven.github.com/django-tastypie/ Tastypie], [http://pypi.python.org/pypi/django-piston django-piston], [http://django-rest-framework.org/ django-rest-framework], [http://code.google.com/p/django-rest-interface django-rest-interface] [http://code.google.com/p/django-restapi django-restapi], [http://webpy.org/ web.py], [https://launchpad.net/lazr.restful lazr.restful] * Микроядро и программная платформа REST [[NetKernel]] * Ruby [[Ruby on Rails]], [[Sinatra (software)|Sinatra]], [http://restfulie.caelum.com.br/ Restfulie] * [[TurboGears]]2 предлагает RestController * [http://code.google.com/p/zest/ ZEST] - облегченный Struts-like Web framework * [http://wiki.objectstyle.org/confluence/display/WONDER/ERRest+Framework ERRest] - REST платформа для Apple's [[WebObjects]] == За пределами Веб == Программное обеспечение, которое может взаимодействовать с целым рядом различных видов объектов или устройств, может делать это с помощью единого, согласованного интерфейса. === CMIP === [[CMIP|Протокол общей управляющей информации]] (CMIP) был разработан для управления сетевыми ресурсами, представляя их управляемые характеристики в качестве атрибутов объекта. Объекты связаны отношениями родитель-потомок, которые идентифицируются с помощью уникальных имен и атрибутов, которые читаются и изменяются набором операций [[CRUD| создания, чтения, обновления и удаления]]. Примечательным не RESTful аспектом CMIP является операция M_ACTION, хотя по возможности, разработчики [Management Information Base|базы управляющей информации] (MIB), как правило, стремятся предоставить контролируемые и имеющие состояние аспекты сетевого оборудования через атрибуты. == Примечания == <references/> == См. также== *[[Clean URLs]] *[[CRUD]] (CRUD) *[[HATEOAS]] (Hypermedia as the Engine of Application State) *[[Сервис-ориентированная архитектура]] *[[Waka (protocol)]] == Ссылки == * {{Citation |last1=Fielding |first1=Roy T. |last2=Taylor |first2=Richard N. |date=2002-05 |title=Principled Design of the Modern Web Architecture |url=http://www.ics.uci.edu/~taylor/documents/2002-REST-TOIT.pdf |format=[[Portable Document Format|PDF]] |journal=ACM Transactions on Internet Technology (TOIT) |publisher=Association for Computing Machinery |location=New York |volume=2 |issue=2 |pages=115–150 |doi=10.1145/514183.514185 |issn=1533-5399}} * {{Citation|last=Fielding|first=Roy Thomas|year=2000|title=Architectural Styles and the Design of Network-based Software Architectures|version=Doctoral dissertation|publisher=University of California, Irvine|url=http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm}} * {{Citation|last1=Pautasso|first1=Cesare|last2=Zimmermann|first2=Olaf|last3=Leymann|first3=Frank|date=2008-04|month=April|title=RESTful Web Services vs. Big Web Services: Making the Right Architectural Decision|url=http://www.jopera.org/docs/publications/2008/restws|journal=17th International World Wide Web Conference (WWW2008)|location=Beijing, China}} * {{Citation|last1=Richardson|first1=Leonard|last2=Ruby|first2=Sam|date=2007-05|title=RESTful Web Services|url=http://oreilly.com/catalog/9780596529260|publisher=O'Reilly|isbn=978-0-596-52926-0}} == Внешние ссылки == {{Spoken Wikipedia|En-Representational_State_Transfer.ogg|2011-06-02}} * [http://www.ibm.com/developerworks/webservices/library/ws-restful RESTful Web services: The basics] * [http://www.infoq.com/minibooks/emag-03-2010-rest InfoQ Explores: REST] * [http://restxdemo.mulesoft.org/ruwiki/static/demo/start.html Illustration of a self-documenting RESTful API and creation of RESTful web services through an interactive demo] * [http://www.infoq.com/articles/rest-introduction Stefan Tilkov: A Brief Introduction to REST] * [http://www.infoq.com/articles/rest-anti-patterns Stefan Tilkov: REST Anti-Patterns] * Martin Fowler describes the [http://martinfowler.com/articles/richardsonMaturityModel.html Richardson Maturity Model] as a way of building up an understanding of RESTful APIs * [http://www.infoq.com/articles/designing-restful-http-apps-roth Gregor Roth: RESTful HTTP in practice] * [http://duncan-cragg.org/blog/post/getting-data-rest-dialogues/ The REST Dialogues] * [http://rest.blueoxen.net/cgi-bin/wiki.pl RESTwiki]: a useful collection of articles about REST by some of its early proponents * [http://tomayko.com/writings/rest-to-my-wife How I Explained REST to My Wife]: Simple explanation of what REST is and why it's important * [http://wiki.oxygennext.com/index.php/Oxygen_REST_API Oxygen REST API] A Demo REST implementation * [http://developer.mindtouch.com/REST/REST_for_the_Rest_of_Us REST for the Rest of Us] * [http://www.oreillynet.com/pub/wlg/3005 REST vs. SOAP at Amazon] - Why 85% of the users of Amazon use REST rather than SOAP {{cloud computing}} [[Category:Cloud standards]] [[Category:Software architecture]] [[Category:Web 2.0 neologisms]] [[ca:REST]] [[cs:Representational State Transfer]] [[de:Representational State Transfer]] [[et:REST]] [[es:Representational State Transfer]] [[fr:Representational State Transfer]] [[ko:REST]] [[id:REST]] [[it:Representational State Transfer]] [[he:REST]] [[hu:REST]] [[nl:Representational State Transfer]] [[ja:REST]] [[pl:Representational State Transfer]] [[pt:REST]] [[ru:REST]] [[fi:REST]] [[sv:Representational State Transfer]] [[uk:REST]] [[zh:REST]]'