Чем отличаются get и post запросы

Чем отличается POST от GET

Если вы занимались какой-либо веб-разработкой, вы, должно быть, встречали эти два термина GET & POST. Эти термины вводятся в отношении тега формы. Объяснение было таким:

«В теге формы есть атрибут, называемый методом. Здесь вы можете указать, каким образом вы хотите отправлять данные на серверную часть. У этого атрибута есть два значения: GET и POST».

GET: если вы используете этот метод, то данные, которые вы записали в форме, будут добавлены к URL-адресу и будут отправлены. Поскольку вводимые пользователем данные чётко видны в URL-адресе, этот метод небезопасен, и существует ограничение на то, что вы можете отправить, и сколько вы можете отправить.

POST: если вы используете POST, данные будут отправлены в теле HTTP-запроса. Его не будет видно в URL-адресе. Нет ограничений на объём отправляемых данных. POST также поддерживает отправку любых данных.

Чем отличается POST от GET

GET: вот код формы GET.

Как и ожидалось, значения параметров появились в URL-адресе. Но если мы воспользуемся инструментом проверки хрома для более подробного анализа, мы сможем увидеть значения, которые представлены в разделе «Параметры строки запроса».

POST: вот код формы POST. Если вы заметили, она идентична нашей форме GET, за исключением значения атрибута method.

Данные отправлены. Но теперь, если мы проверим его с помощью инструментов Chrome, параметры появятся в разделе «Данные формы». GET и POST относятся к семейству HTTP-методов (отсюда и произошло название метода атрибута). Некоторые из методов HTTP: GET, PUT, POST, DELETE, HEAD, PATCH, OPTIONS, TRACE и т.д.

Все они служат нескольким целям протокола HTTP. В этой статье мы в основном сосредоточимся на первых четырёх.

CRUD-операции

Если вы работаете с базами данных, вы, должно быть, встречали эти термины. С точки зрения непрофессионала, я могу объяснить CRUD как базовую функциональность, которая должна предоставляться конечным пользователям через API, чтобы иметь возможность правильно использовать любую систему управления базами данных (в контексте веб-разработки это будет СУБД, которую вы используете вместе со своим сервером. код, скажем MySql, Hibernate и т. д.). CRUD означает CREATE, READ, UPDATE и DELETE. Четыре метода HTTP, как я упоминал ранее, соответствуют одной из этих операций.

Вставить в TABLENAME ЗНАЧЕНИЯ (value1_for_column1, value2_for_column2…);

ВЫБРАТЬ * из ГДЕ столбецX = значениеX И столбецY> значениеY…;

HTTP-метод, соответствующий этой операции, — GET. Попробуйте сравнить это с URL-адресом, сгенерированным после запроса GET, то есть с частью после ’?’ отметьте в URL-адресе выражение после предложения WHERE. Они оба очень похожи, не так ли?

Теперь, если вы подумаете о результатах, которые у нас были ранее, это имеет гораздо больше смысла. Для GET тело запроса было пустым, а значения находились в параметре строки запроса. Поскольку поля формы обрабатывались как параметр запроса, запрашиваемого по URL-адресу «localhost / target.php».

В методе POST данные, введённые в форму, шли вместе с телом запроса. Так оно и появилось в разделе Form Data. Он обрабатывается как некоторые данные, которые пользователь хочет отправить, а не как параметры запроса.

GET и POST: теперь давайте немного вернёмся и подумаем с точки зрения разработчика протокола HTTP. Мы знаем, что GET разработан для использования в случаях, когда пользователь запрашивает список записей. Поля, по которым пользователь выполняет поиск, обычно очень маленькие и текстовые. Таким образом, для запроса GET нет необходимости разрешать что-либо, кроме текстов и всего, что превышает 30 КБ. Скорее, если мы сохраним небольшой размер, задержка обработки будет уменьшена.
Теперь, имея в виду эти вещи, попробуйте подумать о некоторых приложениях, которые вы используете ежедневно, где, по вашему мнению, используется GET. Да! Поисковые системы. Теперь откройте поисковик и попробуйте что-нибудь поискать. Обратите внимание на появившийся URL.

Давайте снова подумаем о разработчиках HTTP. Посредством POST пользователь будет создавать новые записи, для которых потребуется передать большой объём данных. Такой объём данных не может быть передан через URL-адрес, поэтому лучше отправлять их как HTTP-пакеты. Более того, запись может содержать некоторые личные данные, поэтому метод POST должен быть безопасным. Следовательно, POST используется с формами, которые имеют дело с пользовательскими данными (например, с формами Google, когда вы создаёте новую учётную запись на GfG).

С тех пор как я говорил о создании учётной записи, вы можете спросить: «А как насчёт входа в систему? Там никаких новых рекордов не создаётся! Тогда почему GET там не используется?» Хотя можно просто отбросить этот вопрос, сказав, что GET небезопасен, мы не используем его для входа в систему. Но давайте подумаем об этом в контексте, который мы обсуждали до сих пор. При входе в систему вы на самом деле не запрашиваете / не ищете свою запись. Давайте рассмотрим логин с точки зрения поиска. Затем вы передаёте имя пользователя и пароль и спрашиваете систему, есть ли какая-либо учётная запись с этими учётными данными. Это будет очень неправильно. Когда мы авторизуемся, мы запрашиваем у системы разрешение на взаимодействие с нашими данными. По аналогии с банком login будет просить менеджера предоставить нам ключ, который откроет наш шкафчик, во время поиска будет спрашивать, есть ли у человека X шкафчик в этом банке или нет, что опять же очень неправильно и сводит на нет всю цель конфиденциальности. Итак, если вы поставите правильную подпись, менеджер предоставит вам ключ, который откроет шкафчик. В веб-разработке сервер предоставит вам sessionId.

Подведём итоги. При входе в систему, если учётные данные верны, серверная часть создаст для вас сеанс и предоставит идентификатор сеанса. Теперь, используя sessionId, вы можете искать свои данные. Итак, POST подходит для этой ситуации. И, войдя в систему, вы можете использовать запросы GET для извлечения данных.

Заключение

Подводя итог, GET используется для чтения / доступа к некоторым ресурсам, а POST используется для его создания. Я бы посоветовал вам не ограничивать себя мыслительным ресурсом по отношению к СУБД, а подумать об этом в более широком смысле. Ресурс может быть любым, начиная от строки в базе данных и заканчивая файлами, такими как изображения или текст, а иногда даже полными HTML-страницами. Если вы хотите читать / искать ресурс, используйте GET, а если вы хотите создать / добавить / загрузить ресурс, используйте POST.

Источник

Блог Vaden Pro

GET или POST? – вот в чем вопрос!

В последнее время в сложившейся практике разработки сайтов наибольшую популярность получили два типа HTTP запросов: GET и POST. Казалось бы ничего сложного в этих двух понятиях нет, но начинающие и неопытные веб-разработчики очень часто допускают непростительные ошибки при выборе определенного метода. Главным образом это происходит по той причине, что эти 2 разные пути могут привести к одному и тому же результату. Ценой неправильного выбора типа запроса может быть угроза безопасности ресурса или информационная перегрузка сервера.

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

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

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

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

Теперь стоит разъяснить суть каждого из методов. Безопасными называются те запросы, которые не имеют никакого влияния на ресурс, они просто запрашивают и помогают считывать информацию. Примером такого запроса является отображение картинки – через ее адрес идет запрос на сервер в указанную директиву, где должен находится файл с картинкой. Такой тип запроса распространяется на методы HEAD и GET.

На заметку

Безопасный метод – это еще не гарантия отсутствия проблем. Ущерб может нанести зацикливание определенного типа запроса, даже если он и безопасный.

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

Идемпотентные методы

Это сложное для восприятия и произношения понятие означает способность некоторых из методов предоставлять одни и те же данные при многочисленных запросах. Та ситуация, когда информация была обновлена, во внимание не берется. Изъясняясь более понятно, это тот случай, когда при запросе файла по одному и тому же адресу будет выводиться постоянно одна и та же информация (например, картинка). Такая способность присуща GET, PUT, DELETE методам.

На этом будем завершать анализ методов. Теперь вы можете убедиться в том, что не совсем POST похож на GET. Поэтому при выборе метода в первую очередь следует проанализировать поставленные цели для ресурса, а затем, исходя из принятых решений, делать выбор. Да, стоит отметить, что по умолчанию работает метод GET.

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

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

Источник

Типы HTTP-запросов и философия REST

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

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

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

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

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

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

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

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

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

Первая строка — это строка запроса, остальные — заголовки; тело сообщения отсутствует

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

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

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

В игру вступает 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 запросы

HTTP определяет множество методов запроса, которые указывают, какое желаемое действие выполнится для данного ресурса. Несмотря на то, что их названия могут быть существительными, эти методы запроса иногда называются HTTP глаголами.

CRUD — (англ. create read update delete — «Создание чтение обновление удаление») сокращённое именование 4 базовых функций при работе с персистентными хранилищами данных — создание, чтение, редактирование и удаление.

Каждый реализует свою семантику, но каждая группа команд разделяет общие свойства: так, методы могут быть безопасными (не изменяют состояния сервера – GET, HEAD, OPTIONS), идемпотентными (возвращают один и тот же результат на идентичный запрос – GET, HEAD, PUT, DELETE) или кэшируемыми.

Методы HTTP запроса:

POST запрос.

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

Отличие GET от POST

GET отсылает запрос на получение данных, POST отправляет данные. GET. Добавляется в закладки. Кэшируется. История остается в закладках браузера. Есть ограничения по по символам, так как данные передаются в URL, то должен ограничиваться в 2048 символах (мах строка символов в URL). По типу данных допускается использование только символов ASCII. Менее безопасный, так как передоваемые в URL данные, видны пользователю. Данные в URL доступны всем.

Разница между PUT и POST

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

Все безопасные методы являются также идемпотентными, как и некоторые другие, но при этом небезопасные, такие как PUT или DELETE.

Структура HTTP запроса:

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

Зачем нужны Header?

Для того чтобы компьютер мог понимать с каким ресурсом работать:

Заголовок-сущность Content-Type используется для того, чтобы определить MIME тип ресурса.
MIME тип:

Content-Type (text/html; charset=utf-8)

Клиент может установить Accept в application/json, если он запрашивает ответ в JSON.

И наоборот, когда отправляются данные, установленный Content-Type в application/xml говорит клиенту, что данные были отправлены в XML форме.

Источник

Руководство по выбору между GET и POST

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

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

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

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

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

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

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

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

Просто примите к сведению то, что 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.

Выбирая между этими двумя методами необходимо иметь некоторое чутье и я думаю следующая схема поможет Вам в этом выборе:

Источник