REST ( передача репрезентативного состояния ) — это архитектурный стиль программного обеспечения , созданный для руководства при проектировании и разработке архитектуры Всемирной паутины . 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, которое может негативно повлиять на общее кэширование и масштабируемость сервера. Файлы cookie HTTP также нарушают ограничения REST, поскольку они могут рассинхронизироваться с состоянием приложения браузера, что делает их ненадежными; они также содержат непрозрачные данные, которые могут представлять угрозу конфиденциальности и безопасности .
Архитектурный стиль REST предназначен для сетевых приложений, в частности приложений клиент-сервер. Более того, он предназначен для использования в масштабах Интернета, поэтому связь между пользовательским агентом (клиентом) и исходным сервером должна быть как можно более свободной , чтобы облегчить широкомасштабное внедрение.
Сильное разделение клиента и сервера вместе с текстовой передачей информации с использованием единого протокола адресации обеспечило основу для удовлетворения требований Интернета: надежность (анархическая масштабируемость), независимое развертывание компонентов, крупномасштабная передача данных и низкий входной барьер для читателей контента, авторов контента и разработчиков.
Ограничения архитектурного стиля REST влияют на следующие архитектурные свойства: [1] [6]
Архитектурный стиль REST определяет шесть основных ограничений. [6] [8] Когда эти ограничения применяются к архитектуре системы, она приобретает желаемые нефункциональные свойства , такие как производительность, масштабируемость, простота, модифицируемость, наглядность, переносимость и надежность. [1]
Формальные ограничения REST следующие:
Шаблон проектирования клиент-сервер реализует принцип разделения задач : отделение проблем пользовательского интерфейса от проблем хранения данных. Таким образом, улучшается переносимость пользовательского интерфейса. В случае с Интернетом для большинства платформ было разработано множество веб-браузеров, без необходимости знания каких-либо реализаций серверов. Разделение также упрощает серверные компоненты, улучшая масштабируемость, но, что более важно, оно позволяет компонентам развиваться независимо (анархическая масштабируемость), что необходимо в среде масштаба Интернета, включающей несколько организационных доменов.
В вычислениях протокол без сохранения состояния — это протокол связи , в котором получатель, обычно сервер, не сохраняет информацию о сеансе. Соответствующие данные сеанса отправляются клиентом получателю таким образом, что каждый передаваемый пакет информации можно понять изолированно, без контекстной информации из предыдущих пакетов в сеансе. Это свойство протоколов без сохранения состояния делает их идеальными для приложений с большим объемом данных, повышая производительность за счет устранения нагрузки на сервер, вызванной сохранением информации о сеансе.
Как и во Всемирной паутине, клиенты и посредники могут кэшировать ответы. Ответы должны явно или неявно определять себя как кэшируемые или некэшируемые, чтобы клиенты не могли предоставлять устаревшие или неподходящие данные в ответ на дальнейшие запросы. Хорошо управляемое кэширование частично или полностью исключает некоторые взаимодействия клиент-сервер, что еще больше повышает масштабируемость и производительность. Кэширование может выполняться на клиентском компьютере в памяти или в хранилище кэша браузера. Кроме того, кеш может храниться в сети доставки контента (CDN).
Клиент обычно не может определить, подключен ли он напрямую к конечному серверу или к посреднику на этом пути. Если между клиентом и сервером установлен прокси-сервер или балансировщик нагрузки , это не повлияет на их связь, и не возникнет необходимости обновлять код клиента или сервера. Промежуточные серверы могут улучшить масштабируемость системы , обеспечивая балансировку нагрузки и предоставляя общий кэш. Кроме того, безопасность может быть добавлена как уровень поверх веб-сервисов, отделяя бизнес-логику от логики безопасности. [9] Добавление безопасности в качестве отдельного уровня обеспечивает соблюдение политик безопасности . Наконец, промежуточные серверы могут вызывать несколько других серверов для генерации ответа клиенту.
Серверы могут временно расширять или настраивать функциональность клиента путем передачи исполняемого кода: например, скомпилированных компонентов, таких как Java-апплеты , или клиентских сценариев, таких как JavaScript .
Единообразное ограничение интерфейса имеет основополагающее значение для проектирования любой системы RESTful. [1] Он упрощает и отделяет архитектуру, что позволяет каждой части развиваться независимо. Четыре ограничения для этого универсального интерфейса:
Было разработано несколько моделей, помогающих классифицировать REST API в соответствии с их соответствием различным принципам проектирования REST, например:
API-интерфейсы веб-сервисов , которые соответствуют архитектурным ограничениям REST, называются API-интерфейсами RESTful. [13] API RESTful на основе HTTP определяются со следующими аспектами: [14]
В отличие от веб-сервисов на основе SOAP , для веб-API RESTful не существует «официального» стандарта. Это связано с тем, что REST — это архитектурный стиль, а SOAP — это протокол. REST сам по себе не является стандартом, но реализации RESTful используют такие стандарты, как HTTP , URI , JSON и XML . Многие разработчики описывают свои API как RESTful, даже несмотря на то, что эти API не удовлетворяют всем описанным выше архитектурным ограничениям (особенно ограничениям единого интерфейса). [2] Большинство API, претендующих на RESTful, на самом деле соответствуют только уровню 2 модели зрелости Ричардсона .
{{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка )