Что такое PATCH?

Что такое HTTP-метод PATCH?

PATCH — это один из методов протокола HTTP (Hypertext Transfer Protocol), который используется для частичного обновления ресурса на сервере. В отличие от метода PUT, который предполагает полную замену ресурса, PATCH предназначен для применения к ресурсу набора изменений (так называемого "патча"), описанного в теле запроса. Это делает его более эффективным для сценариев, где необходимо изменить только определенные поля, не пересылая весь объект целиком.

Ключевые особенности PATCH

• Частичное обновление: Клиент отправляет только те данные, которые необходимо изменить. Например, если у объекта пользователя 10 полей, а нужно обновить только поле email, то в запросе PATCH будет только это поле, а не весь JSON-объект пользователя.
• Идемпотентность (условно): В отличие от PUT, метод PATCH не является идемпотентным по умолчанию. Однако стандарт (RFC 5789) рекомендует делать PATCH-запросы идемпотентными, где это возможно. Это означает, что если один и тот же корректный PATCH-запрос будет отправлен несколько раз, состояние ресурса на сервере должно быть таким же, как и после однократного применения. Реализация идемпотентности ложится на разработчика серверной логики.
• Формат описания изменений: Стандарт не диктует конкретный формат описания изменений ("патча"). Это может быть собственный формат, JSON Merge Patch (RFC 7396) или, что чаще и предпочтительнее, JSON Patch (RFC 6902).

---

Сравнение PATCH с PUT

---

Форматы PATCH-запросов

Чаще всего используются два формата:

1. JSON Merge Patch (RFC 7396)

Более простой формат. Чтобы обновить поле, вы указываете его новое значение. Чтобы удалить поле — устанавливаете его значение в null.

Пример запроса:

PATCH /api/users/123 HTTP/1.1
Host: example.com
Content-Type: application/merge-patch+json

{
    "email": "new.email@example.com",
    "age": 31
}

В этом примере обновляются только поля email и age. Остальные поля остаются без изменений.

2. JSON Patch (RFC 6902)

Более мощный и стандартизированный формат. Описывает изменения как массив операций: add, remove, replace, move, copy, test.

Пример запроса:

PATCH /api/users/123 HTTP/1.1
Host: example.com
Content-Type: application/json-patch+json

[
    { "op": "replace", "path": "/email", "value": "new.email@example.com" },
    { "op": "add", "path": "/address/city", "value": "Moscow" },
    { "op": "remove", "path": "/phoneNumber" }
]

Этот запрос:

1. Заменяет значение поля email.
2. Добавляет новое поле city внутри объекта address.
3. Удаляет поле phoneNumber.

---

Применение в QA Automation (REST API-тестировании)

При автоматизации тестирования REST API, тестирование эндпоинтов, поддерживающих PATCH, является важной частью проверки функциональности и надежности приложения.

Ключевые аспекты для тестирования:

1. Позитивные тесты:

    *   Успешное обновление одного поля.
    *   Успешное обновление нескольких полей.
    *   Обновление вложенных полей (если формат поддерживает).
    *   Проверка, что неизменяемые/неупомянутые поля остались прежними.
    *   Проверка кода ответа `200 OK` или `204 No Content` и обновленных данных в последующем GET-запросе.

1. Негативные тесты и тесты на безопасность:

    *   Отправка некорректного формата тела запроса (например, обычный JSON для JSON Patch).
    *   Попытка обновить несуществующее поле (`ignoreUnknownProperties` или ошибка?).
    *   Попытка обновить поле, не предназначенное для изменения (например, `id` или `createdAt`).
    *   Проверка валидации данных (например, неверный формат email в поле `email`).
    *   **Отсутствие идемпотентности:** Отправка одного и того же PATCH-запроса дважды. Приводит ли это к ошибке (например, увеличению счетчика) или состояние ресурса не меняется?
    *   Попытка частичного обновления несуществующего ресурса (должен вернуть `404 Not Found`).
    *   Отправка запроса с недостаточными правами (`403 Forbidden`).

1. Пример автоматизированного теста (Python, pytest + requests):

import pytest
import requests

BASE_URL = "https://api.example.com"
USER_ID = 123

def test_patch_user_email_successfully():
    """Проверка успешного обновления email пользователя через PATCH."""
    headers = {"Content-Type": "application/merge-patch+json"}
    payload = {"email": "updated_{USER_ID}@test.com"}

    response = requests.patch(f"{BASE_URL}/users/{USER_ID}", json=payload, headers=headers)

    # Проверяем статус ответа
    assert response.status_code == 200, f"Ожидался 200 OK, получен {response.status_code}"

    # Проверяем, что поле email изменилось
    user_data = response.json()
    assert user_data["email"] == payload["email"]

    # ПРОВЕРКА НЕИЗМЕННОСТИ ДРУГИХ ПОЛЕЙ (важно!)
    # Для этого можно сделать отдельный GET-запрос и сравнить неизменяемые поля
    get_response = requests.get(f"{BASE_URL}/users/{USER_ID}")
    full_user_data = get_response.json()
    assert full_user_data["id"] == USER_ID
    assert full_user_data["username"] == "previous_username"  # Предполагаемое старое значение

Вывод

PATCH — это мощный и эффективный инструмент для работы с API, который позволяет оптимизировать сетевой трафик и уменьшить вероятность конфликтов при обновлении данных. С точки зрения QA Automation инженера, понимание нюансов этого метода, его отличий от PUT, а также форматов JSON Patch и JSON Merge Patch критически важно для проектирования полного, надежного и эффективного набора автоматизированных тестов для REST API. Особое внимание следует уделять тестированию частичности обновлений, валидации, безопасности и, по возможности, идемпотентности операций.