HTTP-методы
HTTP-метод (глагол) стоит первым в request-line: GET /users HTTP/1.1. Он говорит серверу что клиент хочет сделать с ресурсом. Определён в RFC 9110.
Основные девять
| Метод | Идемпотент | Safe | Тело в запросе | Тело в ответе | Кэшируется |
|---|---|---|---|---|---|
| GET | да | да | нет | да | да |
| HEAD | да | да | нет | нет (только headers) | да |
| POST | нет | нет | да | да | редко |
| PUT | да | нет | да | да | нет |
| PATCH | нет (обычно) | нет | да | да | нет |
| DELETE | да | нет | иногда | иногда | нет |
| OPTIONS | да | да | редко | да | нет |
| CONNECT | — | нет | да | да | нет |
| TRACE | да | да | нет | да | нет |
Пояснения
- Safe — не меняет состояние сервера. GET, HEAD, OPTIONS.
- Идемпотентный — повторный вызов даёт тот же эффект. Можно спокойно повторять. GET/PUT/DELETE — да. POST/PATCH — нет.
- Кэшируется — можно ли хранить ответ в кэше.
GET
Получение ресурса. Не должно иметь тела запроса (можно, но не гарантируется что доставится). Параметры — в query-string: /search?q=foo.
GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
POST
Создание ресурса или произвольное действие. Не идемпотентен — повторный POST создаст ещё одну запись/отправит форму второй раз. Отсюда «Вы уверены что хотите повторить отправку формы?» в браузерах.
PUT vs POST vs PATCH
- POST /users — «создай нового юзера» (URL коллекции, тело описывает объект).
- PUT /users/42 — «замени юзера 42 целиком» (или создай если нет). Идемпотент.
- PATCH /users/42 — «частично обнови юзера 42» (диффом, например JSON Patch RFC 6902 или JSON Merge Patch RFC 7396).
DELETE
Удаляет ресурс. Идемпотент: второй DELETE → 404, но эффект тот же (нет объекта).
HEAD
Как GET, но сервер возвращает только заголовки. Используется чтобы узнать размер файла, дату, ETag без скачивания. Все download-менеджеры делают HEAD перед скачиванием.
OPTIONS
Два применения:
- Discovery. «Какие методы разрешены для этого URL?» — сервер возвращает
Allow: GET, POST. - CORS preflight. Браузер шлёт OPTIONS перед «сложным» кросс-доменным запросом, сервер отвечает какие origins/headers/methods разрешает.
CONNECT
Просит прокси-сервер открыть TCP-туннель к целевому серверу и стать «прозрачным». Стандартный способ прокачки HTTPS через HTTP-прокси:
CONNECT example.com:443 HTTP/1.1
Host: example.com
→ HTTP/1.1 200 OK
… далее чистый TLS-трафик через туннель …
Именно CONNECT позволяет прокси-серверу пропускать HTTPS без расшифровки. Также используется XHTTP и другими VPN-транспортами.
TRACE
Отражает запрос обратно клиенту — увидеть что промежуточные прокси сделали. Отключено везде из-за XST (Cross-Site Tracing) атаки — TRACE возвращал бы cookies/headers, которые JS не может прочитать.
Custom-методы (SEARCH, MKCOL, PROPFIND, LOCK)
WebDAV (RFC 4918) добавил кучу собственных методов для управления файлами. Экзотика, но живёт в NextCloud, iCloud, Microsoft SharePoint.
- PROPFIND — свойства ресурса.
- MKCOL — создать директорию.
- MOVE, COPY.
- LOCK, UNLOCK.
Тонкости
- Метод — чувствителен к регистру:
GET, неget. - Некоторые прокси/CDN режут всё кроме GET/POST. RESTful API с PUT/DELETE может не работать через них — тогда tunneled метод:
X-HTTP-Method-Override. - В форме HTML только GET и POST. PUT/DELETE в браузере — только через JS (fetch, XHR).