REST ( Representational State Transfer ) — это программный архитектурный стиль , который был создан для руководства проектированием и разработкой архитектуры для Всемирной паутины . REST определяет набор ограничений для того , как должна вести себя архитектура распределенной гипермедиа- системы масштаба Интернета , такой как Веб. Архитектурный стиль REST подчеркивает единообразные интерфейсы , независимое развертывание компонентов , масштабируемость взаимодействий между ними и создание многоуровневой архитектуры для содействия кэшированию с целью сокращения воспринимаемой пользователем задержки , обеспечения безопасности и инкапсуляции устаревших систем . [1]
REST использовался во всей индустрии программного обеспечения для создания надежных веб-приложений без сохранения состояния . Приложение, которое придерживается архитектурных ограничений REST, можно неформально описать как RESTful , хотя этот термин чаще ассоциируется с разработкой API на основе HTTP и тем, что широко считается передовой практикой в отношении «глаголов» ( методов HTTP ), на которые реагирует ресурс , имея при этом мало общего с REST в его первоначальной формулировке, а часто даже противореча этой концепции. [2]
Термин «передача репрезентативного состояния» был введен и определен в 2000 году ученым-компьютерщиком Роем Филдингом в его докторской диссертации. Он означает, что сервер ответит представлением ресурса (сегодня это чаще всего будет документ HTML , XML или JSON ), и этот ресурс будет содержать гипермедийные ссылки, по которым можно перейти, чтобы изменить состояние системы. Любой такой запрос, в свою очередь, получит представление ресурса и т. д.
Важным следствием является то, что единственный идентификатор, который необходимо знать, — это идентификатор первого запрошенного ресурса, а все остальные идентификаторы будут обнаружены. Это означает, что эти идентификаторы могут меняться без необходимости предварительного информирования клиента и что между клиентом и сервером может быть только слабая связь.
Веб начал входить в повседневное использование в 1993–1994 годах, когда веб-сайты общего пользования начали становиться доступными. [3] В то время существовало лишь фрагментарное описание архитектуры Веба, и в отрасли оказывалось давление с целью согласования некоторого стандарта для протоколов веб-интерфейса. Например, несколько экспериментальных расширений были добавлены в протокол связи (HTTP) для поддержки прокси-серверов , и предлагалось больше расширений, но была необходимость в формальной архитектуре Веба, с помощью которой можно было бы оценить влияние этих изменений. [4]
Рабочие группы W3C и IETF совместно начали работу над созданием формальных описаний трех основных стандартов Интернета: URI , HTTP и HTML . Рой Филдинг принимал участие в создании этих стандартов (в частности, HTTP 1.0 и 1.1, а также URI), и в течение следующих шести лет он создал архитектурный стиль REST, протестировав его ограничения на стандартах протоколов Интернета и используя его как средство для определения архитектурных улучшений — и выявления архитектурных несоответствий. Филдинг определил REST в своей докторской диссертации 2000 года «Архитектурные стили и проектирование сетевых программных архитектур» [1] [5] в Калифорнийском университете в Ирвайне .
Чтобы создать архитектурный стиль REST, Филдинг определил требования, которые применяются при создании всемирного сетевого приложения, такие как необходимость низкого входного барьера для обеспечения глобального принятия. Он также изучил множество существующих архитектурных стилей для сетевых приложений, определив, какие функции являются общими с другими стилями, такими как кэширование и клиент-серверные функции, и те, которые являются уникальными для REST, такими как концепция ресурсов. Филдинг пытался как классифицировать существующую архитектуру текущей реализации, так и определить, какие аспекты следует считать центральными для поведенческих и производительных требований Интернета.
По своей природе архитектурные стили не зависят от какой-либо конкретной реализации, и хотя REST был создан как часть разработки веб-стандартов, реализация веба не подчиняется всем ограничениям в архитектурном стиле REST. Несоответствия могут возникать из-за незнания или упущения, но существование архитектурного стиля REST означает, что их можно идентифицировать до того, как они станут стандартизированными. Например, Филдинг определил встраивание информации о сеансе в URI как нарушение ограничений REST, которое может негативно повлиять на общее кэширование и масштабируемость сервера. HTTP-cookie также нарушают ограничения REST [4], поскольку они могут стать несинхронизированными с состоянием приложения браузера, что делает их ненадежными; они также содержат непрозрачные данные, которые могут представлять проблему для конфиденциальности и безопасности .
Архитектурный стиль REST разработан для сетевых приложений, в частности клиент-серверных приложений. Но более того, он разработан для использования в масштабах Интернета, поэтому связь между пользовательским агентом (клиентом) и исходным сервером должна быть максимально свободной для облегчения широкомасштабного внедрения.
Сильное разделение клиента и сервера вместе с текстовой передачей информации с использованием единого протокола адресации обеспечило основу для удовлетворения требований Интернета: расширяемость , анархическая масштабируемость [ необходима ссылка ] и независимое развертывание компонентов, крупномасштабная передача данных и низкий порог входа для читателей, авторов и разработчиков контента.
Ограничения архитектурного стиля REST влияют на следующие архитектурные свойства: [1] [6]
Архитектурный стиль REST определяет шесть руководящих ограничений. [6] [8] Когда эти ограничения применяются к архитектуре системы, она приобретает желаемые нефункциональные свойства , такие как производительность, масштабируемость, простота, модифицируемость, видимость, переносимость и надежность. [1]
Формальные ограничения REST следующие: [9]
Ограничение единого интерфейса является основополагающим для проектирования любой системы RESTful. [1] Оно упрощает и разделяет архитектуру, что позволяет каждой части развиваться независимо. Четыре ограничения для этого единого интерфейса:
Было разработано несколько моделей, помогающих классифицировать REST API в соответствии с их приверженностью различным принципам проектирования REST, таким как