Каковы основные принципы тестирования HTTP-метода PUT в REST API?

«Каковы основные принципы тестирования HTTP-метода PUT в REST API?» — вопрос из категории API тестирование, который задают на 10% собеседований QA Тестировщик. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

PUT предназначен для полного замещения ресурса по указанному URI. Если ресурс существует, он обновляется, если нет — создается (хотя создание через PUT встречается реже). Ключевой принцип — идемпотентность.

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

  1. Идемпотентность: Повторный идентичный PUT-запрос должен приводить к тому же состоянию ресурса, что и первый. Это критично для надежности и повторных отправок.

  2. Семантика полного замещения:

    • Клиент должен отправить полное валидное представление ресурса.
    • Поля, не указанные в запросе, должны быть установлены в значения по умолчанию или null (в соответствии с логикой API), а не сохранены из предыдущей версии.
    • Пример кода на Python с библиотекой requests:

      import requests
      
      def test_put_update_user():
          url = "https://api.example.com/users/1"
          # Полное представление пользователя
          data = {"id": 1, "name": "Updated Name", "email": "updated@example.com", "age": 30}
          response = requests.put(url, json=data)
          assert response.status_code == 200  # Или 204 No Content
          # Проверяем, что ресурс полностью соответствует отправленным данным
          get_response = requests.get(url)
          assert get_response.json() == data
  3. Коды ответов:

    • 200 OK или 204 No Content при успешном обновлении существующего ресурса.
    • 201 Created — если ресурс был создан.
    • 400 Bad Request — при невалидных данных в теле запроса.
    • 404 Not Found — если ресурс не существует и API не поддерживает создание через PUT.
    • 409 Conflict — при конфликте обновления.
  4. Валидация: Аналогична POST: проверка обязательных полей, форматов, бизнес-правил. Поскольку PUT требует полного представления, валидация должна применяться ко всему телу запроса.

  5. Конкурентность: Важно тестировать сценарии, когда два клиента пытаются обновить один ресурс. Использование заголовков If-Match (ETag) или If-Unmodified-Since помогает предотвратить потерю данных (Optimistic Locking).