Методы HTTP-запроса

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

При получении запроса сервер пытается определить метод запроса, и если ему это не удается, то возвращает ответное сообщение с кодом 501 и фразой Not Implemented. Если же сервер определил метод, но его невозможно применить к запрашиваемому ресурсу, то возвращается ответное сообщение с кодом 405 и фразой Method Not Allowed. Подробнее о кодах состояния HTTP-ответа. Если происходит любой из этих двух вариантов, то серверу при возврате ответа нужно добавить заголовок Allow и перечислить в нем все поддерживаемые сервером методы.

Хотя каких-то обязательных методов нет, для того чтобы не изобретать свой велосипед для каждого сервера, желательно использовать встроенные в спецификации HTTP методы.

OPTIONS

Определяет возможности и используемые методы веб-сервера. В ответном сообщении должен быть добавлен заголовок Allow с перечислением всех поддерживаемых сервером методов.

Пример запроса:

OPTIONS * HTTP/1.1
Host: example.com

Пример ответа:

HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST, PUT, PATCH, DELETE, TRACE

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

GET

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

Пример запроса:

GET /text.txt HTTP/1.1
Host: example.com

Пример ответа:

HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8

Title: Заголовок файла
Text: Текст файла

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

HEAD

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

Пример запроса:

HEAD /text.txt HTTP/1.1
Host: example.com

Пример ответа:

HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8

Заголовки ответного сообщения могут кэшироваться. Если метаданные ресурса не совпадают с информацией в кэше, то копия ресурса должна быть помечена устаревшей.

POST

Создает новый ресурс из переданных данных в запросе.

Пример запроса:

POST /text.txt HTTP/1.1
Host: example.com

Title=Заголовок+файла
Text=Текст+файла

Если был создан ресурс (в данном случае файл text.txt), то нужно вернуть сообщение ответа с кодом состояния 201 Created и заголовком Location, указывающим на этот ресурс.

HTTP/1.1 201 Created
Location: /text.txt

Если же URI не изменился, а были созданы данные, то серверу следует вернуть ответ с кодом состояния 200 OK и информацией с итогом выполнения запроса в теле сообщения.

HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8

Добавлен контент в пустой файл «text.txt»

Часто применяется для отправки данных на сервер из HTML форм заполняемых пользователями на веб-сайтах.

PUT

Изменяет содержимое запроса по-указанному URI.

PUT /text.txt HTTP/1.1
Host: example.com

Title=Новый+заголовок+файла
Text=Новый+текст+файла

Если ресурс был изменён, то возвращается сообщение ответа с кодом состояния 200 OK или 204 No Content.

HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8

Изменен контент в файле «text.txt»

Если ресурс, указанный в URI, не существует, то сервер создаст его и вернет ответ с кодом состояния 201 Created.

HTTP/1.1 201 Created
Content-Type: text/plain; charset=UTF-8

Изменен контент в файле «text.txt»

POST и PUT отличаются предназначением URI ресурсов. Используя PUT, предполагается, что загружаемый контент соответствует ресурсу, находящемуся по-указанному URI. Используя POST, предполагается, что загружаемый контент будет проходить обработку на указанном URI.

PATCH

Похож на PUT, но применяется только к фрагменту ресурса.

Пример запроса:

PATCH /text.txt HTTP/1.1
Host: example.com

Title=Новый+заголовок+файла

Пример ответа:

HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8

Изменен заголовок в файле «text.txt»

Таким образом изменен был только Title, а Text остался прежним.

DELETE

Удаляет конкретный ресурс по-указанному URI.

Пример запроса:

DELETE /text.txt HTTP/1.1
Host: example.com

Пример ответа:

HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8

Файл «text.txt» удален

Если ресурс был удален, то возвращается ответ с кодом состояния 200 OK или 204 No Content.

TRACE

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

Пример запроса:

TRACE / HTTP/1.1
Host: example.com

Пример ответа:

HTTP/1.1 200 OK
Content-Type: message/http

TRACE / HTTP/1.1
Host: example.com

Конечным получателем запроса является исходный сервер, и информация о запросе возвращается от него. Если же нужно вернуть раньше с конкретного прокси-сервера, то нужно установить заголовок Max-Forwards с необходимым значением.

CONNECT

Запускает двустороннюю связь с запрошенным ресурсом. Метод обычно используется для открытия прозрачного TCP/IP-туннеля.

CONNECT server.example.com:80 HTTP/1.1 
Host: server.example.com:80

Часто используется для получения доступа к веб-сайту, который использует SSL (HTTPS). Для создания TCP/IP-туннеля клиентом запрашивается прокси-сервер, который в свою очередь тоже выполняет роль клиента, подключаясь к исходному серверу. После подключения к исходному серверу прокси-сервер проксирует поток TCP к клиенту и обратно.

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

Все вышеперечисленные методы можно разделить на три группы:

• безопасные (GET, HEAD, OPTIONS) — не изменяют данные, их можно выполнять в любой последовательности;
• идемпотентные (GET, HEAD, PUT, DELETE, OPTIONS, TRACE) — при повторном выполнении результаты будут ожидаемо одинаковыми;
• неидемпотентные (POST, PATCH) — при повторном выполнении результаты будут разными, если, например, отправить POST-запрос на создание элемента несколько раз подряд, то он может создать несколько элементов с одинаковыми данными.

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