Этот пост - ответ на вопрос, заданный в комментарии к одной из моих статей.

В статье я хочу рассказать, что же из себя представляют HTTP-методы GET/POST/PUT/DELETE и другие, для чего они были придуманы и как их использовать в соответствии с REST.

HTTP

Итак, что же представляет из себя один из основных протоколов интернета? Педантов отправлю к RFC2616 , а остальным расскажу по-человечески:)

Этот протокол описывает взаимодействие между двумя компьютерами (клиентом и сервером), построенное на базе сообщений, называемых запрос (Request) и ответ (Response). Каждое сообщение состоит из трех частей: стартовая строка, заголовки и тело. При этом обязательной является только стартовая строка.

Стартовые строки для запроса и ответа имеют различный формат - нам интересна только стартовая строка запроса, которая выглядит так:

METHOD URI HTTP/VERSION ,

Где METHOD - это как раз метод HTTP-запроса, URI - идентификатор ресурса, VERSION - версия протокола (на данный момент актуальна версия 1.1).

Заголовки - это набор пар имя-значение, разделенных двоеточием. В заголовках передается различная служебная информация: кодировка сообщения, название и версия браузера, адрес, с которого пришел клиент (Referrer) и так далее.

Тело сообщения - это, собственно, передаваемые данные. В ответе передаваемыми данными, как правило, является html-страница, которую запросил браузер, а в запросе, например, в теле сообщения передается содержимое файлов, загружаемых на сервер. Но как правило, тело сообщения в запросе вообще отсутствует.

Пример HTTP-взаимодействия

Рассмотрим пример.

Запрос:
GET /index.php HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Accept: text/html Connection: close
Первая строка - это строка запроса, остальные - заголовки; тело сообщения отсутствует

Ответ:
HTTP/1.0 200 OK Server: nginx/0.6.31 Content-Language: ru Content-Type: text/html; charset=utf-8 Content-Length: 1234 Connection: close ... САМА HTML-СТРАНИЦА...

Ресурсы и методы

Вернемся к стартовой строке запроса и вспомним, что в ней присутствует такой параметр, как URI. Это расшифровывается, как Uniform Resource Identifier - единообразный идентификатор ресурса. Ресурс - это, как правило, файл на сервере (пример URI в данном случае "/styles.css"), но вообще ресурсом может являться и какой-либо абстрактный объект ("/blogs/webdev/" - указывает на блок «Веб-разработка», а не на конкретный файл).

Тип HTTP-запроса (также называемый HTTP-метод) указывает серверу на то, какое действие мы хотим произвести с ресурсом. Изначально (в начале 90-х) предполагалось, что клиент может хотеть от ресурса только одно - получить его, однако сейчас по протоколу HTTP можно создавать посты, редактировать профиль, удалять сообщения и многое другое. И эти действия сложно объединить термином «получение».

Для разграничения действий с ресурсами на уровне HTTP-методов и были придуманы следующие варианты:

• GET - получение ресурса
• POST - создание ресурса
• PUT - обновление ресурса
• DELETE - удаление ресурса

Обратите внимание на тот факт, что спецификация HTTP не обязывает сервер понимать все методы (которых на самом деле гораздо больше, чем 4) - обязателен только GET, а также не указывает серверу, что он должен делать при получении запроса с тем или иным методом. А это значит, что сервер в ответ на запрос DELETE /index.php HTTP/1.1 не обязан удалять страницу index.php на сервере, так же как на запрос GET /index.php HTTP/1.1 не обязан возвращать вам страницу index.php, он может ее удалять, например:)

В игру вступает REST

REST (REpresentational State Transfer) - это термин был введен в 2000-м году Роем Филдингом (Roy Fielding) - одним из разработчиков протокола HTTP - в качестве названия группы принципов построения веб-приложений. Вообще REST охватывает более широкую область, нежели HTTP - его можно применять и в других сетях с другими протоколами. REST описывает принципы взаимодействия клиента и сервера, основанные на понятиях «ресурса» и «глагола» (можно понимать их как подлежащее и сказуемое). В случае HTTP ресурс определяется своим URI, а глагол - это HTTP-метод.

REST предлагает отказаться от использования одинаковых URI для разных ресурсов (то есть адреса двух разных статей вроде /index.php?article_id=10 и /index.php?article_id=20 - это не REST-way) и использовать разные HTTP-методы для разных действий. То есть веб-приложение, написанное с использованием REST подхода будет удалять ресурс при обращении к нему с HTTP-методом DELETE (разумеется, это не значит, что надо давать возможность удалить всё и вся, но любой запрос на удаление в приложении должен использовать HTTP-метод DELETE).

REST дает программистам возможность писать стандартизованные и чуть более красивые веб-приложения, чем раньше. Используя REST, URI для добавления нового юзера будет не /user.php?action=create (метод GET/POST), а просто /user.php (метод строго POST).

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

Проблемы?

Да, есть небольшая проблема с применением REST на практике. Проблема эта называется HTML.

PUT/DELETE запросы можно отправлять посредством XMLHttpRequest, посредством обращения к серверу «вручную» (скажем, через curl или даже через telnet), но нельзя сделать HTML-форму, отправляющую полноценный PUT/DELETE-запрос.

Дело в том, спецификация HTML не позволяет создавать формы, отправляющие данные иначе, чем через GET или POST. Поэтому для нормальной работы с другими методами приходится имитировать их искусственно. Например, в Rack (механизм, на базе которого Ruby взаимодействует с веб-сервером; с применением Rack сделаны Rails, Merb и другие Ruby-фреймворки) в форму можно добавить hidden-поле с именем "_method", а в качестве значения указать название метода (например, «PUT») - в этом случае будет отправлен POST-запрос, но Rack сможет сделать вид, что получил PUT, а не POST.

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

Немного о HTTP

Сервер принимает три типа запросов: GET, POST и HEAD. Запрос программы к Web-серверу выглядит следующим образом:

GET /index.html HTTP/1.0

Первая часть, в данном случае GET , - это метод запроса, вторая, index.html , - запрашиваемый URL, третья, HTTP/1.0 , - протокол, используемый клиентом.

Два основных метода запроса - это GET и POST. Это те самые методы которые доступны вам при создании формы. Метод HEAD редко используется броузером, поскольку он запрашивает только заголовок ответа, а тело ответа в таком случае не передается. Например, для проверки того, не изменилась ли страница, броузер может запросить заголовок, но при этом не порождается полноценный обмен данными.

Метод GET

По умолчанию при запросе используется метод GET. Метод POST используется только тогда, когда это явно указано в запросе формы. Для CGI-программиста очень важно понимать, что при запросе методом GET данные формы передаются серверу вместе с URL. Web-серверы, поддерживающие CGI, копируют эти данные в переменную окружения с именем QUERY_STRING . После этого забота о получении данных из переменной окружения и их обработке возлагается на CGI-программу.

URL со строкой запроса выглядит так:

Http://www.domen-name.com/login.pl?nick=maks&psw=parol

Знак? отделяет строку запроса от собственно URL ресурса; nick и psw - переменные передаваемые серверу, maks и parol - их значения соответственно.

Метод POST

Метод POST используется тогда, когда это явно указано в атрибуте формы METHOD. В отличии от метода GET, POST помещает данные не в URL, а в тело запроса. Запрос POST во многом похож на ответ HTTP. Первая строка представляет собой стандартный запрос HTTP, в котором указан метод POST. В ней могут быть необходимые дополнительные заголовки, отделяемые от тела запроса пустой строкой.

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

Выбор между GET и POST

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

Рассмотрим несколько ситуаций, когда есть смысл предпочесть метод GET или POST.

• Если вы хотите, чтобы ваша программа вызывалась с помощью ссылки, предпочтение следует отдать методу GET.
• Если вы не хотите, чтобы аргументы, передаваемые вашей программе, записывались в файл отчета сервера, используйте метод POST. Например, если форма требует указать имя пользователя и пароль, вы вряд ли захотите, чтобы имена и пароли сохранялись в файле отчета. Кроме того, не разумно передавать пароль как часть URL.
• Если ваша форма имеет значительные размеры, непример в ней есть текстовые окна с заметками и коментариями, следует использовать метод POST. Вообще говоря, можно и в этом случае применять метод GET, но тогда вы сможете столкнуться с ограничениями на размер URL, разными для разных операционных систем и броузеров (ограничение обусловленно размером переменных окружения). Проще воспользоваться методом POST.
• Если ваша форма содержит файловое поле, используйте метод POST. Кроме того, в этом случае нужно установить значение атрибута ENCTYPE в multipart/form-data .

Сейчас наиболее часто используются всего два HTTP метода: GET и POST. Но оказалось, что даже среди этих двух «сосен» веб разработчики умудряются теряться. Этому есть объяснение: оба метода можно использовать для получения одинакового результата. Но нужно помнить, что необдуманное применение какого-либо из методов может привести к плачевным последствиям, среди которых большие нагрузки на канал и дыры в безопасности.

Чтобы этого избежать достаточно просто детальней разобраться в назначениях и различиях этих методов.

Если вникнуть в значение названий методов, уже многое прояснится. GET (с англ. получать), т.е. следует применять для запроса данных. POST (c англ. отправлять по почте) — применяем для отправки данных на сервер. Вроде все предельно просто и понятно. Но кто желает разрабатывать сайты чуть сложнее сайта визитки с одной формой обратной связи, лучше с вопросом познакомиться поближе.

Безопасные и небезопасные HTTP запросы

Спецификация HTTP 1.1 вводит два понятия: безопасный и небезопасный запрос, или если быть более точным, метод.

Безопасные — это методы, которые могут лишь запросить информацию. Они не могут изменить запрашиваемый ресурс, не могут привести к нежелательным результатам для пользователя, других лиц или сервера. Примерами безопасных есть запрос HTML кода веб страницы или изображения. К безопасным относятся методы HEAD и GET.

Заметка

В реальности умельцы конечно могут нанести вред и GET запросами. Например, зацикливаниями запросов.

Небезопасные запросы, как уже все догадались, могут потенциально привести к нехорошим последствиям, если ими воспользоваться повторно. Такие запросы могут менять содержимое ресурса, к которому обращаются. Примеры таких запросов: отправка сообщений, регистрация, онлайн платежи. К небезопасным относятся методы POST, PUT, DELETE.

Идемпотентнные (idempotent) методы

Идемпотентность — свойство методов, которые при многочисленном повторном обращении вернут один и тот же результат, кроме случаев когда информация устарела. Это значит, что при обращении к одному и тому же URL все пользователи будут видеть одну и туже веб страницу, изображение, видео и т.п. Таким свойством обладают GET, PUT, DELETE методы.

А теперь подробней о самих методах GET и POST: составим каждому короткое «резюме».

GET

• предназначен для получения данных с сервера;
• тело запроса пустое;
• обрабатываются на стороне сервера быстрее и с меньшим потреблением ресурсов сервера за счет пустого тела запроса;
• передача переменных происходит в адресной строке (так видит пользователь, технически данные предаются в строке запроса) и поэтому видна информация о переменных и их значениях (данные не защищены);
• способен передать небольшое количество данных на сервер: есть ограничения на длину URL, которое зависит от браузера, например, IE6 = 2Kb. На это число и рекомендуют ориентироваться разработчики Yahoo!;
• может передать только ASCII символы;
• такой запрос можно скопировать, сохранить (например, в закладках);
• запрос может кэшироваться (этим можно управлять);
• для дополнительного снижения нагрузки на канал и сервер доступны условные и частичные запросы;
• не разрывает HTTP соединение (при включенном на сервере режиме keepAlive).

POST

• предназначен для отправления данных на сервер;
• передача данных происходит в теле запроса;
• обработка на стороне сервера медленнее и «тяжелее», чем GET, потому что помимо заголовков нужно анализировать тело запроса;
• способен передать большие объемы данных;
• способен передать файлы;
• страницу, сгенерированную методом POST нельзя сохранить в закладки;
• разрывает HTTP соединение;
• для передачи даже очень малого объема информации большинством браузеров отправляет минимум два TCP пакета: заголовок, а потом тело запроса.

Оказывается не такие уж и похожие эти два метода. Применение того или иного должно быть обусловлено поставленной задачей, а никак не тем, что GET используется по умолчанию или с ним легче работать. GET, конечно, в большинстве случаев более выигрышный вариант, особенно при построении быстрых AJAX, но не стоит забывать о его недостатках. Для себя же сделал простую алгоритм-заметку по выбору метода.

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

Я расскажу о них в контексте PHP. Прошу заметить что протокол HTTP к PHP имеет косвенное отношение потому что он создавался для обмена html страницам а PHP просто расширяет возможности и того и другого.

GET запрос используется чтобы получить данные а POST чтобы отправить. (Напоминаю что технически они работают одинаково).

Поэтому в контексте PHP опираясь на эту идеологию сделали следующим образом:
1. При каждом запуске PHP по умолчанию создаются суперглобальные массивы ($_GET, $_POST).
2. Если в строке запроса есть вопросительный знак(?). То все что после него считается параметрами GET запроса они представлены в формате "ключ"="значение" и в качестве разделителя используется знак амперсанда (&)
Пример:
GET /index.php?name=Андрей&surname=Галкин
это строка запроса, тут 2 параметра. эти параметры попадут в массив $_GET.
3. $_POST заполняется другим способом. содержимое этого массива заполняется из "заголовков запроса". То есть из места, скрытого от глаз в явном виде. Всю рутину по созданию таких заголовков берет на себя браузер. Хотя иногда и что-то редактируется в заголовках в ручную.

Чаще всего пост запрос используется в формах (для отправки данных).

Например у нас есть форма для входа 2 поля логин и пароль.

Представим что мы используем GET метод. Тогда при отправке формы мы перейдем на следующий адрес /login.php?login=Андрей&password=123 согласитесь что так передавать такую информацию совсем не безопасно. Любой может открыть ваш браузер и начиная вводить адрес сайта он из истории может увидеть ваши пароли и логины.

А вот если бы мы указали методом POST то мы бы получили следующий запрос:
POST /login.php (login=Андрей&password=123) то что в скобочках было бы скрыто и никак не сохранено в браузере.

В общем подводя итог:
GET - это чтобы получить определенную страницу в определенном виде (сортировка, текущая страница в блоге, строка поиска и т.п.).
POST - для оправки данных которые не влияют на отображение страницы, в том плане что эти данные влияют только на результат выполнения скрипта (логины, пароли, номера кредиток, сообщения и т.п.).

И еще одна хорошая новость их можно комбинировать, например
POST /index.php?page=login (login=Андрей&password=123) Думаю я уже достаточно объяснил что из этого получится и какие параметры в какой массив попадут.

• Метод POST передает данные таким образом, что пользователь сайта уже не видит передаваемые скрипту данные:
  http://www.komtet.ru/script.php

Оба метода успешно передают необходимую информацию из веб-формы скрипту, поэтому при выборе того или иного метода, который будет наиболее подходить Вашему сайту, нужно учитывать следующие факторы:

1. Принцип работы метода GET ограничивает объем передаваемой скрипту информации;
2. Так как метод GET отправляет скрипту всю собранную информацию формы как часть URL (то есть в открытом виде), то это может пагубно повлиять на безопасность сайта;
3. Страницу, сгенерированную методом GET, можно пометить закладкой (адрес страницы будет всегда уникальный), а страницу, сгенерированную метод POST – нельзя (адрес страницы остается неизменным, так как данные в URL не подставляются);
4. Используя метод GET можно передавать данные не через веб-форму, а через URL страницы, введя необходимые значения через знак &:
   http://www.komtet.ru/script.php?login=admin&name=komtet
5. Метод POST в отличие от метода GET позволяет передавать запросу файлы;
6. При использовании метода GET существует риск того, что поисковый робот может выполнить тот или иной “открытый запрос”

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

На основании этой характеристики можно делать вывод, когда нужно использовать POST , а когда GET . Например, если пользователь хочет сохранить сгенерированную страницу в закладки. То генерация должна происходить путём GET-запроса , иначе добавить страницу в закладки не получится. Другой пример: при передаче логина и пароля нельзя ставить метод GET , так как он основан на передаче данных через адресную строку. Иначе после нажатия кнопки “Submit “, в адресной строке появится что-то наподобии этого: “http://test.ru/login.php?log=User&pass=123 “, – и пароль может увидеть, кто угодно, чего, разумеется, допускать нельзя. Поэтому здесь надо использовать метод POST .

Также не забывайте, что размер данных, которые можно передать методом POST , на порядок больше, чем при передаче методом GET . В общем, анализируйте эту таблицу и делайте вывод: каким методом передачи данных нужно пользоваться в конкретном случае. От себя добавлю, что в 80% случаев надо использоватьPOST , но и не забывайте, что это далеко не 100% .