Как очистить post запрос php
Обрабатываем POST-запросы в PHP
Итак, в прошлом уроке мы вспоминали о том, как происходит работа пользователя с сайтом. Их общение происходит в форме запрос-ответ. Пользователь отправляет в запросе какие-то данные, а сервер возвращает какой-либо ответ, в зависимости от этих данных.
В предыдущем уроке мы научились работать с GET-запросами. Как мы помним, при этом способе данные передаются на сервер с помощью параметров в адресной строке. Такое бывает удобно, когда нам нужно поделиться ссылкой в которой эти параметры нужны. Например, у нас спрашивают, где в Москве купить шкаф. И мы скидываем человеку ссылку на поиск в Яндексе:
https://yandex.ru/search/?text=шкаф%20в%20москве%20купить
Он переходит по ней и прекрасно себя чувствует, потому что всё уже введено за него.
Однако, параметры в адресной строке – это не всегда уместно. Например, когда в параметрах содержится какая-то конфиденциальная информация: пароль, пин-код. И любой мимо проходящий человек может её увидеть. Как в такой ситуации быть? Использовать POST-запросы!
Что это такое? Да всё тот же запрос от клиента к серверу, только параметры передаются внутри тела запроса, а не в адресной строке. И увидеть их просто так не получится.
Что за тело запроса? Ну, это просто данные, которые передаются на сервер. При этом они скрыты от лишних глаз.
Чтобы отправить POST-запрос нужно в HTML-форме задать для атрибута method значение POST.
Данные, отправленные с помощью POST-запроса доступны в PHP в суперглобальном массиве $_POST.
Давайте выведем переданные скриптом выше значения login и password. Для этого в файл login.php положим следующий код:
Откройте теперь форму, введите в неё значения и нажмите кнопку «Войти».
Вы увидите введенные вами в форме данные, при этом они будут отсутствовать в адресной строке. Вуаля! Теперь никто не подсмотрит ваш пароль в адресной строке. 
Как увидеть тело POST-запроса
Чтобы увидеть данные POST-запроса в браузере, в Google Chrome нужно перейти в режим разработчика. Нажмите клавишу F12, находясь в окне браузера. После этого вы увидите панель разработчика. 
Перейдите во вкладку Network, а затем установите галочку напротив пункта Preserve log.
Теперь вернитесь на форму, и снова введите данные, после чего нажмите на кнопку «Войти». 
Одновременно с тем, как вы нажмете на кнопку входа, вы увидите в панели разработчика запрос на login.php. 
Нажмите на него, и справа откроются детали запроса. По умолчанию открывается исходный код ответа. Здесь можно увидеть то, что было сгенерировано с помощью PHP и отправлено веб-сервером в браузер. 
Нас здесь интересует вкладка Headers. Перейдите в неё, и прокрутите содержимое в самый низ. Здесь вы увидите те данные, что браузер отправил на сервер. 
Заключение
Вот так и работают POST-запросы под капотом. Используют их всегда, когда не нужно отображать детали запроса в адресной строке. Хорошие примеры: форма авторизации, ввод данных о кредитной карте. Такими данными лучше в адресной строке не светить.
Если этот урок был вам полезен, расскажите об этом курсе своим знакомым или поделитесь на него ссылкой в социальных сетях.
RESTful PHP — 5 простых советов
REST (Representational state transfer) — это архитектурный стиль или свод соглашений для web-приложений и сервисов, основанный на манипулировании ресурсами и спецификацией HTTP. Впервые об этом заговорил Рой Филдинг (Roy Fielding) — один из отцов основателей HTTP (Hypertext Transfer Protocol).
Web-приложения зачастую игнорируют спецификацию HTTP и двигаются вперёд используя полюбившиеся возможности: GET и POST, 200 OK и 404 NOT FOUND. Так как используются программируемые web-приложения, со своими собственными API, то решение игнорировать спецификацию HTTP, может создать проблемы в дальнейшем. Как следствие — имеем множество приложений с интерфейсами GET и POST. Например интерфейс удаления пользователя: GET /user/1/delete против POST /user/delete
Такие важные методы HTTP, как — POST, GET, PUT и DELETE — зачастую сравнивают с CREATE, READ, UPDATE, DELETE (CRUD) операциями маниулирования базами данных. HTTP отделяет понятие web-сервер и web-браузер. Это позволяет каждой реализации отличаться от других подобных, основанных на «клиент/сервер» принципе.
Теперь самое время взглянуть на примеры, так будет понятнее.
1. Использование методов PUT и DELETE
2. Отправка выборочных HTTP 1.1 заголовков
PHP позволяет кастомизировать заголовки посылаемые клиенту. В свою очередь заголовок содержит код ответа от сервера. По умолчанию PHP ответит кодом 200 OK на успешный запрос, на использование функции die() или на создание нового ресурса. Собственно есть два пути кастомизировать ситуацию:
Первый вариант достаточно стандартный метод установки кода ответа. Если же потребуется указать перенаправление на ресурс «201 Created» или «301 Moved Permanently», это несложно реализовать, указав код в третьем параметре функции header(), как показано в примере. Второй пример можно заменить на более удобочитаемый код:
3. Отправка значимых HTTP заголовков
Смысл заключается в использовании прописанных в спецификации заголовков, которые являются вполне самодостаточными, но зачастую игнорируются или эмулируются более стереотипными решениями.
201 Created — используется если был создан новый ресурс. Должен применяться с функционалом направления на ресурс, например /tech/news, т.к. сам автоматического направления не использует.
202 Accepted — как бы говорит клиенту «ваш заказ принят и скоро будет обработан». В отличие от кода 201, который отсылается после создания ресурса, код 202 ставит запрос в очередь.
204 No Content — В связке с кэшированием и условным GET запросом (запросы с If-Modified-Since/If-None-Match заголовками), позволяет сказать web-приложениям «контент не изменился, продолжайте юзать кэшированную версию», без повторной переработки и отправки кэша.
401 Unauthorized — должен использоваться при попытке обратиться к ресурсу, требующему определённого уровня доступа. Используется в связке с www-authentication.
500 Internal Server Error — гораздо лучше 200 OK, когда PHP скрипт уже не дышит или привёл к исключению.
Естественно заголовков гораздо больше, на эту тему неоднократно было написано, приведённые выше — всего лишь примеры.
Настоящее RESTful PHP приложение должно быть полностью независимо, все запросы должны содержать достаточно информации чтобы на них можно было отреагировать без дополнительных усилий со стороны сервера. На практике это подразумевает сохранение авторизационной информации в куках с датой (timestamp) и контрольной суммой. Дополнительная информация так же может быть сохранена в куках. В случае если требуется сохранить большие объёмы данных, их можно уложить в базу данных, авторизационную информацию стоит оставить в куках. UPD: Надо оговориться, что использование cookies не в полной мере соответствует идеологии REST, т.к. сеансовые связи сохраняются. Но в случае cookies информация о сеансе хранится у клиента, а в случае использования session сеансовые связи хранятся во временной директории сервера и в сессионной куке клиента (если включен «session.use_cookies»).
5. Тестирование при помощи cURL или rest-client
cURL позволяет легко выполнять любые HTTP методы для нужного ресурса. Можно передавать любые параметры запросов и заголовков, а так же проверять ответные заголовки и данные. Инструмент коммандной строки «curl», стандартен для большинства *nix систем. Для пользователей Windows подойдёт MinGW/MSYS.
Пример использования и базовые опции:
-X [METHOD] определяет HTTP метод.
-d «name=value» устанавливает имя и значения переменных в POST/PUT.
-H [HEADER] устанавливает заголовок.
-I отображает заголовки ответа.
Так же существует бесплатный графический, основанный на Java/Swing, rest-client для тестирования REST. Он так же поддерживает JSON/XML.
Полезные ссылки по теме
Где так или иначе используется
* restful (англ.) — успокоительный; успокаивающий.