Применение методов 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 .

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

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

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

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

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

Я расскажу о них в контексте 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) Думаю я уже достаточно объяснил что из этого получится и какие параметры в какой массив попадут.

30.10.16 9.7K

Создание POST-запросов с помощью PHP

Первый метод для выполнения 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 ).