Типы HTTP-запросов и философия REST. Какая разница между POST и GET Какая разница между get и post

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

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

Поэтому, что-бы быть уверенным в том, что мы делаем все правильно, я представляю Вам руководство по выбору между GET и POST.

Давайте вспомним, что в строках запросов, пара переменная/значение, передается в GET через вот такой URL запрос:

GET /blog/?name1=value1&name2=value2 HTTP/1.1 Host: carsonified.com

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

POST /blog/ HTTP/1.1 Host: carsonified.com name1=value1&name2=value2

Основы: GET против POST

Давайте введем новое слово в свой словарный запас, термин - идемпотентный (Вам не стоит лезть в википедию за его трактовкой: идемпотентность это свойство объекта проявляющееся в том, что повторное действие над этим объектом не изменяет его ), а разделы 9.1, 9.3 и 9.5 RFC 2616 помогут нам составить первое правило GET против POST...

Правило #1: Используйте GET для безопасных действий и POST для небезопасных

RFC указывает Интернет браузерам на то, что пользователей необходимо предупреждать о повторном использовании POST запроса, потому что это действие потенциально небезопасно (к примеру оформление онлайн оплаты).

Однако, пока браузер соблюдает это требование RFC, может поясним почему POST должен использоваться для небезопасных действий, и почему мы не должны использовать POST для безопасных?

Просто примите к сведению то, что GET запросы используются чаще:

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

Примечание: Если Вам необходимо извлекать лучшее из обоих методов, небезопасное действие можно превратить в безопасное сделав его идемпотентным и таким образом обезопаситься от возможной проблемы многочисленных повторений запросов. Вы назначаете каждому запросу свой уникальный ID и проверяете его на сервере, был ли запрос с таким ID обработан ранее. На самом деле все небезопасные действия должны быть идемпотентными, так как пользователя не остановят никакие предупреждения.

GET против POST: копаем глубже

Правило #2: Используйте POST для операций с важной информацией

Так как в GET запросах строка запроса находится в открытом виде, мы должны заботиться о своей безопасности и о том, что пользователи будут работать с важными данными, такими как пароли или номера кредитных карт:
1. Наши пользователи могут и не догадываться об этом, передавая важные данные через URL другим лицам или когда история серфинга в их браузере может быть просмотрена другими пользователями этого компьютера (хотя это может и не сработать при работе с AJAX ориентированными сервисами).
2. Мы сами нарушаем закон о частной информации, сохраняя, к примеру, в логах своего сервера номера CV2s с кредитных карт пользователей.

Правило #3: Используйте POST для операций с большими данными

Несмотря на то, что RFC не описывает такой параметр, как длина URL, Internet Explorer упорно придерживается мнения, что максимальная длина URL не может превышать 2,048 символов, это накладывает некоторые ограничения на использование GET.

Правило #4: Используйте GET в AJAX приложениях

Когда используется XMLHttpRequest, браузеры реализуют POST как двухпроходный процесс (сперва посылают заголовок, а затем данные). Это означает, что GET запросы более отзывчивые, что так необходимо для хорошего AJAX окружения.

Итоги

Хотя правила обычно существуют для убедительных причин, хорошо бы знать то, что за ними скрывается. Я сам ненавижу правила, у которых нет объяснений и надеюсь, что все вышесказанное поможет Вам уяснить правила различий GET против POST.

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

6.1. GET и POST-запросы

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

GET -запросы

На раннем этапе развития сети Интернет существовали только GET-запросы. Они представляют собой передачу данных непосредственно в адресной строке браузера, имеющих следующий синтаксис:

http://домен/страница?[параметр1=значение1][&параметр2=значение2]...

Здесь набор передаваемых данных на сервер начинаются с символа ‘?’ и разделяются символом ‘&’. Сами данные представляют собой пары

параметр=значение

Например, если требуется передать имя и фамилию пользователя на странице регистрации (например, register.php) сайта mysite.com, то это будет выглядеть так:

http://mysite.com/register.php?fname=Иван&lname=Иванов

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

Недостатком GET-запросов является ограниченность передаваемых данных. На стороне сервера строка запроса ограничивается некоторым максимальным значением. Например, если максимальный размер запроса может составлять 1024 символа, то все что превышает это значение будет удалено и тогда часть передаваемой информации не будет обработана указанной страницей сайта. Вторым существенным ограничением является возможность передачи строго определенных наборов символов. Например, символы? и & уже зарезервированы и их передавать как значения параметров нельзя. Однако это правило можно обойти, если в строке запроса передавать не сам символ, а его кодовое значение. Для этого используется символ ‘%’, за которым следует код символа, например, так:

http://mysite.com/register.php?fname=%CC%DF%AD%1F%DS&lname=%DD

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

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

http://vk.com/profile.php?id=12345678

Также GET-запросы часто применяются для проверки корректности email-адреса при регистрации пользователя. В этом случае пользователю на указанный email приходит письмо со ссылкой активации и эта ссылка представляет собой GET-запрос.

POST -запросы

Для решения указанных недостатков GET-запросов были добавлены POST-запросы, позволяющие передавать большие объемы данных в бинарном виде, т.е. без искажений и изменений передаваемых данных. Такие запросы хорошо подходят для загрузки файлов и изображений на сервер. Например, когда пользователь загружает изображение в свой профиль социальной сети, то для этого используются POST-запросы. Более подробно об организации POST-запросов будет сказано ниже.

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

В статье я хочу рассказать, что же из себя представляют 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.

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

. Рассмотрим каждый из этих методов в подробности.

Метод GET

Метод GET использует для передачи данных строку URL. Возможно, Вы обращали внимание на длинные и непонятные URLы. Например: function.php?login=Alex&email=dezyakin . В данном случае данные обрабатываются в function.php. После знака вопроса "? " идет перечисление передаваемых параметров (параметр разделяются знаком "&") со значениями: параметру login присвоено значение Alex, а переменной email значение dezyakin. Данные будут хранится в суперглобальном массиве $_GET . Приведем пример использования метода GET представлен ниже:

Login : E-mail : С помощью суперглобального массива $_GET выводим принятые значения: */ echo "
login = ". $_GET["login"] ; echo "
email = ". $_GET["email"] ; ?>

Обратите внимание на то, как мы считываем значения из суперглобального массива $_GET: $_GET["имя_переменной"] . В нашем примере имена переменных были объявлены в форме (name=login и name=email).

Совет :
Прежде чем обрабатывать полученные значения советую проверять их на существование через функции isset(имя_переменной) или empty(имя_переменной) - эти функции были рассмотрены в предыдущем уроке 2: переменные в PHP . Например:

проверка на существование с помощью isset: if isset ($_GET["login"] ) { операторы для обработки login ... } //или же проверить на существование с помощью empty: if empty ($_GET["email"] ) { операторы для обработки email ... } ?>

В форме можно указать имя файла, который будет обрабатывать передаваемые значения. Делается это с помощью атрибута формы action , которому можно присвоить адрес этого файла. По умолчанию этот файл присвоен текущему файлу (т.е. обрабатывается в файле, где и расположена форма). Приведем пример, в котором данные из формы передаются на обработку в файл srcipt.php :

Login : E-mail :

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

Метод GET обладает множеством недостатков:

Пользователь видит значения передаваемых параметров;
Пользователь может легко подделать передаваемые параметры;
Неудобная передача бинарной информации (приходится кодировать в текстовый формат);
Объем передаваемых данных ограничен - 8 Кбайт;

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

Метод POST

Метод POST отличается от GET тем, что данные передаются в закрытой форме. Существует суперглобальный массив $_POST , из которого можно считывать данные следующим образом: $_POST["имя_переменной"] . Например:

Login : "> E-mail : ">
С помощью суперглобального массива $_POST выводим принятые значения: */ echo "
login = ". $_POST["login"] ; echo "
email = ". $_POST["email"] ; ?>

Результат выполнения выше описанного кода представлен на рисунке ниже:

Как видите URL не имеет никакой приписки, но тем не менее данные были получены и выведены.

Примечание :
1) Объем передаваемых значений методом POST по умолчанию ограничен и равен 8 Мбайт. Чтобы увеличить это значение нужно изменить директиву post_max_size в php.ini.

2) В ранних версиях PHP вместо коротких названий суперглобальных массивов $_GET и $_POST использовались более длинные имена: $HTTP_GET_VARS и $HTTP_POST_VARS . По умолчанию они выключены в php 5, но Вы можете их включить в конфигурационном файле php.ini с помощью параметра register_long_arrays . В php 6 версии эти длинные названия будут недоступны.

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

Первый метод для выполнения PHP POST запроса заключается в использовании file_get_contents . Второй метод будет использовать fread в сочетании с парой других функций. Оба варианта применяют функцию stream_context_create , чтобы заполнить необходимые поля заголовка запроса.

Пояснение кода

Переменная $sPD содержит данные, которые нужно передать. Она должна иметь формат строки HTTP-запроса , поэтому некоторые специальные символы должны быть закодированы.

И в функции file_get_contents , и в функции fread у нас есть два новых параметра. Первый из них — use_include_path . Так как мы выполняем HTTP- запрос , в обоих примерах он будет иметь значение false . При использовании значения true для считывания локального ресурса функция будет искать файл по адресу include_path .

Второй параметр — context , он заполняется возвращаемым значением stream_context_create , который принимает значение массива $aHTTP .

Использование file_get_contents для выполнения POST-запросов

Чтобы в PHP отправить POST запрос с помощью file_get_contents , нужно применить stream_context_create , чтобы вручную заполнить поля заголовка и указать, какая «обертка » будет использоваться — в данном случае HTTP :

$sURL = "http://brugbart.com/Examples/http-post.php"; // URL-адрес POST $sPD = "name=Jacob&bench=150"; // Данные POST $aHTTP = array("http" => // Обертка, которая будет использоваться array("method" => "POST", // Метод запроса // Ниже задаются заголовки запроса "header" => "Content-type: application/x-www-form-urlencoded", "content" => $sPD)); $context = stream_context_create($aHTTP); $contents = file_get_contents($sURL, false, $context); echo $contents;

Использование fread для выполнения POST-запросов

Для выполнения POST-запросов можно использовать функцию fread . В следующем примере stream_context_create используется для составления необходимых заголовков HTTP-запроса :

$sURL = "http://brugbart.com/Examples/http-post.php"; // URL-адрес POST $sPD = "name=Jacob&bench=150"; // Данные POST $aHTTP = array("http" => // Обертка, которая будет использоваться array("method" => "POST", // Request Method // Ниже задаются заголовки запроса "header" => "Content-type: application/x-www-form-urlencoded", "content" => $sPD)); $context = stream_context_create($aHTTP); $handle = fopen($sURL, "r", false, $context); $contents = ""; while (!feof($handle)) { $contents .= fread($handle, 8192); } fclose($handle); echo $contents;

Выполнение GET-запросов с помощью PHP

Теперь мы уделим внимание использованию fread и file_get_contents для загрузки контента из интернета через HTTP и HTTPS . Чтобы использовать методы, описанные в этой статье, необходимо активировать опцию fopen wrappers . Для этого в файле php.ini нужно установить для параметра allow_url_fopen значение On .

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

Использование fread для загрузки или получения файлов через интернет

Помните, что считывание веб-страницы ограничивается доступной частью пакета. Так что нужно использовать функцию stream_get_contents (аналогичную file_get_contents ) или цикл while , чтобы считывать содержимое меньшими фрагментами до тех пор, пока не будет достигнут конец файла:

В данном случае обработки POST запроса PHP последний аргумент функции fread равен размеру фрагмента. Он, как правило, не должен быть больше, чем 8192 (8*1024 ).

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

Использование file_get_contents для получения URL-адреса сайта

Еще проще использовать этот метод при считывании файла по HTTP , так как вам не придется заботиться о считывании по фрагментам — все обрабатывается в PHP .

Данная публикация представляет собой перевод статьи «Making POST Requests With PHP » , подготовленной дружной командой проекта