Вредоносное ПО (malware) - это назойливые или опасные программы,...
Этот пост - ответ на вопрос, заданный в комментарии к одной из моих статей.
В статье я хочу рассказать, что же из себя представляют 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 - удаление ресурса
В игру вступает 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.
Очень давно хотел написать статью, в которой рассказать о разнице между методом POST и методом GET , но всё как-то появлялись другие темы, и переключался на них. И вот, наконец-то, пришло время осветить эту тему, так как зачастую люди просто не знают, какая разница между POST и GET .
Чтобы более наглядно отобразить разницу между POST и GET , привожу таблицу, в которой видно, по каким характеристикам они различаются.
На основании этой характеристики можно делать вывод, когда нужно использовать POST , а когда GET . Например, если пользователь хочет сохранить сгенерированную страницу в закладки. То генерация должна происходить путём GET-запроса , иначе добавить страницу в закладки не получится. Другой пример: при передаче логина и пароля нельзя ставить метод GET , так как он основан на передаче данных через адресную строку. Иначе после нажатия кнопки "Submit ", в адресной строке появится что-то наподобии этого: "http://mysite.ru/login.php?log=User&pass=123456 ", - и пароль может увидеть, кто угодно, чего, разумеется, допускать нельзя. Поэтому здесь надо использовать метод POST .
Также не забывайте, что размер данных, которые можно передать методом POST , на порядок больше, чем при передаче методом GET . В общем, анализируйте эту таблицу и делайте вывод: каким методом передачи данных нужно пользоваться в конкретном случае. От себя добавлю, что в 80% случаев надо использовать POST , но и не забывайте, что это далеко не 100% .
Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.
Комментарии (15 ):
dsmts 12.05.2013 14:00:18
Добрый день! Мне нужно что бы при редиректе например: header("Location: test.php"); передавался на эту страницу $_POST значение. Страница, с которой должно передаваться это значение не имеет ни каких форм. Т.е. она просто обрабатывает данные и формирует определенный запрос. На данный момент у меня сделана передача с помощью cookie. Но я не уверен, что это безопасно. Или я ошибаюсь? Данные, которые передаются, не должны быть видимы пользователям.
Ответить
Alex_ 23.11.2013 23:56:10
Доброго времени суток:), Михаил! Пробую писать плагин на php и естественно обнаружил у себя нехватку знаний. Отсюда вопрос: если некий сайт (платежная система) после моих действий на моей стороне присылает мне на сайт на конкретную страницу данные методом POST должен ли я увидеть их если напишу в скрипте print_r($_POST); ? Просто в моем случае например print_r($_SERVER); видно какие данные в массиве $_SERVER, а $_POST пустой, то есть либо данные не приходят либо у меня профанский взгляд на то как на самом деле обстоят дела.
Ответить
23.11.2013 23:59:31
Здравствуйте,Александр Обычно платёжные системы передают данные в обратном порядке в зашифрованном виде и по защищённым протоколам. Так что всё зависит от платёжной системы. Вы пишете модуль оплаты для какой-либо конкретной системы? Уточните запросы иначе я не смогу Вам помочь
Ответить
Alex_ 24.11.2013 02:00:41
Здравствуйте Александр, спасибо за отклик. Пишу плагин для cms Wordpress, работаю с платежной системой interkassa.com . При удачной покупке перебрасывает на страницу успешной оплаты http://мой_сайт/success . на эту страницу согласно документации приходят данные, которые мне видны. То есть я в настройках выбирал передачу GET методом и приходит длинный url эта ссылка и в ней параметры http://мой_сайт/success/?&ik_payment_id=1&ik_paysystem_alias=yandexdengir ,все как положено. Пробовал выбирать метод передачи POST тогда в скрипте прописывал например if (isset($_POST["ik_trans_id"])) echo $_POST["ik_trans_id"]. И это работало. Потом стал работать со STATUS url потомучто тогда приходит ik_sign_hash который формируется интеркассой с использованием секретного ключа (который известен мне и интеркассе) и в этот раз if (isset($_POST["ik_sign_hash"]) не срабатывает потомучто его нет. У меня на сайте стоит плагин (не все делает как хотелось бы) написанный на ООП (до уровня того кто это писал мне еще далеко, может поэтому мне не очевидно что там используется). Этот плагин все отрабатывает и рассчитывает хеш на своей стороне, потомучто я умышленно менял секретный ключ (в настройках плагина) и на почту приходило письмо с уведомлением о неверно переданных данных (хеши не совпали)и просьбой обратиться к администратору сайта. Вот как-то так.
Ответить
24.11.2013 02:09:28
Ну,я не видел Ваш плагин,поэтому конкретного ничего не скажу. Что касается простой реализации...Я не изучал API интеркассы. Простое решение можете посмотреть тут: http://goo.gl/rFnpNc По сути во всех системах одинаково. Я обычно с робокассой работаю или онпей,так что извините. А вообще структура примерно такая.Вам нужно в соответствии с документацией API написать реализацию http://www.interkassa.com/faq.php смотрите тут раздел Interkassa глазами программиста и администратора+ Там в последнем из вопросов есть тех.документация для скачки ну и мелочи по API вообще
Ответить
Alex_ 24.11.2013 02:16:40
Спасибо Александр. Видел я все это читал, пробую уже не первый день и гуглю вот и думаю может я чего не понимаю:). http://goo.gl/rFnpNc - а это плагин Андрея Морковина, написанный не до конца (наверное чтобы не раскрывать всех секретов скрипт теперь платный). По нему создано несколько видео уроков о том как писать плагины на WP. Вот этот плагин http://www.icprojects.net/paid-downloads-plugin.html есть в платной и бесплатной версии. В бесплатной версии доступна только оплата PAYPAL. но он весь и если поменять пару значений становится доступен режим Интеркассы в бета версии.
Ответить
24.11.2013 02:23:00
Да,я в курсе этого.Просто валялся плагин.До конца или нет,но он работал.Может,где-то версия и за 40у.е. валяется. В любом случае ничего конкретного не посоветую. Читайте документацию по API Интеркасса А алгоритмы везде одинаковы.Пишете обработчик который посылает данные в шифрованном виде и который их в таком же виде принимает и расшифровывает. Можете подсмотреть решение у Левчука в его wppage ;) Если будет время,то разберу эту тему более подробно
Да да, все когда-то учились чему либо. Единственное что в этом плане отличает людей — кому-то учения даются легко, а кто-то не может разобраться в сути вопроса долгие месяцы. Сегодня мы поговорим о POST и GET запросах в HTML\PHP.
Сами запросы POST и GET (далее просто запросы) давно проросли корнями во все Интернет ресурсы. Если вдруг когда нибудь и появится альтернатива данным технологиям, то наверное это будет не скоро, да и, наверное, не нужно. Потому что наши запросы вполне полно выполняют задачу обмена данными между Интернет страницами.
Давайте рассмотри сначала запрос типа GET. Создадим файл index.php со стандартным html кодом, а так же разместим на нем форму, пусть это будет форма заказа товара.
Здесь обратим внимание на тег form . Он имеет два параметра action и method . Первый отвечает за адрес страницы, на которую мы будем передавать наши данные, второй — за метод, которым эти данные будут передаваться. Внутри данного тега описываются набор наших данных, которые мы хотим передавать. Обязательно данным присваиваются имена (параметр name ). Так же обязателен input типа submit , который является кнопкой, по нажатию на которую происходит отправка данных.
Давайте сохраним наш файл и откроем его в браузере.
Путь нашей страницы в браузере «…/index.php». На самой странице мы видим два поля для ввода и кнопку. Давайте вобъем в наши поля что-нибудь и нажмем на кнопку «Заказать». Наша страница обновилась. Давайте посмотрим на ее адрес: «…/index.php?orderName=Test&count=12». (я вбил в первое поле слово ‘Test’ во второе ’12’). Как мы видим адрес страницы немного поменялся. Дело в том что передача параметров GET запросом осуществляется путем их приписывания в строку адреса страницы. Параметры отделяются от основного адреса символом ‘?’, а разные параметры символом ‘&’. Структура параметров следующая: название_параметра=значение
. Название параметра будет совпадать со значением атрибута name в поле input.
Давайте немного подредактируем код страницы:
Теперь нажмем на кнопку «Заказать» еще раз. Как мы видим страница обновилась, однако наши поля остались заполнены. Это произошло благодаря тому, что мы указали значение по умолчанию для наших полей. Причем эти значения — полученный параметр GET. Как мы видим в PHP коде GET параметры являются массивом со строковым индексом равным имени параметра. Если сейчас поиграться с адресом сайта и в нем поменять значения параметров и нажать кнопку «Enter», то мы опять заметим картину с обновлением страницы и заполнением нашей формы.
Очевидно что пересылать секретные или служебные данные в GET запросе неправильно (и не безопасно). Его лучше использовать для передачи, например, id новости, которую стоит взять из базы или имени страницы, которую стоит отобразить.
Другое дело POST запрос. Работает он аналогично, однако не сохраняет параметры в строке адреса. Изменим нашу форму:
Как видно изменилось не многое, Однако! Откроем нашу страницу, вобъем что-нибудь в поля и нажмем кнопку «Заказать». Все сработало аналогично, однако (однако), как мы видим в строке запросов красуется адрес «…/index.php» без всякого рода параметров. Таким образом мы как бы «скрыли» наши данные от посторонних глаз. Конечно понятие скрыли, достаточно условное, так как эти данные все равно можно перехватить, но это уже другая история. Давайте допишем в наш адрес параметры «…/index.php?orderName=Trololo&count=100» и нажмем «Enter». Как мы видим страница загрузилась, однако даже не смотря на передачу параметров, поля оказались пустые. Это говорит о том что несмотря на большую схожесть, данные виды запросов никак не пересекаются между собой и если есть необходимость стоит писать обработчик для каждого типа запроса отдельно.
Думаю на этом хватит. Азы вопроса, я думаю, описаны с головой.
И еще немного… Не стоит забывать о проверке передаваемых параметров. Если Вы точно знаете, что параметр должен являться числом, то присекайте все попытки передачи не числового значения и т.п…
Общего между ними то что они работают одинаково. Разницы между ними технически никакой. А вот идеологические различия есть.
Я расскажу о них в контексте 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) Думаю я уже достаточно объяснил что из этого получится и какие параметры в какой массив попадут.
Сегодня мне немного захотелось ударится в примитивные вещи и описать то, что можно найти во всемирной сети в большом количестве и без особых трудов. Речь пойдет практически о святая святых протокола HTTP: POST и GET запросах.
Многие спросят зачем? Отвечу коротко и ясно: что это и зачем это нужно — знают далеко не все, а те кто хочет узнать об этом (при этом мало что понимая в it сфере) часто не могут понять то что пишут во многих и многих статьях посвященных данной теме. Я же постараюсь на пальцах объяснить что такое POST и GET запросы и с чем их едят.
Итак, начнем наше путешествие в сказку…
Если вы читаете данное сообщение, то Вы как минимум знаете как выглядит Интернет и что такое Интернет сайт. Опустив все тонкости работы всемирной паутины, будем оперироваться такими понятиями как пользователь и сайт. Как ни крути но эти два субъекта должны как-то взаимодействовать друг с другом. Вот люди, например, общаются между собой благодаря жестам, эмоциям и речи, животные издают какие-то звуки, а что же происходит при «общении» человека и Интернет ресурса? Здесь мы имеем случай обмена информацией, который можно перенести и на человеческий разговор плана «Вопрос-Ответ». Причем и вопросы и ответы могут задавать как и пользователь, так и сайт. Когда мы говорим о сайте, то его вопросы и ответы, как правило, всегда выражаются в виде Интернет страницы с тем или иным текстом. Когда же речь идет о пользователе, то тут все происходит благодаря GET и POST запросам (конечно не только, но мы говорим о них).
Таким образом мы выяснили, что объекты нашей темы необходимы для «общения» с сайтами. Причем как и GET, так и POST запросы могут использоваться и для «задания вопросов» сайту и для «ответов». Чем же они отличаются? Все достаточно просто. Однако для объяснения различий, придется рассмотреть пример, в качестве которого возьмем сайт плана Интернет магазин.
Наверное Вы часто обращали внимание, когда искали что-нибудь в онлайн магазинах, что прибегая к поиску по фильтрам, адрес сайта превращался из красивого «http://magaazin.ru» в страшный «http://magaazin.ru/?category=shoes&size=38». Так вот, все что идет после символа ‘?’ и есть Ваш GET запрос сайту, а если быть совсем точным, то в данном случае Вы как бы спрашиваете сайт, о том что у него есть в категории «Обувь» с размеров «38» (данный пример взят из головы, на деле все может выглядеть не так очевидно). В итоге мы имеем что вопросы мы можем задавать сами, путем указания их в строке адреса сайта. Очевидно, что данный метод имеет несколько недостатков. Во-первых, любой кто находится рядом с пользователем за компьютером, может спокойно подсмотреть все данные, поэтому использовать данный вид запросов для передачи паролей крайне не желательно. Во-вторых, есть ограничение на длину строки, которая может быть передана из поля адреса сайта, а значит особо много данных передать не получится. Однако несомненным плюсом использования GET запросов является его простота использования и возможность быстро спрашивать сайт, что особенно бывает полезно при разработке, но это уже другая история…
Теперь поговорим о POST запросах. Догадливые читатели, возможно, смекнули, что главным отличаем данного запроса от его собрата — скрытность передаваемых данных. Если рассматривать Интернет магазин, то ярким примером где используется запрос POST — регистрация на сайте. Сайт спрашивает Ваши данные, Вы эти данные заполняете и при нажатии на кнопку «Регистрация» посылаете свой ответ. Причем никак внешне эти данные не отобразятся. Так же стоит отметить, что запрашивать могут достаточно большое количество информации — а значим ограничений POST запрос не имеет. Ну и если затронуть минус, то такой запрос быстро не сгенерируешь. Без специальных навыков, тут уже не обойтись. Хотя на самом деле все не так уж и сложно, но это опять же — другая история.
Подведем небольшой итог. POST и GET запросы нужны для «общения» пользователя и сайта. Они по сути практически являются противоположностью друг друга. Использование тех или иных видов запросов зависит от конкретной ситуации и пользоваться только одним видом запроса крайне неудобно.
