Материал учебного циклаОткрытый материал

HTTP-методы GET, POST, PUT, PATCH, DELETE и QUERY: как работают запросы

Подробно разбираем HTTP-методы GET, POST, PUT, PATCH, DELETE и новый QUERY: назначение, примеры запросов, URL, headers, body, безопасность и идемпотентность.

Команда Студии Ягуара 01 августа 2026 18 мин чтения 156 просмотров

Веб-разработка #API #DELETE #GET #HTTP #HTTP-запросы #HTTP-методы #PATCH #POST #PUT #QUERY #REST API #backend #веб-разработка #программирование

Учебный цикл Основы API и backend-разработки Материал 1 из 8

HTTP-методы GET, POST, PUT, PATCH, DELETE и QUERY

HTTP-метод сообщает серверу, что клиент хочет сделать с ресурсом.

GET получает данные.
POST создаёт ресурс или запускает обработку.
PUT полностью заменяет ресурс.
PATCH изменяет его отдельные поля.
DELETE удаляет ресурс.
QUERY выполняет сложный безопасный запрос с телом.

В этой статье разберём, как работают HTTP-методы, из чего состоит HTTP-запрос, чем PUT отличается от PATCH, зачем появился новый метод QUERY и какой метод выбирать в разных ситуациях.

Главная мысль: HTTP-метод описывает намерение клиента, но не определяет внутреннюю реализацию сервера.

Краткое сравнение HTTP-методов

Метод	Для чего используется	Пример
`GET`	Получить данные	`GET /products/42`
`POST`	Создать ресурс или запустить операцию	`POST /products`
`PUT`	Полностью заменить ресурс	`PUT /products/42`
`PATCH`	Частично изменить ресурс	`PATCH /products/42`
`DELETE`	Удалить ресурс	`DELETE /products/42`
`QUERY`	Выполнить сложный запрос чтения с телом	`QUERY /products`
`HEAD`	Получить заголовки без тела ответа	`HEAD /files/manual.pdf`
`OPTIONS`	Узнать доступные возможности	`OPTIONS /products`

Что такое HTTP

HTTP - Hypertext Transfer Protocol - это протокол взаимодействия клиента и сервера.

Обмен обычно состоит из двух сообщений:

HTTP Request  - запрос клиента
HTTP Response - ответ сервера

Клиент формирует запрос и сообщает серверу своё намерение. Сервер принимает запрос, интерпретирует его относительно выбранного ресурса и возвращает ответ. HTTP определяет общую семантику сообщений, методов, заголовков, статус-кодов и представлений ресурсов.

HTTP сам по себе не знает, что такое товар, пользователь, заказ или платёж. Для него это ресурсы, с которыми клиент взаимодействует через стандартизированные сообщения.

Клиент

Клиент - программа, отправляющая HTTP-запрос.

Клиентом может быть:

браузер;
мобильное приложение;
Telegram-бот;
Python-скрипт;
JavaScript-код на странице;
Postman;
другой сервер.

Например, приложение может запросить товар:

GET /products/42

Сервер

Сервер - программа, которая принимает запросы, выполняет необходимую логику и возвращает ответы.

Сервер не обязательно является отдельным физическим компьютером. В разработке этим словом часто называют запущенную программу, которая слушает сетевой порт и обрабатывает входящие соединения.

При получении запроса сервер может:

определить метод и путь;
проверить параметры;
прочитать тело;
установить пользователя;
проверить его права;
обратиться к базе данных;
выполнить бизнес-логику;
сформировать ответ.

Упрощённая схема:

Клиент
   ↓
HTTP-запрос
   ↓
Сервер
   ↓
Программная логика и база данных
   ↓
HTTP-ответ
   ↓
Клиент

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

HTTP-метод - часть запроса, описывающая намерение клиента.

Например:

GET /products/42

означает:

Получить представление товара с идентификатором 42.

А запрос:

DELETE /products/42

означает:

Удалить товар с идентификатором 42.

При этом метод не выполняет операцию автоматически. Серверный разработчик сам определяет, какой код будет вызван.

Например, во фреймворке FastAPI это может выглядеть так:

@app.get("/products/{product_id}")
def get_product(product_id: int):
    ...

HTTP лишь устанавливает стандартный смысл методов. Реальная логика находится внутри приложения.

Один путь может поддерживать несколько методов:

GET /products
POST /products
QUERY /products

Это три разные операции, несмотря на одинаковый путь.

Поэтому конкретную серверную операцию обычно определяет сочетание:

HTTP-метод + путь

GET - получение данных

Метод GET используется для получения представления ресурса.

GET /products/42

Сервер может вернуть:

{
  "id": 42,
  "name": "Механическая клавиатура",
  "price": 7500
}

Клиент получает не физический товар и не обязательно строку из базы данных. Он получает представление ресурса - данные, описывающие его текущее состояние.

HTTP специально отделяет ресурс от его представления: один и тот же ресурс может быть представлен в JSON, HTML, XML, изображении или другом формате.

С помощью GET можно получить:

одного пользователя;
список товаров;
историю заказов;
содержимое статьи;
изображение;
данные о погоде;
результаты поиска.

Примеры:

GET /users/15

GET /products

GET /users/15/orders

GET не должен изменять ресурс

GET предназначен для чтения.

Такой запрос не должен удалять товар, списывать деньги или изменять состояние заказа:

GET /products/42

Поэтому следующий вариант спроектирован неправильно:

GET /products/42/delete

Несмотря на слово delete в адресе, клиент всё ещё отправляет GET.

Для удаления нужно использовать:

DELETE /products/42

Это важно не только с точки зрения аккуратного дизайна. Браузеры, поисковые роботы, прокси и кеши могут автоматически повторять или предварительно загружать безопасные запросы.

GET и query-параметры

Для фильтрации, поиска, сортировки и пагинации часто используются query-параметры.

GET /products?category=laptops&limit=20

Здесь:

/products

путь к ресурсу.

А:

category=laptops
limit=20

query-параметры.

Несколько параметров разделяются символом &:

GET /products?category=laptops&limit=20&sort=price

Они могут использоваться для:

фильтрации;
полнотекстового поиска;
сортировки;
ограничения количества результатов;
смещения;
пагинации;
выбора дополнительных полей.

Например:

GET /products?category=laptops&limit=20&offset=40&sort=price

может означать:

category=laptops → выбрать ноутбуки;
limit=20         → вернуть не больше 20 объектов;
offset=40        → пропустить первые 40;
sort=price       → отсортировать по цене.

Важно не путать два понятия:

query-параметры → часть URL;
QUERY           → отдельный HTTP-метод.

POST - создание ресурса или запуск операции

Метод POST передаёт серверу данные на обработку.

Чаще всего он используется для создания нового ресурса. Данные нового объекта обычно помещаются в тело запроса - отдельную часть HTTP-сообщения после заголовков. В примере ниже тело записано в формате JSON, а заголовок Content-Type сообщает серверу об этом формате. Структуру запроса, заголовки и тело подробно разберём ниже.

POST /products
Content-Type: application/json

{
  "name": "Монитор",
  "price": 35000
}

Здесь POST /products указывает операцию и ресурс, Content-Type описывает формат тела, а объект в фигурных скобках содержит данные нового товара.

Сервер может создать товар и вернуть:

{
  "id": 108,
  "name": "Монитор",
  "price": 35000
}

Идентификатор 108 сформирован сервером.

POST используется не только для создания

Смысл POST шире, чем «добавить строку в базу данных».

Он может запускать любую предусмотренную сервером обработку:

POST /auth/login

POST /reports/generate

POST /orders/42/pay

POST /files/upload

Через POST можно:

создать пользователя;
создать товар;
оформить заказ;
отправить форму;
загрузить файл;
запустить генерацию отчёта;
начать платёж;
отправить сообщение;
передать команду;
выполнить сложный поиск, если сервер не поддерживает QUERY.

Почему POST нельзя бездумно повторять

Рассмотрим создание заказа:

POST /orders
Content-Type: application/json

{
  "product_id": 42,
  "quantity": 1
}

Первый запрос может создать заказ №1001.

Повторный такой же запрос может создать заказ №1002.

Поэтому одинаковый POST-запрос нельзя бездумно повторять: повтор может создать ещё одну операцию. Формальное свойство, связанное с таким поведением, разберём ниже в разделе об идемпотентности.

Особенно это важно для:

платежей;
бронирований;
создания заказов;
отправки сообщений;
регистрации пользователей.

В платёжных и других критических системах сервер дополнительно защищается от повторной обработки одного запроса. Конкретные механизмы такой защиты относятся уже к проектированию API.

PUT - полная замена ресурса

Метод PUT обычно используется для передачи полного нового состояния ресурса.

Пусть товар выглядит так:

{
  "id": 42,
  "name": "Клавиатура",
  "price": 5000,
  "description": "Проводная клавиатура",
  "available": true
}

Клиент отправляет:

PUT /products/42
Content-Type: application/json

{
  "name": "Игровая клавиатура",
  "price": 7500,
  "description": "Механическая клавиатура",
  "available": true
}

Смысл:

Сделай текущее представление товара №42 соответствующим переданному состоянию.

После обработки:

{
  "id": 42,
  "name": "Игровая клавиатура",
  "price": 7500,
  "description": "Механическая клавиатура",
  "available": true
}

Что будет с отсутствующими полями

Предположим, клиент отправил:

PUT /products/42
Content-Type: application/json

{
  "name": "Игровая клавиатура",
  "price": 7500
}

В зависимости от контракта API отсутствующие поля могут:

удалиться;
получить null;
получить значение по умолчанию;
вызвать ошибку валидации.

Поэтому PUT лучше воспринимать как передачу полного желаемого состояния.

PUT → полная замена представления ресурса.

Может ли PUT создавать ресурс

Иногда PUT может создать ресурс, если клиент заранее знает его точный адрес.

PUT /user-settings/42

Если настройки пользователя 42 ещё не существуют, сервер может создать их по указанному URI.

При POST точный адрес нового ресурса обычно определяет сервер:

POST /products

Результатом может стать:

/products/108

PATCH - частичное изменение ресурса

Метод PATCH используется для частичного обновления.

Пусть товар хранится так:

{
  "id": 42,
  "name": "Клавиатура",
  "price": 5000,
  "description": "Проводная клавиатура",
  "available": true
}

Нужно изменить только цену:

PATCH /products/42
Content-Type: application/json

{
  "price": 6500
}

После обработки:

{
  "id": 42,
  "name": "Клавиатура",
  "price": 6500,
  "description": "Проводная клавиатура",
  "available": true
}

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

Форматы PATCH

Во многих API клиент отправляет обычный JSON-объект:

{
  "price": 6500,
  "available": false
}

Но тело также может содержать формальный набор операций:

[
  {
    "op": "replace",
    "path": "/price",
    "value": 6500
  }
]

Такой формат называется JSON Patch - стандартным способом описать последовательность точечных операций над JSON-документом.

Конкретный формат всегда должен быть описан в документации API.

DELETE - удаление ресурса

Метод DELETE используется для удаления ресурса.

DELETE /products/42

Смысл:

Удали ресурс, доступный по адресу /products/42.

После успешного удаления запрос:

GET /products/42

обычно вернёт:

404 Not Found

404 Not Found означает, что сервер не нашёл ресурс по указанному адресу. Статус-коды HTTP подробно разбираются в отдельном материале.

Удаление не всегда физическое

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

Физическое удаление

Строка полностью удаляется из базы данных.

Мягкое удаление

Строка сохраняется, но получает признак:

deleted = true

или дату:

deleted_at = "2026-08-01T12:00:00"

Мягкое удаление позволяет:

восстановить объект;
сохранить историю;
проводить аудит;
не разрушать связи между данными.

Для обычного клиента ресурс всё равно перестаёт быть доступен.

QUERY - сложный безопасный запрос с телом

QUERY - новый HTTP-метод для серверных запросов, которым требуется содержательное тело, но которые при этом должны оставаться безопасными и идемпотентными.

Он был опубликован как RFC 10008 в июне 2026 года. Стандарт определяет QUERY как метод, при котором целевой ресурс обрабатывает переданное содержимое безопасным и идемпотентным образом и возвращает результат.

Пример:

QUERY /products
Content-Type: application/json

{
  "category": "laptops",
  "price": {
    "from": 50000,
    "to": 150000
  },
  "manufacturers": [
    "Lenovo",
    "ASUS"
  ],
  "sort": {
    "field": "price",
    "direction": "asc"
  }
}

Смысл:

Выполни сложный запрос по товарам, используя описание из тела, но не изменяй сами товары.

Зачем понадобился QUERY

Для простого поиска достаточно GET:

GET /products?category=laptops&limit=20

Но сложные условия неудобно описывать в URL.

Например, требуется:

выбрать ноутбуки Lenovo или ASUS;
ограничить цену диапазоном;
выбрать модели с определённым объёмом памяти;
применить несколько уровней сортировки;
передать вложенные логические условия.

URL быстро становится длинным и трудно читаемым:

GET /products?category=laptops&manufacturer=Lenovo&manufacturer=ASUS&price_from=50000&price_to=150000&ram_gte=16&sort=rating,-price

Раньше для подобных задач часто использовали:

POST /products/search
Content-Type: application/json

Но по методу POST невозможно сразу понять, является ли операция безопасным поиском или изменяет состояние.

QUERY закрывает промежуток между GET и POST:

GET   → безопасное чтение, параметры обычно находятся в URL;
POST  → передача данных на потенциально изменяющую обработку;
QUERY → безопасный сложный запрос, описание которого находится в теле.

RFC 10008 прямо указывает, что QUERY предназначен для ситуаций, в которых входные данные запроса передаются в содержимом сообщения, а не только в query-компоненте URI.

QUERY и query-параметры

Это разные понятия.

Query-параметры являются частью URL:

GET /products?limit=20&offset=40

Метод QUERY находится в начале запроса:

QUERY /products

То есть:

query-параметры → часть адреса;
QUERY           → семантика HTTP-запроса.

Они могут использоваться одновременно:

QUERY /products?language=ru
Content-Type: application/json

{
  "filters": {
    "price": {
      "gte": 50000
    }
  }
}

Query-компонент URI по-прежнему участвует в определении целевого ресурса, а содержимое запроса описывает саму операцию поиска.

Content-Type в QUERY

Поскольку запрос определяется телом и его форматом, серверу необходимо знать тип содержимого:

Content-Type: application/json

Стандарт требует отклонять QUERY, если Content-Type отсутствует или не соответствует переданному содержимому.

Поддержка QUERY

Стандарт появился недавно, поэтому поддержка может различаться в:

браузерах;
HTTP-библиотеках;
веб-фреймворках;
прокси-серверах;
CDN;
API-шлюзах.

Поэтому во многих существующих API пока продолжает использоваться:

POST /products/search

вместо:

QUERY /products

Дополнительные HTTP-методы

HEAD

HEAD похож на GET, но сервер не возвращает тело ответа.

HEAD /files/manual.pdf

Ответ может содержать:

HTTP/1.1 200 OK
Content-Type: application/pdf
Content-Length: 5242880
Last-Modified: Sat, 01 Aug 2026 12:00:00 GMT

Метод позволяет узнать:

существует ли ресурс;
его размер;
тип содержимого;
дату последнего изменения;
параметры кеширования.

OPTIONS

OPTIONS позволяет узнать доступные варианты взаимодействия с сервером или конкретным ресурсом.

OPTIONS /products

Ответ:

HTTP/1.1 204 No Content
Allow: GET, POST, QUERY, OPTIONS

Метод также используется браузерами при CORS-проверке - предварительном запросе, с помощью которого браузер уточняет, разрешает ли сервер обращение с другого сайта.

CONNECT

CONNECT создаёт сетевой туннель до указанного сервера:

CONNECT example.com:443 HTTP/1.1

Обычно он применяется при работе через прокси и редко используется непосредственно в обычном веб-API.

TRACE

TRACE просит сервер вернуть полученный запрос обратно клиенту.

Метод предназначен для диагностики прохождения запроса через промежуточные узлы, но на практике используется редко и часто отключается.

Безопасность, идемпотентность и кешируемость

HTTP-методы отличаются не только назначением, но и дополнительными свойствами.

Безопасный метод

Безопасный метод не должен изменять основное состояние целевого ресурса.

К безопасным относятся:

GET
HEAD
OPTIONS
TRACE
QUERY

GET только запрашивает представление ресурса.

QUERY выполняет операцию поиска, но не должен изменять целевой ресурс.

Безопасность не означает, что сервер вообще ничего не делает. Он всё равно может:

записать запрос в лог;
собрать статистику;
обновить кеш;
сохранить техническую метрику.

Важно, что клиент не запрашивает изменение бизнес-состояния.

К небезопасным относятся:

POST
PUT
PATCH
DELETE

Они могут создавать, заменять, изменять или удалять данные.

Идемпотентный метод

Метод идемпотентен, если несколько одинаковых запросов приводят к тому же ожидаемому итоговому состоянию, что и один запрос.

Например:

PUT /users/42
Content-Type: application/json

{
  "active": false
}

После первого и десятого одинакового запроса:

active = false

Обычно идемпотентны:

GET
HEAD
PUT
DELETE
OPTIONS
TRACE
QUERY

Семантика безопасности и идемпотентности основных методов установлена HTTP Semantics, а безопасный и идемпотентный характер QUERY - RFC 10008.

Почему POST обычно неидемпотентен

POST /orders

каждый раз может создавать новый заказ.

Почему PATCH не всегда идемпотентен

Этот запрос идемпотентен:

PATCH /products/42

{
  "price": 7000
}

Повторение снова устанавливает цену 7000.

А этот запрос может быть неидемпотентным:

PATCH /accounts/42

{
  "operation": "increase",
  "balance": 100
}

Каждый повтор увеличивает баланс ещё на 100.

Почему DELETE идемпотентен

Первый запрос:

DELETE /products/42

удаляет ресурс.

Второй может вернуть 404, но итоговое состояние остаётся тем же:

Товара №42 нет.

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

Кешируемость

Кеширование - сохранение ответа для повторного использования.

Например:

GET /products/42

Ответ может быть сохранён браузером, CDN или промежуточным прокси.

Чаще всего кешируются ответы на:

GET
HEAD

На кеширование также влияют заголовки ответа:

Cache-Control: max-age=3600

ETag: "product-42-v5"

Last-Modified: Sat, 01 Aug 2026 12:00:00 GMT

Сводная таблица свойств

Метод	Обычно имеет тело	Безопасный	Идемпотентный
`GET`	Нет	Да	Да
`POST`	Да	Нет	Обычно нет
`PUT`	Да	Нет	Да
`PATCH`	Да	Нет	Не гарантируется
`DELETE`	Обычно нет	Нет	Да
`QUERY`	Да	Да	Да
`HEAD`	Нет	Да	Да
`OPTIONS`	Обычно нет	Да	Да
`CONNECT`	Особая структура	Нет	Нет
`TRACE`	Обычно нет	Да	Да

Из чего состоит HTTP-запрос

На уровне HTTP/1.1 запрос можно представить как структурированный текст из четырёх частей:

1. Start Line - стартовая строка;
2. Headers - заголовки;
3. пустая строка;
4. Body - тело запроса.

Пример:

POST /products?notify=true HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json
Authorization: Bearer abc123

{
  "name": "Монитор",
  "price": 35000
}

HTTP/2 и HTTP/3 используют другой формат передачи сообщений, однако общая семантика сохраняется: метод, целевой ресурс, поля заголовков и содержимое. Все основные версии HTTP опираются на общие семантические правила.

Start Line - стартовая строка

POST /products?notify=true HTTP/1.1

Стартовая строка собирает уже знакомые элементы в фиксированном порядке:

POST                  - метод;
/products?notify=true - цель запроса;
HTTP/1.1              - версия протокола.

В обычном запросе к серверу в стартовой строке передаётся путь, а имя сервера указывается в заголовке Host:

GET /products?limit=20 HTTP/1.1
Host: api.example.com

При работе через HTTP-прокси может использоваться абсолютная форма, в которой в стартовой строке указывается полный URI:

GET https://api.example.com/products?limit=20 HTTP/1.1
Host: api.example.com

Полная запись не отменяет заголовок Host в HTTP/1.1. Она нужна прежде всего прокси-серверу, чтобы сразу определить адрес назначения.

Существуют и специальные формы цели запроса: host:port для CONNECT и * для запроса OPTIONS ко всему серверу. Здесь достаточно знать об их существовании, поскольку в обычных API чаще используется путь.

Из чего состоит URL

Рассмотрим адрес:

https://api.example.com:443/products/42?include=reviews#description

Он содержит:

https            - схема;
api.example.com  - хост;
443              - порт;
/products/42     - путь;
include=reviews  - query-компонент;
description      - fragment.

Схема

https

Определяет способ доступа.

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

http
https

HTTPS - это HTTP через защищённое TLS-соединение.

Хост

api.example.com

Указывает целевой сервер.

Порт

Определяет сетевой порт.

Стандартные значения:

HTTP  → 80
HTTPS → 443

Стандартный порт обычно не указывается явно.

Путь

/products/42

Указывает на целевой ресурс.

Например:

/products     → коллекция товаров;
/products/42  → конкретный товар.

HTTP не знает, что слово products означает товары. Смысл адреса определяет серверное приложение.

Query-компонент

Начинается после ?:

?category=laptops&limit=20

Обычно состоит из пар:

ключ=значение

Несколько параметров разделяются &.

Fragment

Начинается после #:

#description

Фрагмент обычно используется самим клиентом, например браузером, и не отправляется HTTP-серверу.

Headers - заголовки

Заголовки передают служебную информацию о клиенте, запросе и теле сообщения.

Host: api.example.com
User-Agent: Mozilla/5.0
Accept: application/json
Accept-Language: ru-RU
Content-Type: application/json
Authorization: Bearer abc123

Каждый заголовок состоит из имени и значения:

Имя: значение

Host

Host: api.example.com

Указывает целевой хост.

Один физический сервер может обслуживать несколько доменов, поэтому значение помогает выбрать нужное приложение.

User-Agent

User-Agent: Mozilla/5.0

Передаёт информацию о клиентской программе.

Например:

User-Agent: python-httpx/0.28

или:

User-Agent: MyMobileApp/2.1

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

Accept

Accept: application/json

Сообщает, какой формат ответа клиент предпочитает.

Другие примеры:

Accept: text/html

Accept: image/png

Accept-Language

Accept-Language: ru-RU

Сообщает предпочтительный язык ответа.

Accept-Language: ru-RU,ru;q=0.9,en;q=0.8

Здесь русский язык имеет более высокий приоритет, чем английский.

Content-Type

Content-Type: application/json

Описывает формат тела запроса.

Примеры:

Content-Type: application/json

Content-Type: text/plain

Content-Type: application/x-www-form-urlencoded

Content-Type: multipart/form-data

Важно различать:

Content-Type → формат отправляемого тела;
Accept       → желаемый формат ответа.

Authorization

Authorization: Bearer abc123

Передаёт данные аутентификации.

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

Cookie: session_id=abc123; theme=dark

Передаёт ранее сохранённые cookie.

Они могут содержать:

идентификатор сессии;
язык;
настройки;
служебные параметры.

Content-Length

Content-Length: 57

Указывает размер тела сообщения в байтах.

Обычно HTTP-клиент рассчитывает его автоматически.

Body - тело запроса

Тело содержит данные, которые клиент передаёт серверу.

Оно чаще всего используется с:

POST
PUT
PATCH
QUERY

JSON

POST /products
Content-Type: application/json

{
  "name": "Монитор",
  "price": 35000
}

Обычный текст

POST /messages
Content-Type: text/plain

Привет, сервер

HTML-форма

POST /login
Content-Type: application/x-www-form-urlencoded

email=user@example.com&password=secret

Файл

Для загрузки файлов часто используется:

Content-Type: multipart/form-data

Так можно передавать:

изображения;
PDF;
документы;
архивы;
аудио;
видео.

Можно ли передавать body в GET

Некоторые библиотеки технически позволяют добавить тело к GET, но его общая семантика не определена.

Промежуточные системы могут:

проигнорировать тело;
отклонить запрос;
обработать его нестандартным образом.

Для сложного безопасного чтения с содержательным телом предназначен QUERY.

Статус-коды

Статус-коды делятся на пять групп:

1xx - сервер получил запрос и продолжает обработку;
2xx - запрос успешно выполнен;
3xx - для получения результата требуется дополнительное действие;
4xx - проблема связана с запросом или правами клиента;
5xx - сервер не смог выполнить корректный запрос.

Краткая таблица основных ошибок

Код	Значение	Что произошло
`400`	Bad Request	Запрос составлен некорректно
`401`	Unauthorized	Не удалось подтвердить пользователя
`403`	Forbidden	Недостаточно прав
`404`	Not Found	Ресурс не найден
`405`	Method Not Allowed	Метод недоступен для пути
`409`	Conflict	Конфликт с текущим состоянием
`413`	Content Too Large	Тело слишком большое
`415`	Unsupported Media Type	Формат тела не поддерживается
`422`	Unprocessable Content	Значения не прошли проверку
`429`	Too Many Requests	Превышен лимит запросов
`500`	Internal Server Error	Непредвиденная ошибка сервера
`501`	Not Implemented	Возможность не реализована
`502`	Bad Gateway	Шлюз получил неправильный ответ
`503`	Service Unavailable	Сервис временно недоступен
`504`	Gateway Timeout	Шлюз не дождался ответа

Практический алгоритм выбора метода

Задай себе несколько вопросов.

1. Операция только получает данные?

Для простого чтения:

GET /products

Для сложного поиска с телом:

QUERY /products

2. Создаётся новый объект или запускается действие?

POST /products

или:

POST /reports/generate

3. Изменяется существующий объект?

Полностью:

PUT /products/42

Частично:

PATCH /products/42

4. Ресурс удаляется?

DELETE /products/42

Частые вопросы

Какой метод использовать для создания объекта

Обычно:

POST /products

Если клиент заранее знает точный адрес создаваемого ресурса, в некоторых API применяется PUT.

Какой метод использовать для поиска

Для простых условий:

GET /products?category=laptops

Для сложного безопасного поиска с телом:

QUERY /products

при условии, что метод поддерживается сервером и инфраструктурой.

Является ли DELETE безопасным

Нет. Он изменяет состояние ресурса.

При этом DELETE считается идемпотентным, поскольку повторное удаление не создаёт нового итогового состояния.

Является ли PATCH идемпотентным

Не обязательно.

Запрос, устанавливающий конкретное значение, может быть идемпотентным. Запрос, увеличивающий значение при каждом выполнении, - нет.

Итог

HTTP-запрос содержит четыре основных логических элемента:

HTTP-запрос
│
├── метод
│   ├── GET
│   ├── POST
│   ├── PUT
│   ├── PATCH
│   ├── DELETE
│   └── QUERY
│
├── URL
│   ├── схема
│   ├── хост
│   ├── порт
│   ├── путь
│   └── query-параметры
│
├── заголовки
│   ├── Host
│   ├── User-Agent
│   ├── Accept
│   ├── Content-Type
│   ├── Authorization
│   └── Cookie
│
└── тело
    ├── JSON
    ├── текст
    ├── форма
    └── файл

Главные правила:

HTTP-метод сообщает, что клиент хочет сделать.

URL указывает, с каким ресурсом нужно работать.

Заголовки передают служебную информацию.

Тело содержит данные запроса.

GET, POST, PUT, PATCH, DELETE и QUERY не являются просто разными способами вызвать серверную функцию. Каждый метод передаёт определённое намерение и обладает собственной семантикой.

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

Продолжить

Обратная связь

Материал был полезен?

Нашли ошибку или неточность? Сообщить →

HTTP-методы GET, POST, PUT, PATCH, DELETE и QUERY

Краткое сравнение HTTP-методов

Что такое HTTP

Клиент

Сервер

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

GET - получение данных

GET не должен изменять ресурс

GET и query-параметры

POST - создание ресурса или запуск операции

POST используется не только для создания

Почему POST нельзя бездумно повторять

PUT - полная замена ресурса

Что будет с отсутствующими полями

Может ли PUT создавать ресурс

PATCH - частичное изменение ресурса

Форматы PATCH

DELETE - удаление ресурса

Удаление не всегда физическое

Физическое удаление

Мягкое удаление

QUERY - сложный безопасный запрос с телом

Зачем понадобился QUERY

QUERY и query-параметры

Content-Type в QUERY

Поддержка QUERY

Дополнительные HTTP-методы

HEAD

OPTIONS

CONNECT

TRACE

Безопасность, идемпотентность и кешируемость

Безопасный метод

Идемпотентный метод

Почему POST обычно неидемпотентен

Почему PATCH не всегда идемпотентен

Почему DELETE идемпотентен

Кешируемость

Сводная таблица свойств

Из чего состоит HTTP-запрос

Start Line - стартовая строка

Из чего состоит URL

Схема

Хост

Порт

Путь

Query-компонент

Fragment

Headers - заголовки

Host

User-Agent

Accept

Accept-Language

Content-Type

Authorization

Cookie

Content-Length

Body - тело запроса

JSON

Обычный текст

HTML-форма

Файл

Можно ли передавать body в GET

Статус-коды

Краткая таблица основных ошибок

Практический алгоритм выбора метода

1. Операция только получает данные?

2. Создаётся новый объект или запускается действие?

3. Изменяется существующий объект?

4. Ресурс удаляется?

Частые вопросы

Какой метод использовать для создания объекта

Какой метод использовать для поиска

Является ли DELETE безопасным

Является ли PATCH идемпотентным

Итог

Связанные материалы

Материал был полезен?

Поделиться материалом