> В чем разница HTTP методов GET, POST, PUT, DELETE и когда их использовать (Python)

Короткий ответ

GET, POST, PUT и DELETE - это стандартные HTTP-методы, которые описывают намерение клиента при работе с ресурсом. GET - безопасный и идемпотентный, используется для чтения. POST - неидемпотентный, создает новый ресурс или выполняет действие. PUT - идемпотентный, заменяет ресурс целиком. DELETE - идемпотентный, удаляет ресурс. Выбор метода определяется семантикой операции, а не "удобством" или привычкой.

Подробное объяснение

HTTP-методы - это часть спецификации RFC 9110, которая определяет семантику запроса. Ключевые свойства:

• Безопасность (safe): метод не изменяет состояние сервера. GET, HEAD, OPTIONS - безопасны.
• Идемпотентность (idempotent): повторный запрос с теми же параметрами дает тот же результат, что и первый. GET, PUT, DELETE, HEAD - идемпотентны. POST - нет.

GET - запрос на получение представления ресурса. Не должен иметь тела (хотя формально может, но это антипаттерн). Используется для чтения, поиска, фильтрации. Кэшируется, попадает в историю браузера, может быть закладкой.

POST - запрос на создание нового ресурса или выполнение действия, которое не подходит под другие методы. Неидемпотентен: два одинаковых POST создадут два разных ресурса. Используется для форм, загрузки файлов, RPC-подобных операций (например, /api/actions/start).

PUT - полная замена ресурса по известному URI. Идемпотентен: повторный PUT с тем же телом не изменит состояние после первого. Если ресурс не существует - может создать его (в некоторых API). Важно: PUT заменяет ресурс целиком, а не частично.

DELETE - удаление ресурса по URI. Идемпотентен: повторный DELETE вернет 404 или 204, но состояние не изменится. В некоторых реализациях может быть "мягкое удаление" (soft delete), но семантика метода сохраняется.

Дополнительно стоит упомянуть PATCH - частичное обновление, но он не входит в вопрос. Также важно различать PUT и PATCH: PUT - полная замена, PATCH - частичное изменение.

На практике

В реальном backend на Python (FastAPI, Django, Flask) выбор метода диктует структуру роутинга и контракт API. Например:

• GET /users - список пользователей
• POST /users - создание пользователя
• GET /users/{id} - получить одного
• PUT /users/{id} - полностью заменить пользователя
• DELETE /users/{id} - удалить

Типичные ошибки на практике:

• Использование POST для обновления, потому что "так проще" - ломает идемпотентность и семантику.
• PUT с частичным телом - клиент не присылает все поля, сервер обнуляет остальные. Это нарушение контракта PUT.
• GET с телом для сложных фильтров - лучше использовать query parameters или POST, если параметры слишком сложные.
• DELETE с телом - большинство прокси и клиентов не поддерживают тело в DELETE, лучше передавать идентификатор в URI.

Также важно помнить про статус-коды: GET - 200, POST - 201 Created, PUT - 200 или 204, DELETE - 204 или 404.

Пример кода

Пример на FastAPI:

PYTHON
from fastapi import FastAPI, HTTPException, status
from pydantic import BaseModel

app = FastAPI()

class User(BaseModel):
    id: int
    name: str
    email: str

users_db = {}

@app.get("/users/{user_id}", status_code=status.HTTP_200_OK)
def get_user(user_id: int):
    if user_id not in users_db:
        raise HTTPException(status_code=404, detail="User not found")
    return users_db[user_id]

@app.post("/users", status_code=status.HTTP_201_CREATED)
def create_user(user: User):
    if user.id in users_db:
        raise HTTPException(status_code=409, detail="User already exists")
    users_db[user.id] = user
    return user

@app.put("/users/{user_id}", status_code=status.HTTP_200_OK)
def replace_user(user_id: int, user: User):
    if user_id not in users_db:
        raise HTTPException(status_code=404, detail="User not found")
    users_db[user_id] = user
    return user

@app.delete("/users/{user_id}", status_code=status.HTTP_204_NO_CONTENT)
def delete_user(user_id: int):
    if user_id not in users_db:
        raise HTTPException(status_code=404, detail="User not found")
    del users_db[user_id]

Как отвечать на собеседовании

Начните с определения: "HTTP-методы - это глаголы, которые описывают намерение клиента". Затем перечислите четыре метода и их ключевые свойства: безопасность и идемпотентность. Приведите примеры использования для каждого. Обязательно упомяните разницу между PUT и POST, а также между PUT и PATCH. Если спросят про идемпотентность - объясните на примере: повторный POST создаст дубликат, повторный PUT - нет. Хорошо добавить про статус-коды, которые ожидаются для каждого метода. Если интервьюер спросит про кэширование - скажите, что GET кэшируется, а POST/PUT/DELETE - нет по умолчанию.

Что проверяет интервьюер

Интервьюер проверяет:

• Понимание семантики HTTP, а не просто заученных определений.
• Умение различать безопасность и идемпотентность.
• Знание практических следствий: кэширование, повторные запросы, идемпотентность в распределенных системах.
• Понимание разницы между PUT и PATCH, POST и PUT.
• Умение применить это к реальному API-дизайну.

Для senior-уровня важно показать, что вы понимаете, как эти методы влияют на проектирование API, обработку ошибок и поведение клиентов. Также ценится знание edge cases: например, что DELETE может быть неидемпотентным при мягком удалении, но семантически он остается идемпотентным.

Типичные ошибки

• Путаница между PUT и POST: "PUT - это обновление, POST - создание". На самом деле POST может создавать, а PUT - заменять.
• Утверждение, что GET не может иметь тело - формально может, но это плохая практика.
• Игнорирование идемпотентности: "DELETE повторно вернет ошибку, значит он неидемпотентен" - нет, идемпотентность означает, что состояние сервера не меняется, а не что ответ всегда 200.
• Использование POST для всего "чтобы не заморачиваться" - признак плохого API-дизайна.
• Неупоминание PATCH, когда речь идет о частичном обновлении - интервьюер может специально спросить про разницу.