Какие знаешь методы в REST?

HTTP методы в REST API

REST (Representational State Transfer) использует стандартные HTTP методы для операций над ресурсами. Знание этих методов — базовый навык для QA инженера, работающего с API тестированием. За свой опыт я работал с множеством REST API'й и знаю все нюансы применения каждого метода.

Основные HTTP методы в REST

1. GET — получение данных (безопасный, идемпотентный)

Назначение: получить данные с сервера без изменения состояния

Характеристики:

• Безопасен — не изменяет состояние
• Идемпотентен — повторные запросы вернут одинаковый результат
• Кэшируется браузером
• Параметры передаются в URL (query string)
• Код ответа: 200 OK (успешно), 404 Not Found (ресурс не найден)

Примеры:

GET /api/v1/users/123
GET /api/v1/orders?status=completed&limit=10
GET /api/v1/products/search?q=iphone

Когда использую в тестах:

• Проверка получения данных
• Проверка фильтрации и поиска
• Проверка пагинации
• Проверка авторизации (401, 403)

2. POST — создание нового ресурса (небезопасный, не идемпотентный)

Назначение: создать новый ресурс на сервере

Характеристики:

• Небезопасен — изменяет состояние (создаёт данные)
• Не идемпотентен — каждый запрос создаёт новый ресурс
• Параметры передаются в body (JSON, form-data)
• Код ответа: 201 Created (создано), 400 Bad Request (ошибка валидации)
• Возвращает: новый ресурс с ID и Location заголовком

Примеры:

POST /api/v1/users
Body: {"name": "Ivan", "email": "ivan@example.com"}
Ответ: 201, {"id": 123, "name": "Ivan", ...}

POST /api/v1/orders
Body: {"items": [...], "payment_method": "card"}
Ответ: 201, {"id": 456, "status": "pending", ...}

Когда использую в тестах:

• Создание новых ресурсов
• Проверка валидации данных
• Проверка проверку дубликатов (уникальность)
• Проверка authorization и permissions

3. PUT — полная замена ресурса (безопасный по стандарту, идемпотентный)

Назначение: полностью заменить существующий ресурс

Характеристики:

• Идемпотентен — повторные запросы дают одинаковый результат
• Требует все поля — нужно передать все атрибуты ресурса
• Параметры в body (JSON)
• Код ответа: 200 OK или 204 No Content
• ID ресурса в URL: /api/v1/users/123

Примеры:

PUT /api/v1/users/123
Body: {"id": 123, "name": "Ivan Petrov", "email": "new@example.com", "age": 30}
Ответ: 200, обновлённый ресурс

Повторение того же запроса → вернёт тот же результат

Когда использую в тестах:

• Полное обновление ресурса
• Проверка идемпотентности (запустить дважды, результат одинаковый)
• Проверка обязательных полей

4. PATCH — частичное обновление ресурса (идемпотентный)

Назначение: частично обновить ресурс (только переданные поля)

Характеристики:

• Идемпотентен — повторные запросы дают одинаковый результат
• Требует только изменяемые поля — можно передать только 1-2 поля
• Параметры в body (JSON)
• Код ответа: 200 OK с обновлённым ресурсом
• ID ресурса в URL: /api/v1/users/123

Примеры:

PATCH /api/v1/users/123
Body: {"email": "new@example.com"}
Ответ: 200, {"id": 123, "name": "Ivan", "email": "new@example.com", ...}

Остальные поля остаются без изменения

Когда использую в тестах:

• Частичное обновление
• Тестирование частичных обновлений
• Проверка, что неизменённые поля не меняются

5. DELETE — удаление ресурса (идемпотентный)

Назначение: удалить ресурс

Характеристики:

• Идемпотентен — повторное удаление уже удалённого ресурса вернёт 404
• ID ресурса в URL: /api/v1/users/123
• Нет body в запросе
• Код ответа: 204 No Content (успешно удалено) или 200 OK
• При повторном запросе: 404 Not Found

Примеры:

DELETE /api/v1/users/123
Ответ: 204 No Content

DELETE /api/v1/users/123 (повторно)
Ответ: 404 Not Found (уже удалён)

Когда использую в тестах:

• Удаление ресурсов
• Проверка cascading delete (удаление связанных данных)
• Проверка soft delete (логическое удаление)
• Проверка permissions для удаления

6. OPTIONS — получение доступных методов (для CORS)

Назначение: получить информацию о доступных методах для ресурса

Характеристики:

• Используется браузером перед CORS запросами
• Безопасен — только информирует
• Код ответа: 200 OK
• Возвращает заголовок Allow с доступными методами

Пример:

OPTIONS /api/v1/users
Ответ: 200
Allow: GET, POST, PUT, DELETE, OPTIONS

7. HEAD — как GET, но без тела ответа

Назначение: проверить существование ресурса и получить метаданные

Характеристики:

• Безопасен и идемпотентен
• Идентичен GET, но не передаёт тело ответа
• Экономит трафик — только заголовки
• Используется для проверки существования файла

Пример:

HEAD /api/v1/users/123
Ответ: 200 (ресурс существует) или 404 (не существует)

Таблица сравнения методов

CRUD соответствие

CRUD операции в REST:

• Create → POST /resources
• Read → GET /resources/{id}
• Update → PUT или PATCH /resources/{id}
• Delete → DELETE /resources/{id}

Пример complete workflow'а:

1. Создание пользователя:
   POST /api/v1/users
   Body: {"name": "Ivan"}
   Ответ: 201, {"id": 123}

2. Получение данных:
   GET /api/v1/users/123
   Ответ: 200, {"id": 123, "name": "Ivan"}

3. Обновление:
   PATCH /api/v1/users/123
   Body: {"email": "ivan@example.com"}
   Ответ: 200, {"id": 123, "name": "Ivan", "email": "..."}

4. Удаление:
   DELETE /api/v1/users/123
   Ответ: 204

Практические советы для QA

1. Тестируй правильные коды ответов: POST → 201, GET → 200, DELETE → 204

2. Проверяй идемпотентность: PUT/PATCH/DELETE должны давать одинаковый результат при повторении

3. Убедись в правильности Location заголовка: POST должен вернуть Location: /api/v1/users/123

4. Тестируй валидацию для POST/PATCH: неправильные данные должны вернуть 400

5. Проверяй permissions: запрос от неавторизованного пользователя должен вернуть 401/403

6. Не путай PUT и PATCH: PUT заменяет весь ресурс, PATCH — только переданные поля

7. Проверяй обработку несуществующих ресурсов: GET/PUT/DELETE к /users/999999 должны вернуть 404

Знание HTTP методов — это фундамент для API тестирования. Каждый метод имеет своё назначение и соответствующие коды ответов, которые нужно проверять в тестах.