request_methods :::::::::::::::::::::::::::::::::::::::::::::::::::

# HTTP определяет набор методов запроса для указания желаемого 
# действия для данного ресурса. Хотя они также могут быть 
# существительными, эти методы запроса иногда называются 
# HTTP-глаголами. Каждый из них реализует другую семантику, но 
# некоторые общие функции разделяются группой из них: например. 
# метод запроса может быть безопасным, идемпотентным или кэшируемым.

# ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

OPTIONS
# Используется для определения возможностей веб-сервера или 
# параметров соединения для конкретного ресурса. В ответ серверу 
# следует включить заголовок Allow со списком поддерживаемых 
# методов. Также в заголовке ответа может включаться информация 
# о поддерживаемых расширениях.
# Предполагается, что запрос клиента может содержать тело сообщения 
# для указания интересующих его сведений. Формат тела и порядок 
# работы с ним в настоящий момент не определён; сервер пока должен 
# его игнорировать. Аналогичная ситуация и с телом в ответе сервера.
# Для того, чтобы узнать возможности всего сервера, клиент должен 
# указать в URI звёздочку — «*». Запросы «OPTIONS * HTTP/1.1» могут 
# также применяться для проверки работоспособности сервера 
# (аналогично «пингованию») и тестирования на предмет поддержки 
# сервером протокола HTTP версии 1.1.
# Результат выполнения этого метода не кэшируется.

GET
# Используется для запроса содержимого указанного ресурса. С 
# помощью метода GET можно также начать какой-либо процесс. В этом 
# случае в тело ответного сообщения следует включить информацию о 
# ходе выполнения процесса.
# Клиент может передавать параметры выполнения запроса в URI целевого 
# ресурса после символа «?»:
	# GET /path/resource?param1=value1&param2=value2 HTTP/1.1
# Согласно стандарту HTTP, запросы типа GET считаются идемпотентными

HEAD
# Аналогичен методу GET, за исключением того, что в ответе сервера 
# отсутствует тело. Запрос HEAD обычно применяется для извлечения 
# метаданных, проверки наличия ресурса (валидация URL) и чтобы узнать, 
# не изменился ли он с момента последнего обращения.
# Заголовки ответа могут кэшироваться. При несовпадении метаданных 
# ресурса с соответствующей информацией в кэше — копия ресурса 
# помечается как устаревшая.

POST
# Применяется для передачи пользовательских данных заданному ресурсу. 
# Например, в блогах посетители обычно могут вводить свои комментарии 
# к записям в HTML-форму, после чего они передаются серверу методом 
# POST и он помещает их на страницу. При этом передаваемые данные 
# (в примере с блогами — текст комментария) включаются в тело запроса. 
# Аналогично с помощью метода POST обычно загружаются файлы на сервер.
# В отличие от метода GET, метод POST не считается идемпотентным, то 
# есть многократное повторение одних и тех же запросов POST может 
# возвращать разные результаты (например, после каждой отправки 
# комментария будет появляться очередная копия этого комментария).
# При результате выполнения 200 (Ok) в тело ответа следует включить 
# сообщение об итоге выполнения запроса. Если был создан ресурс, то 
# серверу следует вернуть ответ 201 (Created) с указанием URI нового 
# ресурса в заголовке Location.
# Сообщение ответа сервера на выполнение метода POST не кэшируется.

PUT
# Применяется для загрузки содержимого запроса на указанный в запросе 
# URI. Если по заданному URI не существует ресурс, то сервер создаёт 
# его и возвращает статус 201 (Created). Если же был изменён ресурс, 
# то сервер возвращает 200 (Ok) или 204 (No Content). Сервер не 
# должен игнорировать некорректные заголовки Content-*, передаваемые 
# клиентом вместе с сообщением. Если какой-то из этих заголовков не 
# может быть распознан или не допустим при текущих условиях, то 
# необходимо вернуть код ошибки 501 (Not Implemented).
# Фундаментальное различие методов POST и PUT заключается в понимании 
# предназначений URI ресурсов. Метод POST предполагает, что по 
# указанному URI будет производиться обработка передаваемого клиентом 
# содержимого. Используя PUT, клиент предполагает, что загружаемое 
# содержимое соответствует находящемуся по данному URI ресурсу.
# Сообщения ответов сервера на метод PUT не кэшируются.

PATCH
# Аналогично PUT, но применяется только к фрагменту ресурса

DELETE
# Удаляет указанный ресурс.

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

CONNECT
# Преобразует соединение запроса в прозрачный TCP/IP-туннель, обычно 
# чтобы содействовать установлению защищённого SSL-соединения через 
# нешифрованный прокси.
