Что такое метод POST?

Метод POST: назначение и применение в HTTP

POST — это HTTP метод, предназначенный для отправки данных на сервер с целью создания нового ресурса или выполнения операции обработки. В отличие от GET, POST отправляет данные в теле запроса (body), что позволяет передавать большие объёмы информации безопасно.

Основные характеристики POST

1. Отправка данных в теле запроса

# Простой POST запрос
curl -X POST http://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name": "John", "email": "john@example.com"}'

Структура POST запроса:

POST /users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 42

{"name": "John", "email": "john@example.com"}

2. Создание новых ресурсов

Первичное назначение POST — создание нового ресурса на сервере:

# Создание нового пользователя
curl -X POST http://api.example.com/api/v1/users \
  -H "Content-Type: application/json" \
  -d '{"username": "alice", "password": "secure123"}'

# Ответ сервера (обычно 201 Created)
HTTP/1.1 201 Created
Location: /api/v1/users/123
{"id": 123, "username": "alice"}

3. Различные форматы данных

JSON:

curl -X POST http://localhost:8000/api/data \
  -H "Content-Type: application/json" \
  -d '{"key": "value"}'

Form data:

curl -X POST http://example.com/login \
  -d "username=admin&password=pass123"

Multipart (файлы):

curl -X POST http://example.com/upload \
  -F "file=@document.pdf" \
  -F "description=Important PDF"

POST vs GET: ключевые отличия

Коды ответов для POST

• 200 OK — Запрос обработан, но ресурс уже существовал
• 201 Created — Ресурс успешно создан
• 202 Accepted — Запрос принят на обработку (асинхронно)
• 204 No Content — Успешно, но нет содержимого в ответе
• 400 Bad Request — Некорректные данные
• 401 Unauthorized — Требуется аутентификация
• 403 Forbidden — Нет прав доступа
• 409 Conflict — Конфликт (например, дублирование)

Практические примеры в DevOps

1. Вебхуки (Webhooks) для CI/CD

# GitHub отправляет POST при push в репозиторий
# Jenkins слушает на /github-webhook/ и запускает сборку

POST /github-webhook/ HTTP/1.1
Content-Type: application/json
X-GitHub-Event: push

{"ref": "refs/heads/main", "repository": {...}}

2. API для развёртывания приложений

# Запрос на развёртывание нового сервиса
curl -X POST http://api.infra.com/deployments \
  -H "Authorization: Bearer token" \
  -H "Content-Type: application/json" \
  -d '{
    "service": "backend",
    "version": "v1.2.3",
    "environment": "production"
  }'

3. Логирование и метрики

# Отправка метрик на сервер мониторинга
curl -X POST http://prometheus:9090/metrics \
  -H "Content-Type: application/json" \
  -d '{"metric": "http_requests", "value": 1024}'

4. Аутентификация

# Вход в систему (POST отправляет credentials)
curl -X POST http://api.example.com/login \
  -H "Content-Type: application/json" \
  -d '{"username": "admin", "password": "secret"}'

# Ответ с токеном
{"token": "eyJhbGc...", "expires_in": 3600}

Безопасность POST

Уязвимости:

• CSRF (Cross-Site Request Forgery) — надо использовать CSRF token
• Инъекция данных — валидировать и санитизировать вход
• Утечка данных — использовать HTTPS, не отправлять пароли в открытом виде

Защита:

# Flask с CSRF protection
from flask_wtf.csrf import generate_csrf

@app.route('/submit', methods=['POST'])
def submit():
    token = request.form.get('csrf_token')
    if not validate_csrf_token(token):
        return "CSRF validation failed", 403
    # Обработка данных

Идемпотентность и повторы

Пост не идемпотентен — если отправить дважды, может создать два ресурса. Для безопасности:

# Используем идемпотентный ключ
curl -X POST http://api.example.com/payments \
  -H "Idempotency-Key: unique-key-123" \
  -d '{"amount": 100}'

Сервер запомнит ключ и при повторе вернёт тот же результат, не создавая дубль.