Может ли GET изменять ресурс?

Может ли GET изменять ресурс? Общее правило и исключения

Теоретически, согласно стандартам HTTP, метод GET предназначен исключительно для чтения (retrieval) данных и не должен изменять состояние ресурса на сервере. Его основная цель — безопасное получение информации без побочных эффектов. Однако в реальной практике существуют исключения и спорные случаи, где GET может косвенно или даже напрямую приводить к изменениям.

Стандартное определение и принципы REST

По спецификации HTTP (RFC 9110) и принципам RESTful API, GET является идемпотентным и безопасным методом.

• Идемпотентность: Многократные идентичные запросы GET должны возвращать одинаковый результат и не менять состояние системы.
• Безопасность: Метод не должен вызывать изменений на сервере.

В чистом REST, использование GET для операций, изменяющих данные (например, удаление или обновление), считается нарушением архитектурного стиля и плохой практикой, так как это:

1. Делает API неинтуитивным и непредсказуемым.
2. Создает риски безопасности (например, изменение данных при простом открытии ссылки в браузере).
3. Мешает правильной работе кэширования и веб-инженеров (кэш может некорректно хранить результаты "изменяющих" GET-запросов).

Практические исключения и случаи "изменения"

В реальных приложениях GET иногда может вызывать изменения, хотя это противоречит стандартам:

1. Логирование и аудит (Side Effects):

    Сервер может вести журнал запросов (логи доступа, аналитика) при каждом GET. Сам ресурс не меняется, но в системе создаются новые данные (записи в лог-файле). Это считается приемлемым побочным эффектом.

1. Неявное изменение состояния сессии или пользователя:

    Пример — GET запрос к странице, которая также увеличивает счетчик просмотров или обновляет время последней активности пользователя в его профиле. Ресурс (страница) возвращается корректно, но связанные с ним данные изменяются.

1. Устаревшие или нестандартные реализации (Historical Abuse):

    В прошлом некоторые API использовали GET для выполнения действий, например, для удаления элемента через параметр в URL (`/api/item/delete?id=123`). Это **крайне плохая практика** с точки зрения безопасности (CSRF-атаки) и семантики HTTP. Для таких операций должны использоваться методы **DELETE** или **POST**.

1. Кэширование на клиенте:

    Сам запрос GET может изменять состояние **клиента** — браузер или приложение кэширует полученные данные, что изменяет локальное состояние клиентской системы.

Пример: Некорректное использование GET для изменения (Плохая практика)

GET /api/users/123/disable?confirm=true

В этом примере GET запрос теоретически "отключает" пользователя. Это нарушает стандарты и создает опасность:

• Браузер может предварительно выполнить запрос при предзагрузке.
• Ссылка может быть случайно открыта или отправлена.
• Кэш может сохранить ответ "пользователь отключен", который не актуален после восстановления.

Правильная реализация должна использовать метод POST, PUT или PATCH:

POST /api/users/123/disable
Content-Type: application/json

{
  "confirm": true
}

Вывод и рекомендации

Метод GET в своем чистом виде не должен изменять основной целевой ресурс. Однако он может вызывать побочные эффекты (логирование, обновление счетчиков), которые не изменяют сущность запрашиваемых данных. Использование GET для явных модификаций (создание, изменение, удаление) является архитектурной ошибкой и должно быть заменено соответствующими методами:

• POST — для создания или действий с неопределенным эффектом.
• PUT/PATCH — для обновления.
• DELETE — для удаления.

QA инженер при тестировании API должен проверять соответствие методов HTTP их семантике и указывать на нарушения как на потенциальные дефекты, особенно связанные с безопасностью и корректностью работы системы.