Вы много знаете про REST, но уверены ли вы, что все ваши представления о нем - правда? Рассмотрим самые популярные мифы про REST!
🍋 Любой HTTP-сервис — это REST API
Заблуждение: Многие считают, что если API общается по HTTP-протоколу, значит оно соответствует принципам REST.
Реальность: Просто использование HTTP не означает соблюдение принципов REST. Для того чтобы API было RESTful, оно должно соответствовать следующим критериям:
- Ресурсно-ориентированная структура.
- Использование методов HTTP соответствующим образом (GET, POST, PUT, DELETE и др.).
- Отсутствие состояния на стороне сервера (stateless).
- Кэшируемость результатов запросов.
- Наличие единой точки входа (uniform interface).
Многие API нарушают хотя бы одно из этих правил, несмотря на применение HTTP.
🍊 Только GET-запросы должны возвращать состояние клиента
Заблуждение: Некоторые полагают, что методы HTTP такие как GET предназначены исключительно для чтения данных, а остальные методы (POST, PUT, DELETE) нужны лишь для изменения данных.
Реальность: Любые запросы в RESTful API могут возвращать полезные данные клиенту независимо от метода. Даже запросы POST, PUT или DELETE могут вернуть статус операции, обновленные данные или другой полезный отклик.
🍐 REST API обязательно возвращает JSON
Заблуждение: Часто встречается мнение, что REST API всегда передаёт данные в формате JSON.
Реальность: REST предполагает гибкость форматов данных. API может отвечать XML, YAML, protobuf или даже двоичными файлами, главное — соблюдать принципы REST.
🍓 Каждая сущность должна иметь уникальный URI
Заблуждение: Считается, что каждый объект в системе обязан иметь собственный URL.
Реальность: По сути, REST допускает создание составных сущностей, агрегированных ресурсов и множественных связей. Главное правило — обеспечить прозрачность и единообразие организации маршрутов.
🫐 PUT-запросы заменяют весь ресурс целиком
Заблуждение: Есть заблуждение, что метод PUT предназначен только для полной замены существующего ресурса.
Реальность: PUT может использоваться как для обновления всего ресурса, так и для частичного обновления полей. Важнее сохранять консистентность состояния ресурса и следовать семантике PUT: повторный вызов одного и того же PUT-запроса не должен приводить к изменениям (idempotence).
🍑 Все ресурсы должны находиться на одном уровне
Заблуждение: Иногда считают, что ресурсы должны располагаться на одном уровне иерархии (например,
/users, /products), и нельзя создавать вложенность вроде /users/{id}/orders.Реальность: Группировка ресурсов и вложенность вполне допустимы в REST, если они соответствуют бизнес-логике и делают структуру ясной и интуитивной.
🔚
Рассказывайте, у кого совпало?)