REST (REpresentational State Transfer) – это архитектурный стиль для распределенных систем. Рой Филдинг впервые представил его в 2000 году в своей знаменитой диссертации.
Как и другие архитектурные стили, REST имеет свои основные принципы и ограничения. Если эти принципы соблюдаются, то приложение можно назвать RESTful.
Web API (или Web-сервис), соответствующий архитектурному стилю REST, является REST API.
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.
1. Основные принципы REST
Шесть основных принципов или ограничений архитектуры RESTful:
1.1 Единство интерфейса (Uniform Interface)
Следующие четыре ограничения позволяют добиться единства интерфейса REST:
- Идентификация ресурсов – каждый ресурс взаимодействия между клиентом и сервером должен иметь уникальный идентификатор.
- Обработка ресурсов через представления – когда клиент запрашивает ресурс, сервер возвращает не только сами данные, но и способ представления этих данных. Например, если клиент запрашивает информацию о статье, сервер может вернуть как текст статьи, так и информацию о форматировании, изображениях и т.д.
- Самодокументируемость– каждый запрос, отправляемый от клиента к серверу, должен содержать достаточно информации для того, чтобы понять, как обработать этот запрос. Это может включать в себя информацию о том, какой тип данных передается, как его интерпретировать и какие действия с ним можно выполнять.
- Гипермедиа как двигатель состояния приложения – клиенту достаточно знать только начальный URI приложения. Все остальные шаги и ресурсы клиент может находить и взаимодействовать с ними с помощью гиперссылок, предоставленных сервером. Это позволяет создавать более гибкие и динамичные взаимодействия между клиентом и сервером.
1.2 Отделение клиента от сервера (Client-Server)
Клиент-серверная архитектура обеспечивает разделение ответственности, что помогает клиенту и серверу развиваться независимо друг от друга.
Разделение ответственности пользовательского интерфейса (клиента) и хранения данных (сервера) позволяет улучшить переносимость пользовательского интерфейса на различные платформы и повысить масштабируемость серверного хранения данных.
1.3 Отсутствие записи состояния клиента (Stateless)
Stateless предполагает, что каждый запрос от клиента к серверу должен содержать всю информацию, необходимую для понимания и выполнения запроса.
Клиентское приложение должно полностью управлять состоянием сессии.
1.4 Кэшируемость (Casheable)
Ограничение cacheable требует, чтобы ответ к запросу обозначал себя как кэшируемый или некэшируемый.
Если ответ является кэшируемым, то клиентское приложение получает право повторно использовать данные ответа в дальнейшем для эквивалентных запросов и в течение указанного периода времени.
1.5. Многоуровневость системы (Layered System)
Многоуровневая архитектура – это когда система разделена на уровни, и каждый уровень определяет, как компоненты могут взаимодействовать друг с другом.
В многоуровневой системе каждый компонент не может видеть дальше того слоя системы, с которым он взаимодействует.
1.6. Предоставление кода по запросу (Code on Demand)
REST также позволяет расширять функциональность клиента путем загрузки и выполнения кода с сервера.
Загружаемый код упрощает работу клиентов, уменьшая количество функций, которые должны быть заранее включены в самом приложении. Серверы могут предоставлять часть функций клиенту в виде кода, а клиенту остается только выполнить этот код.
2. Что такое ресурс?
Ключевой абстракцией информации в REST является ресурс. Любая информация может быть ресурсом. Например, ресурсом REST может быть документ или изображение, коллекция других ресурсов или какой-либо объект.
Состояние ресурса в любой конкретный момент времени называется представлением ресурса.
Представления ресурсов состоят из:
- данных
- метаданных, описывающих эти данные
- и гипермедийных ссылок, которые могут помочь клиентам перейти к следующему желаемому состоянию ресурса.
REST API состоит из набора взаимосвязанных ресурсов. Этот набор ресурсов называется ресурсной моделью REST API.
2.1. Идентификаторы ресурсов
REST использует специальные идентификаторы для определения каждого ресурса, участвующего во взаимодействии между клиентом и сервером.
2.2. Гипермедиа
Формат данных, в котором представлена информация, называется медиатипом . Этот тип указывает, как нужно обрабатывать представление.
RESTful API выглядит как гипертекст. Каждая “часть” информации имеет свой адрес.
2.3. Самодокументируемость
Представления ресурсов должны быть самодокументируемыми. “Самодокументируемость” означает, что информация должна быть организована так , чтобы можно было понять, какие данные она содержит и как с ними обращаться. Например, если речь идет о товаре, информация о нём должна быть устроена так, чтобы было понятно, где находится название, цена, описание и так далее.
Каждый медиатип определяет модель обработки по умолчанию. Например, HTML определяет процесс отображения гипертекста и поведение браузера для каждого элемента.
3. Методы запросов
Одним из ключевых аспектов REST являются методы запросов. Эти методы помогают переходить от одного состояния ресурса к другому. Другими словами, они говорят, что мы можем делать с информацией о ресурсе.
Многие ошибочно связывают методы ресурсов с методами HTTP (т.е. GET/PUT/POST/DELETE). Рой Филдинг никогда не давал никаких рекомендаций относительно того, какой метод следует использовать в какой ситуации. Он лишь подчеркивал, что должно соблюдаться единство интерфейса.
Для примера, допустим, мы решаем использовать HTTP POST для обновления информации о ресурсе, хотя многие предпочитают HTTP PUT. Всё равно, какой бы метод мы не использовали, интерфейс нашего приложения будет соответствовать принципам REST.
В идеале все, что необходимо для перехода состояния ресурса, должно быть частью представления ресурса – включая все поддерживаемые методы.
Допустим, у нас есть информация о каком-то объекте, например, о фильме. Идеально было бы, если всё, что нам нужно знать, чтобы перейти от одного состояния этого объекта (например, отображения информации о фильме) к другому (например, его обновления), было бы включено в описание этого объекта.
Многие предпочитают сравнивать HTTP с REST. REST и HTTP – это не одно и то же.
REST != HTTP
5. Вывод
В архитектурном стиле REST данные и функциональность считаются ресурсами, доступ к которым осуществляется с помощью URI (Uniform Resource Identifier).
Действия с ресурсами осуществляются с помощью набора простых, четко определенных операций. Кроме того, ресурсы должны быть отделены от их представления, чтобы клиенты могли получать доступ к содержимому в различных форматах, таких как HTML, XML, plain-text, PDF, JPEG, JSON и др.
Клиенты и серверы обмениваются представлениями ресурсов с помощью протокола (как правило, наиболее часто используется протокол HTTP, но REST не требует его обязательного использования).
Метаданные – это как дополнительная информация о ресурсе, которая помогает в :
- Управлении кэшированием: Мы можем решить, насколько долго сохранять информацию о ресурсе, чтобы не приходилось всегда обращаться за ней.
- Обнаружении ошибок передачи: Мы можем понять, если что-то пошло не так в процессе передачи данных между клиентом и сервером.
- Выборе правильного формата представления: Мы можем определить, какой формат данных выбрать для представления ресурса, чтобы он был понятен клиенту.
- Аутентификации или контроле доступа: Эта информация может использоваться для проверки подлинности пользователя или управления правами доступа к ресурсу.
И самое главное – каждое взаимодействие с сервером должно быть без сохранения состояния.
Все эти принципы помогают RESTful-приложениям быть простыми, легкими и быстрыми.
Перевод статьи «What is REST».