Кешируемый ли PUT

Кешируемый ли PUT?

Да, HTTP метод PUT по своей природе является кешируемым, согласно стандартам HTTP/1.1 (RFC 7231) и HTTP/1.0. Однако его кеширование имеет специфические условия и ограничения, которые сильно отличаются от кеширования GET запросов.

Почему PUT считается кешируемым?

Согласно RFC 7231 (раздел 4.2.3), методы GET, HEAD, POST и PUT явно указаны как кешируемые. Это означает, что ответы на эти запросы могут быть сохранены в кеше (например, в браузере, прокси-сервере или CDN) для потенциального повторного использования. Ключевым критерием является то, что метод должен быть idempotent (идемпотентным), т.е. многократное выполнение одного и того же запроса с одинаковыми данными должно приводить к одному и тому же состоянию ресурса, как и первое выполнение. PUT идеально соответствует этому критерию.

Специфика кеширования PUT

В отличие от GET, где кеширование основано на URL и параметрах запроса, кеширование для PUT (и POST) зависит от содержимого самого запроса (тела запроса) и его URI. Это логично, поскольку PUT предназначен для создания или полного обновления ресурса на указанном URI.

Основные правила кеширования ответов на PUT:

• Ответ можно закешировать, если он содержит явные директивы кеширования (Cache-Control, Expires, ETag).
• Ключом для кеша является URI запроса + тело запроса (payload). Ответ на PUT с другим содержимым тела, даже для того же URI, будет считаться другим запросом и не будет использовать закешированный ответ.
• Кешированный ответ на PUT может быть использован только для последующих идентичных PUT запросов (совпадающий URI и идентичное тело запроса). Это делает его практическое применение очень узким.

Практические примеры и сценарии

В реальности кеширование PUT используется крайне редко из-за его ограниченной полезности. Рассмотрим пример с API для обновления пользователя:

PUT /users/123
Content-Type: application/json

{
  "name": "Иван Иванов",
  "email": "ivan@example.com"
}

Ответ сервера может содержать заголовки кеширования:

HTTP/1.1 200 OK
Cache-Control: max-age=3600, private
ETag: "abc123"
Content-Type: application/json

{
  "id": 123,
  "name": "Иван Иванов",
  "email": "ivan@example.com"
}

Теперь, если клиент точно в течение часа и без изменений отправит тот же PUT запрос с тем же JSON телом на /users/123, браузер или клиентская библиотека могут (теоретически) использовать закешированный ответ, не отправляя запрос на сервер. Однако это маловероятно, так:

• Обновления данных обычно не повторяются идентично моментально.
• Большинство клиентов не реализуют кеширование для методов, изменяющих состояние.
• Серверы часто отправляют Cache-Control: no-store или no-cache для PUT/POST в целях безопасности и сохранения консистентности данных.

Важные ограничения и почему это редко используется

1. Консистентность данных: Автоматическое использование кешированного ответа для PUT может создать проблемы, если данные на сервере были изменены другим клиентом. Клиент получит "успешный" старый ответ из кеша, не узнав о реальном текущем состоянии ресурса.
2. Директивы сервера: Серверы практически всегда явно запрещают кеширование для PUT через заголовки Cache-Control: no-store или must-revalidate. Это стандартная практика для безопасности и актуальности данных.
3. Сложность реализации: Кеш должен сравнивать не только URL, но и полное тело запроса (которое может быть большим), что делает ключ кеша сложным и хранение неэффективным.
4. Ограниченная выгода: Потенциальная экономия трафика и времени при повторении абсолютно идентичного запроса PUT ничтожна в сравнении с рисками.

Роль ETag и Conditional Requests (Условные запросы)

Для PUT гораздо более важную роль играют не общее кеширование, а условные запросы с использованием ETag или Last-Modified. Клиент может включить заголовки If-Match или If-Unmodified-Since в свой PUT запрос, чтобы сервер выполнил обновление только если ресурс не изменился с момента последнего обращения клиента. Это предотвращает конфликты параллельных обновлений и является основным механизмом обеспечения консистентности для методов изменения состояния.

PUT /users/123
Content-Type: application/json
If-Match: "abc123"

{
  "name": "Иван Петров",
  "email": "ivan.petrov@example.com"
}

Вывод для QA Engineer

Как специалист по тестированию, вы должны понимать эту теорию, но в практических тестах API:

• Ожидайте, что сервер запрещает кеширование PUT: Проверяйте, что ответы на PUT содержат Cache-Control: no-store, no-cache или аналогичные директивы.
• Не ожидайте, что клиент (браузер) реально закеширует PUT: Это скорее теоретическая возможность, которую современные клиенты игнорируют.
• Фокусируйтесь на тестировании условных запросов (Conditional PUT): Это критически важный функционал для предотвращения конфликтов. Тестируйте сценарии с правильными и неверными ETag, проверяйте статусы ответов (200 OK, 412 Precondition Failed).
• Проверяйте идемпотентность: Многократная отправка одного и того же PUT запроса должна приводить к одному и тому же конечному состоянию ресурса и возвращать одинаковые успешные ответы (например, 200 или 204).

Таким образом, хотя PUT формально кешируемый, его эффективное и безопасное использование в веб-приложениях связано не с классическим кешированием ответов, а с механизмами контроля версий ресурсов через условные запросы.