REST (Representational State Transfer) — это архитектурный стиль, который использует возможности HTTP-протокола, но при этом добавляет определённые принципы и ограничения для того, чтобы построить более удобную, надёжную и масштабируемую систему для взаимодействия между клиентом и сервером.
Хотя HTTP сам по себе предоставляет методы (GET, POST, PUT, DELETE и др.), REST вводит дополнительные рекомендации и концепции, которые делают его особенно полезным для разработки веб-сервисов. Рассмотрим, зачем нужен REST и что он добавляет к базовым возможностям HTTP:
1. Чёткое разделение ресурсов
В REST ресурсы (например, пользователь, документ, товар и т.д.) идентифицируются уникальными URI.
Например, /users/123 может обозначать пользователя с ID 123.
REST рассматривает всё как ресурсы, и каждое действие выполняется над этим ресурсом.
Зачем это нужно?
Это делает структуру API понятной и предсказуемой. Клиент всегда знает, как получить доступ к конкретному ресурсу и какие операции можно над ним выполнять.
2. Использование стандартных HTTP-методов с семантикой
REST основывается на стандартных HTTP-методах, но при этом чётко задаёт их назначение:
- GET — получение данных,
- POST — создание нового ресурса,
- PUT — обновление существующего ресурса,
- DELETE — удаление ресурса.
Зачем это нужно?
Это способствует унификации интерфейсов. Программисты могут легко понять, какие действия выполнять, зная контекст ресурса и HTTP-метод.
3. Отсутствие состояния на стороне сервера (statelessness)
В REST-системах сервер не хранит состояние сеансов клиента.
Вся необходимая информация для выполнения запроса передаётся клиентом в каждом запросе. Это может быть информация об аутентификации, параметры и контекст запроса.
Зачем это нужно?
Это упрощает масштабирование систем, так как серверы могут обрабатывать запросы независимо друг от друга, не связывая их с предыдущими действиями клиента.
4. Кэширование
REST предполагает, что каждый ответ может быть кэшируемым, если это целесообразно.
Сервер может включать заголовки, которые указывают клиенту, можно ли и как долго кэшировать ответ.
Зачем это нужно?
Это позволяет уменьшить нагрузку на сервер и повысить производительность за счёт повторного использования данных.
5. Единый интерфейс (Uniform Interface)
REST стремится к тому, чтобы взаимодействие между клиентом и сервером было стандартизировано и использовало единые интерфейсы для работы с разными типами ресурсов. Это достигается за счёт:
- использования единого набора HTTP-методов;
- использования стандартных кодов состояния (например, 200 ОК, 404 Not Found, 500 Internal Server Error);
- передачи данных в стандартных форматах (например, JSON или XML).
Зачем это нужно?
Это облегчает разработку и интеграцию, так как клиенты и серверы могут взаимодействовать, не зная много о внутренней логике друг друга.
6. Гипермедийный контроль (HATEOAS)
Одним из важных аспектов REST является концепция HATEOAS (Hypermedia as the Engine of Application State), которая подразумевает, что сервер должен предоставлять гиперссылки в ответах, по которым клиент может переходить для выполнения дальнейших операций.
Основная идея заключается в том, что клиент, взаимодействуя с сервером, получает не только данные, но и ссылки на другие доступные ресурсы или возможные действия, что делает взаимодействие с API более гибким и динамичным.
Примечание: Далеко не все REST API используют концепцию HATEOAS
Пример с HATEOAS
Реальные примеры использования HATEOAS
- GitHub API:
GitHub API активно использует концепцию HATEOAS. Например, при запросе списка репозиториев, клиент получает не только данные о репозиториях, но и ссылки на возможные действия (например, создание новых веток, обновление репозитория и т.д.).
- PayPal API:
PayPal API также использует HATEOAS для управления действиями на платежных транзакциях. Клиент получает ссылки на возможные действия (например, подтверждение, отмену транзакции и т.д.) в зависимости от текущего состояния транзакции.
Зачем это нужно?
Это позволяет клиентам динамически находить доступные действия без необходимости жёсткого кодирования логики на стороне клиента.
7. Масштабируемость
Поскольку REST делает акцент на независимости запросов и минимизации состояния, это упрощает горизонтальное масштабирование серверов, что важно для высоконагруженных систем.
8. Простота и универсальность
REST не требует сложных протоколов или форматов данных.
Он работает поверх HTTP и может использовать распространённые форматы данных, такие как JSON, XML и др.
Это делает его простым для реализации и понимания.
Заключение: зачем REST, если есть HTTP?
REST не просто использует HTTP, он накладывает на него архитектурные ограничения и принципы, которые делают взаимодействие между клиентом и сервером более структурированным, масштабируемым и предсказуемым.
HTTP может существовать и без REST, но REST помогает разработчикам проектировать API более логично, эффективно и с понятной архитектурой.
А разве statelessness и Единый интерфейс (Uniform Interface) не определяется самим HTTP?
Если вы тоже задали себе этот вопрос, вы правы в том, что принципы statelessness (отсутствие состояния) и Uniform Interface (единый интерфейс) частично встроены в сам HTTP-протокол.
Однако REST определяет эти принципы на более высоком уровне, делая их обязательными и более структурированными для построения API.
Давайте разберёмся подробнее, как это работает в контексте HTTP и REST.
1. Statelessness (отсутствие состояния)
В контексте HTTP:
HTTP-протокол изначально был спроектирован как без сохранения состояния (stateless). Каждый запрос HTTP от клиента к серверу обрабатывается как независимый, и сервер не хранит информацию о предыдущих запросах (например, что клиент залогинен или какие ресурсы он раньше запрашивал). Это означает, что каждый HTTP-запрос должен содержать все необходимые данные для его обработки (например, идентификацию пользователя через куки или токены).
В контексте REST:
REST накладывает обязательное требование на то, чтобы сервер не хранил информацию о состоянии клиента между запросами. Это делает REST-системы по-настоящему распределёнными и масштабируемыми. Клиент обязан включать всю необходимую информацию в каждом запросе (например, токен аутентификации, параметры контекста).
Хотя HTTP сам по себе является stateless, REST делает это требование центральным принципом при проектировании API. В то время как в обычных HTTP-сервисах разработчики могут использовать сессии и хранить состояние на сервере (например, через сессионные куки), в REST это считается нарушением архитектурных принципов.
Ключевая разница:
- HTTP протокол не запрещает серверу хранить состояние клиента, хотя и подразумевает работу без него.
- REST же делает отсутствие состояния обязательным требованием для API. Это улучшает масштабируемость и отказоустойчивость системы, так как серверы не зависят от состояния клиентов.
2. Uniform Interface (единый интерфейс)
В контексте HTTP:
HTTP-протокол предоставляет стандартный интерфейс для взаимодействия с сервером:
- Методы (GET, POST, PUT, DELETE и другие),
- URI для идентификации ресурсов,
- Стандартные коды состояния (например, 200 OK, 404 Not Found),
- Заголовки для передачи метаданных (например, Content-Type, Authorization),
- Тела запросов и ответов, которые могут быть разными (например, HTML, JSON, XML).
Это даёт базовую основу для взаимодействия между клиентом и сервером.
В контексте REST:
REST усиливает использование единого интерфейса, делая его ключевым принципом архитектуры. REST-интерфейс должен быть предсказуемым и стандартизированным для всех ресурсов и операций. Это включает:
- Использование четко определённых методов (GET для чтения, POST для создания, PUT для обновления, DELETE для удаления),
- Способ адресации ресурсов через URI,
- Использование стандартных кодов состояния и заголовков HTTP для передачи информации,
- Поддержку гипермедиа (HATEOAS), где сервер предоставляет не только данные, но и гиперссылки для дальнейших операций.
REST усиливает концепцию "Uniform Interface" до такой степени, что это становится фундаментом всей архитектуры:
1. Ресурсы: Каждый объект (ресурс) должен иметь уникальный URI.
2. Методы и операции: Операции над ресурсами должны быть стандартизированы через HTTP-методы.
3. Стандарты взаимодействия: В REST API клиент и сервер взаимодействуют через стандартизированные форматы данных (например, JSON или XML), что позволяет легко интегрировать различные клиенты и серверы.
Ключевая разница:
- HTTP предоставляет возможность стандартизации взаимодействия, но не требует строгого следования принципам единого интерфейса. Разработчики могут использовать кастомные методы и подходы.
- REST же делает единый интерфейс обязательным требованием, что упрощает разработку клиента и сервера, минимизирует ошибки и улучшает совместимость.
Заключение:
Хотя принципы statelessness и Uniform Interface действительно заложены в сам HTTP-протокол, REST формализует эти принципы и делает их обязательными для реализации в API. В то время как HTTP предоставляет инструменты для реализации этих концепций, REST настаивает на их строгом соблюдении, чтобы обеспечить простоту, масштабируемость и предсказуемость взаимодействия между клиентом и сервером.
Если Вам интересно, что еще можно найти на канале QA Helper, прочитайте статью: Вместо оглавления. Что вы найдете на канале QA Helper - справочник тестировщика?
Не забудьте подписаться на канал, чтобы не пропустить полезную информацию: QA Helper - справочник тестировщика
Пишите в комментариях какой пункт было бы интересно рассмотреть более подробно.
Обязательно прочитайте: Что должен знать и уметь тестировщик
Также будет интересно почитать: Вопросы которые задают на собеседовании тестировщикам
