ОТДЫХ
 | Эта статья может быть слишком технической для понимания большинства читателей . ( Октябрь 2020 г. ) |
REST ( передача репрезентативного состояния ) — это архитектурный стиль программного обеспечения , созданный для управления проектированием и разработкой архитектуры Всемирной паутины . REST определяет набор ограничений того, как должна вести себя архитектура распределенной Интернета системы масштаба гипермедийной , такой как Интернет. Архитектурный стиль REST подчеркивает унифицированные интерфейсы , независимое развертывание компонентов , масштабируемость взаимодействия между ними и создание многоуровневой архитектуры для содействия кэшированию с целью уменьшения воспринимаемой пользователем задержки , обеспечения безопасности и инкапсуляции устаревших систем . [1]
REST используется во всей индустрии программного обеспечения для создания без сохранения состояния надежных веб-приложений . Приложение, которое придерживается архитектурных ограничений REST, может быть неофициально описано как RESTful , хотя этот термин чаще ассоциируется с разработкой HTTP на основе API-интерфейсов и тем, что широко считается лучшими практиками в отношении «глаголов» ( методов 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, которое может негативно повлиять на общее кэширование и масштабируемость сервера. Файлы cookie HTTP также нарушают ограничения REST, поскольку они могут рассинхронизироваться с состоянием приложения браузера, что делает их ненадежными; они также содержат непрозрачные данные, которые могут представлять угрозу конфиденциальности и безопасности .
Архитектурные объекты [ править ]
Архитектурный стиль REST предназначен для сетевых приложений, в частности приложений клиент-сервер. Более того, он предназначен для использования в масштабах Интернета, поэтому связь между пользовательским агентом (клиентом) и исходным сервером должна быть как можно более свободной , чтобы облегчить широкомасштабное внедрение.
Сильная развязка клиента и сервера вместе с текстовой передачей информации с использованием единого протокола адресации обеспечила основу для удовлетворения требований Интернета: расширяемость , анархическая масштабируемость и независимое развертывание компонентов, крупномасштабная передача данных и низкий входной барьер для читателей контента, авторов контента и разработчиков.
Ограничения архитектурного стиля REST влияют на следующие архитектурные свойства: [1] [6]
- Производительность взаимодействия компонентов, которая может быть доминирующим фактором производительности, воспринимаемой пользователем, и эффективности сети; [7]
- Масштабируемость , позволяющая поддерживать большое количество компонентов и взаимодействие между компонентами;
- Простота единого интерфейса;
- Возможность модификации компонентов для удовлетворения меняющихся потребностей (даже во время работы приложения);
- Видимость связи между компонентами сервисными агентами;
- Переносимость компонентов за счет перемещения программного кода с данными;
- Надежность в устойчивости к сбоям на уровне системы при наличии сбоев внутри компонентов, разъемов или данных. [7]
Архитектурные ограничения
Архитектурный стиль REST определяет шесть основных ограничений. [6] [8] Когда эти ограничения применяются к архитектуре системы, она приобретает желаемые нефункциональные свойства , такие как производительность, масштабируемость, простота, модифицируемость, наглядность, переносимость и надежность. [1]
Формальные ограничения REST следующие: [9]
- Клиент/Сервер. Клиенты отделены от серверов четко определенным интерфейсом.
- Без сохранения состояния — конкретный клиент не использует хранилище сервера, когда он «находится в состоянии покоя».
- Кэш. Ответы указывают на возможность кэширования.
- Единый интерфейс
- Многоуровневая система. Клиент обычно не может определить, подключен ли он напрямую к конечному серверу или к посреднику на этом пути.
- Код по требованию (необязательно). Серверы могут временно расширять или настраивать функциональность клиента, передавая клиенту логику, которая может выполняться на стандартной виртуальной машине.
Единый интерфейс [ править ]
Единообразное ограничение интерфейса имеет основополагающее значение для проектирования любой системы RESTful. [1] Это упрощает и отделяет архитектуру, что позволяет каждой части развиваться независимо. Четыре ограничения для этого универсального интерфейса:
- Идентификация ресурсов в запросах. Отдельные ресурсы идентифицируются в запросах с использованием URI . Сами ресурсы концептуально отделены от представлений, возвращаемых клиенту. Например, сервер может отправлять данные из своей базы данных в формате HTML , XML или JSON , ни один из которых не является внутренним представлением сервера.
- Манипулирование ресурсами посредством представлений. Когда клиент хранит представление ресурса, включая любые прикрепленные метаданные , у него есть достаточно информации для изменения или удаления состояния ресурса.
- Сообщения, не требующие описания: каждое сообщение содержит достаточно информации, чтобы описать, как его обработать. Например, какой парсер вызывать, можно указать типом носителя . [1]
- Гипермедиа как механизм состояния приложения ( HATEOAS ). Получив доступ к начальному URI для приложения REST (аналогично тому, как пользователь Интернета обращается к домашней странице веб-сайта), клиент REST затем должен иметь возможность динамически использовать предоставленные сервером ссылки для обнаружить все доступные ресурсы, которые ему необходимы. По мере доступа сервер отвечает текстом, который включает гиперссылки на другие доступные в данный момент ресурсы. Клиенту не требуется жестко запрограммировать информацию о структуре сервера. [10]
Модели классификации [ править ]
Было разработано несколько моделей, помогающих классифицировать REST API в соответствии с их соответствием различным принципам проектирования REST, например:
- Модель зрелости Ричардсона
- Классификация API на основе HTTP [11]
- WS 3 модель зрелости [12]
См. также [ править ]
- Чистый URL-адрес — URL-адрес, предназначенный для улучшения удобства использования веб-сайта.
- Сеть доставки контента – уровень интернет-экосистемы, устраняющий узкие места
- Протокол доменных приложений (DAP)
- Список схем URI — идентификатор пространства имен, присвоенный IANA.
- Микросервисы — совокупность слабосвязанных сервисов, используемых для создания компьютерных приложений.
- Обзор языков описания RESTful API – описания интерфейсов компьютерных сетей.
- Ресурсно-ориентированная архитектура . Архитектурный шаблон в разработке программного обеспечения.
- Ресурсно-ориентированные вычисления . Архитектурные шаблоны в разработке программного обеспечения.
- Сервис-ориентированная архитектура - архитектурный шаблон в разработке программного обеспечения.
- Веб-ориентированная архитектура . Архитектурный шаблон в разработке программного обеспечения.
- Веб-службы — услуги, предлагаемые между электронными устройствами через Интернет.
Ссылки [ править ]
- ^ Перейти обратно: а б с д Это ж Филдинг, Рой Томас (2000). «Глава 5: Передача представительского состояния (REST)» . Архитектурные стили и проектирование сетевых архитектур программного обеспечения (доктор философии). Калифорнийский университет в Ирвайне. Архивировано из оригинала 13 мая 2021 г. Проверено 17 августа 2004 г.
- ^ Филдинг, Рой Т. (20 октября 2008 г.). «REST API должны управляться гипертекстом» . roy.gbiv.com. Архивировано из оригинала 18 марта 2010 г. Проверено 6 июля 2016 г.
- ^ Моурри, Ник (2012). Медиа, общество, мир: социальная теория и практика цифровых медиа . Лондон: Полити Пресс. п. 2. ISBN 9780745639208 . Архивировано из оригинала 27 февраля 2024 г. Проверено 9 июня 2021 г.
- ^ Филдинг, Рой Томас (2000). «Глава 6: Опыт и оценка» . Архитектурные стили и проектирование сетевых архитектур программного обеспечения (доктор философии). Калифорнийский университет в Ирвайне. Архивировано из оригинала 26 марта 2023 г. Проверено 21 июня 2023 г.
- ^ «Филдинг, обсуждающий определение термина REST» . группы.yahoo.com. Архивировано из оригинала 5 ноября 2015 года . Проверено 8 августа 2017 г.
- ^ Перейти обратно: а б Эрл, Томас; Карлайл, Бенджамин; Паутассо, Чезаре; Баласубраманиан, Радж (2012). «5.1». SOA с REST: принципы, шаблоны и ограничения для создания корпоративных решений с помощью REST . Река Аппер-Седл, Нью-Джерси: Прентис-Холл. ISBN 978-0-13-701251-0 .
- ^ Перейти обратно: а б Филдинг, Рой Томас (2000). «Глава 2: Архитектура сетевых приложений» . Архитектурные стили и проектирование сетевых архитектур программного обеспечения (доктор философии). Калифорнийский университет в Ирвайне. Архивировано из оригинала 16 декабря 2014 г. Проверено 12 апреля 2014 г.
- ^ Ричардсон, Леонард; Руби, Сэм (2007). RESTful веб-службы . Севастополь, Калифорния: O'Reilly Media. ISBN 978-0-596-52926-0 .
- ^ «Что такое REST API?» . www.visual-paradigm.com . Архивировано из оригинала 24 февраля 2024 г. Проверено 24 февраля 2024 г.
- ^ Гупта, Локеш (2 июня 2018 г.). "РЕСТ ХАТЕОАС" . Учебное пособие по REST API . RESTfulAPI.net. Архивировано из оригинала 7 апреля 2019 года . Проверено 10 марта 2019 г.
- ^ «Классификация HTTP API» . algermissen.io . Архивировано из оригинала 29 января 2023 г. Проверено 29 января 2023 г.
- ^ Иван Сальвадори, Фрэнк Сикейра (июнь 2015 г.). «Модель зрелости для семантических веб-API RESTful» . Конференция: Веб-сервисы (ICWS), 2015 Международная конференция IEEE OnAt . Нью-Йорк. Архивировано из оригинала 27 февраля 2024 г. Получено 14 декабря 2020 г. - через Researchgate.
Дальнейшее чтение [ править ]
- Паутассо, Чезаре; Уайльд, Эрик; Аларкон, Роза (2014), REST: темы перспективных исследований и практические применения , Springer, ISBN 9781461492986
- Паутассо, Чезаре; Циммерманн, Олаф; Лейманн, Франк (апрель 2008 г.), «Restful веб-сервисы против «больших» веб-сервисов», Труды 17-й международной конференции по Всемирной паутине , стр. 805–814, doi : 10.1145/1367497.1367606 , ISBN 9781605580852 , S2CID 207167438
- Феррейра, Отавио (ноябрь 2009 г.), Семантические веб-службы: подход RESTful , IADIS, ISBN 978-972-8924-93-5
- Фаулер, Мартин (18 марта 2010 г.). «Модель зрелости Ричардсона: шаги к славе REST» . martinfowler.com . Проверено 26 июня 2017 г.
