Отличия GET от POST?

Question

[panem_alba]

На собеседовании был вопрос "в чем отличие http запроса GET от POST?". Являясь не особо опытным разработчиком, ответил в двух словах, что GET - "открытый" запрос, который отображается в ссылке сайта и используется обычно во всяких фильтрах сайта, а POST - "скрытый" запрос, который никак не отображается визуально и используется для отправки данных с форм и всякого такого.

На что мне ответили "Боюсь вас разочаровать, но это не так. Я могу написать ссылку вида site/?page=2 и отправить её через POST. Так что скажите нам какие есть еще отличия?".

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

Есть ли какая-то информация на этот счёт? И каким образом ссылку site/?page=2 можно отправить методом POST?

Comments

[panem_alba]

А ты, видимо, даже не пытался вопрос до конца прочитать :)

[panem_alba]

Dr. Bacon, какой ты полезный прям. Спасибо большое. С таким успехом можно было и в принципе в этом вопросе не отмечаться

[Евгений Залецкий]

Dr. Bacon, просто человек не понял вопрос собеседника и думает что есть ещё правильный ответ.

Answer 1

[Nik Faraday]

UPD: пример ниже приведён для MVC архитектуры. API выдаёт данные, а не страницы. HttpGet - это получение информации от сервера. HttpPost - отправка информации на сервер. Основная разница в тому, что Post запрос имеет тело запроса, в котором можно передавать сложные структуры. Get запрос может передавать данные через строку запроса

HttpGet и HttpPost это два стандартных типа запроса. Так же есть HttpPut, HttpDelete и некоторые другие, основные из каких я перечислил сначала.

Разница между HttpGet и HttpPost в очень простом виде:
HttpGet - выдача сервером какой-то информации клиенту. Для примера, сервер отдаёт какую-то информацию, допустим, имя и логин пользователя, который зашёл на сайт, для того, что бы отобразить её где-то на странице. Так же Get запрос может отдавать целые страницы в формате HTML или других форматах. По факту, большинство страниц, что вы видите в браузере, включая эту, была передана нам в браузер от сервера путём выполнения запроса. Такая информация передаётся как HttpGet.

HttpPost - это отправка данных на сервер. Любая. Когда вы регистрируетесь на сайте, ваши данные отправляются с использованием HttpPost запроса. Когда вы делаете изменения личной информации, обновлённые данные отправляются как HttpPost, хотя в REST API принято такой запрос помечать как HttpPut. Тут речь идёт об отправке сложных структур данных, возможно, фотографий, видео, аудио, информации о местонахождении, контактные данные. Т.е., другими словами, когда вы сервер уведомляете о какой-то новой информации.

Стоит отметить, что редирект через url является HttpGet запросом. Если вы просто делаете переадресацию на какую-то страницу и в url передаёте id клиента (Для примера), что бы на странице сведений вывести его данные (Опять же, чисто для примера), это НЕ HttpPost запрос, это просто редирект. Потому что вы не обновляете никакую информацию. Когда вы обращаетесь к серверу с просьбой отрисовать/отрендрить страницу и передаёте туда id клиента, сервер отдаёт ответ на HttpGet запрос, который имеет разметку самой страницы.

Иными словами, HttpGet запрос, это то, когда сервер должен отрисовать новую разметку или вернуть какие-то данные в некотором формате (В основном JSON для API). Может выполняться несколько запросов, если вы во время регистрации на сайте отправляете данные, делается сначала HttpPost запрос с отправкой ваших данных, а потом HttpGet, когда у вас рендрится новая страница, на которую вас перекинуло.

Так же есть HttpPut - аналогия HttpPost, разницы нет почти никакой. Обычно используется для обозначения запроса на обновление информации, т.к. HttpPost должен работать как запрос на создание. Тот же пример HttpDelete - когда нужно удалить информацию.

Comments

[panem_alba]

Спасибо большое

[Dmitry Roo]

У меня вопрос: можно ли методом GET передать информацию на сервер?
И второй сразу: можно ли с помощью метода POST получить информацию с сервера?

[Nik Faraday]

Dmitry Roo, технически, когда вы делаете Get запрос на сервер с просьбой рендринга какой-то страницы, вы можете так же передать туда ещё, допусти, id клиента, что бы на странице вывести информацию клиента.
Post запрос может получить информацию из сервера асинхронным респонсом, для примера, если вы используете ajax для отправки данных в асинхронном порядке и получаете в блоке error какой-то ответ от сервера. Технически, get запроса тут не происходит, а возвращается json объект на Post запрос. С помочью таких ответов на Post запросы обычно передаётся сообщение об ошибки валидации моделей и т.д.

[Dmitry Roo]

Nik Faraday, а если не асинхронным, будет работать?
И, получается, что метод get тоже может передавать данные на сервер? В чем тогда отличие от post?

[AUser0]

Dmitry Roo, GET передаёт данные в самом URL. POST передаёт данные как в URL, так и внутри тела запроса. С помощью ссылки на HTML-странице POST запрос не выполнить. Речь конечно о стандартных средствах, например без использования Javascript и браузерных плагинов.

[DevMan]

Это дичь, а не ответ.

[Dmitry Roo]

AUser0, расскажите, пожалуйста, подробнее о «стандартных средствах»? Что вы имеете ввиду?

[AUser0]

Dmitry Roo, стандартные средства - это WEB-браузер и банальная HREF ссылка.

[Araya]

AUser0, а curl - это не стандартное средство?

[AUser0]

Araya, curl - очень стандартное.

[VikiFaraday]

Дякую, дуже доступно все розписано))

Answer 2

[Василий Банников]

Два главных отличия:
1. У GET-запроса нет тела (как правило, но в теории никто не запрещает отправить с телом).
А у POST как правило нет query-параметров, но в принципе никто не запрещает одновременно указать и их, и тело
2. GET-идемпотентный, в отличие от POST.
Если ты отправишь два одинаковых идемпотентных запроса, то ничего не изменится-это безопасно.
И этим свойством пользуются браузеры и всякие прокси, которые в случае каких-то сетевых ошибок тихо отправляют идемпотентные запросы повторно.

Кроме GET есть ещё PUT и DELETE, которые тоже идемпотентные

Есть ли какая-то информация на этот счёт?

Всё это описано в википедии в статье об HTTP

И каким образом ссылку site/?page=2 можно отправить методом POST?

Через curl или через форму

Comments

[Dmitry Roo]

Я бы не говорил, что GET прям идемпотентный. Скорее, это рекомендация к реализации, в т.ч. в связи с таким поведением браузеров.

[Василий Банников]

Dmitry Roo, ну его очень рекомендуют делать идемпотентным.
Рекомендация прям на уровне спецификации

Можно пример ситуации, когда он на самом деле не идемпотентный?

[Dmitry Roo]

Василий Банников, ну вот, например, делаем два запроса get, допустим /get/user. Между ними данные пользователя изменятся, по какому-то бизнес-процессу. Получается, в первый раз какие-то одни данные прилетают, а второй - уже другие.

[Vamp]

Василий Банников, частенько вижу кнопки выхода из аккаунта в таком виде:
<a href="/logout">выйти</a>
Такая ссылка не идемпотентна.

[Василий Банников]

Vamp, вариант с /logout кстати идемпотентный и спецификацию не нарушает.
После первого нажатия ты выходишь из аккаунта.
После десятого - ты точно также остаёшься разлогиненный.
Но это говнокод, так как некоторые браузеры могут, в теории, ещё и перезагружать данные по ссылкам, предполагая, что они нормальные.

[Василий Банников]

Dmitry Roo, можно пример, какие данные могут так меняться, чтобы использование GET было оправданным?

[Dmitry Roo]

Василий Банников, не понял вопроса.
imho, это все условности и рекомендации. На стороне сервера любой запрос может быть реализован любым способом.

Ваши аргументы насчёт примера с пользователем мне тоже интересно почитать.

[Владимир Коротенко]

Василий Банников, ссылка на скачивание файла инсталлятора. Используется да практически везде.
подтверждающие ссылки на почту для входа.
Разные онлайн конверторы форматов картинок

upd
hotlink ловушки

[Владимир Коротенко]

Василий Банников, а какой нибудь умник вставит картинку с этим адресом

[Василий Банников]

Владимир Коротенко, ссылка на скачивание даже по смыслу должна быть get.

Ссылки с подтверждением - это нормально, но и там достаточно часто добавляют интерактивный элемент

[Владимир Коротенко]

Василий Банников, но их поведение меняется в зависимости от условий, хотя адрес тот же.

[ThunderCat]

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

[Василий Банников]

ThunderCat, а что такого с куками и заголовками?
Может вы один из тех людей, кто считает, что Query в CQRS не могут писать логи?

[Vitsliputsli]

Dmitry Roo,

ну вот, например, делаем два запроса get, допустим /get/user. Между ними данные пользователя изменятся, по какому-то бизнес-процессу. Получается, в первый раз какие-то одни данные прилетают, а второй - уже другие.

Все же, под идемпотентностью подразумевается каким образом запрос изменяет сущности, а не что-то там еще в фоне это делает. Про get даже никто не говорит, что он идемпотентный, потому что он не изменяет сущности.
delete идемпотентен, и не важно, что при последующих вызовах на несуществующую сущность, он пришлет в ответ что-то иное, важно что при любом кол-ве запросов сущность получила одно конкретное состояние. Т.е. такое же поведение как описал Василий Банников для logout.
А по логике описанной в цитате, ни один запрос не будет идемпотентным, если вы в фоне будете менять данные.

[ThunderCat]

Василий Банников,

а что такого с куками и заголовками?

С ними все ок, но они могут влиять на логику сервера, и по тому не всегда идемпотентны.

[Василий Банников]

ThunderCat, можно пример кейса, когда отправка двух гетов подряд может привести к нежелательному поведению, но при этом не будет говнокодом?
+10 баллов, если это будет не выдуманный пример, а ссылка на документацию к какому-нибудь популярному сервису

[ThunderCat]

Василий Банников,

привести к нежелательному поведению, но при этом не будет говнокодом?

А нежелательное поведение это не всегда говнокод? Мы же говорим про предсказуемое, но не идемпотентное поведение, что не совсем одно и то же. Например - протухшая сессия.

+10 баллов, если это будет не выдуманный пример, а ссылка на документацию к какому-нибудь популярному сервису

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

[Василий Банников]

ThunderCat, но это в принципе нормально запрос всё ещё идемпотентный

Answer 3

[stas1212]

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

В реальном мире тот же самый Post очень часто используется для получения информации сервера ,а не для записи,происходит это тогда,когда в теле запроса нужно передать какой то объект( например какой то сложный фильтр) и выбирают меньшее из зол - Get с телом хуже чем идемпотентый Post- но если стоит прокси - в случае неудачи такой пост запрос не будет повторен

Суммируя - есть некая договоренность ,желательно ее соблюдать - но если нет - ничего не случится ))

Answer 4

[Сергей Соколов]

Общение веб-браузера c сервером по протоколу HTTP напоминает обычный текстовый чат. Никакой магии.

Браузер устанавливает соединение с сервером и пишет ему текстом, как будто, «Привет, как дела».
Веб сервер в ответ что-то возвращает, типа «Ничего так, пойдёт».

Настоящий диалог строго регламентирован протоколом. Первая строчка, которую должен прислать браузер содержит название метода, адрес и версию протокола:GET /about/index.html HTTP/1.1

Ну, или POST /guestbook HTTP/1.1. Или ещё какой-то из методов и адресов.

Вы можете подключиться к веб-серверу обычным telnet'ом по 80-му порту, если найдёте веб-сервер, позволяющий подключаться без SSL (без https://), и попробовать вообще вручную вводить все эти строки, изображая браузер.

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

Answer 5

[Vitsliputsli]

"Боюсь вас разочаровать, но это не так. Я могу написать ссылку вида site/?page=2 и отправить её через POST. Так что скажите нам какие есть еще отличия?".

Вы не найдете правильный ответ. Если бы собеседующий хотел проверить ваши знания, он бы уточнял вопрос, показывая о чем конкретно он хочет спросить. Но больше похоже на игру "я вот знаю, а ты нет". Нормальный человек обычно объяснит, что он имел ввиду.
Потому что, на такое замечание можно ответить только, что сделать можно что угодно, можно хоть вместо метода GET использовать метод в виде неприличного слова. А если его будут знать и клиент и сервер, то все будет отлично работать.
Поэтому это вопрос больше про договоренности, а если вопрошающий заявляет что ему пофиг на них, то угадать что для него важно, а что нет - очень сложно.
Например, avivasyuta вспомнил еще один интересный момент - кеширование браузером. Кто знает, может быть имелось ввиду оно, но и это ведь тоже договоренности.

Comments

[Vitsliputsli]

m0ze, "перенять инициативу" - это больше про умение собеседоваться, а не про знания в вопросе. "Размытые" вопросы это не про собеседование, это про желание покрасоваться. И тем более, когда речь про неопытного разработчика. Коммуникации вообще вещь сложная, люди очень часто неправильно понимают друг друга, поэтому попытка наводить "тень на плетень" нисколько не поможет определить знания собеседуемого, разве что поможет "загнать" его, он перестанет понимать, что от него хотят и будет тупить. Опытный человек просто послал бы на хер такого "специалиста", а вот неопытный исходит из того, что собеседующий понимает, что он делает, и не допускает мысли, что он просто идиот.
И хотя ответ автора не выглядит очень профессионально, он вполне правильный с определенной точки зрения. А то, что "я могу написать ссылку вида site/?page=2 и отправить её через POST", нисколько не помогает в том, что хочет услышать собеседующий. Ну разве что, можно ответить, что с таким подходом отличий нет вовсе, после этого собеседующий молча сделает выводы и будет до конца своих дней считать, что он крутой специалист, а на собеседования приходят бестолковые.

[Vitsliputsli]

m0ze, без разницы, умение себя продать - отличный навык, но к профессиональным знаниям и навыкам не имеет отношения. Вы пишите про так называемое "агрессивное" собеседование, когда собеседуемому показывают, что он говно, а компания что-то недосигаемо божественное. Я сужу субъективно, но в IT это не распространено, сам сталкивался только 1 раз, такое могут практиковать менеджеры, но собеседуют разработчиков как правило технические специалисты, а они таким не страдают, хотя страдают другим, что описал выше. Да и при дефиците IT кадров, это провальная тактика, даже джун пройдет несколько собеседований, и не выберет компанию, где его будут прогинать. И исходя из того же дефицита, нужно понимать, что не только собеседуемый может провалить собеседование, но и интервьюер, это не так очевидно бывает, но в конечном итоге компания просто уронит квалификацию своих кадров.

[Vitsliputsli]

m0ze, любое мнение субъективно, о чем я прямо и написал, почему же вы считаете, что только ваша картина мира единственно правильная? По собеседованиям ходил не мало, HR проводят собеседование по общей адекватности, на наличие навыков, которые сам соискатель заявляет, могут делать опросы по заготовленным техническим вопросам, но если у вас HR проводит техническое собеседование, стоит ли его проходить?

[Vitsliputsli]

m0ze,

А я вот так прямо и считаю, да? Забавно такое читать, когда у вас изначально ответом было "нет, вы не знаете, сейчас я расскажу", а в качестве отступных добавили "я сужу субъективно".

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

И продолжение пассивной агрессии. В общем, всё как по нотам.

"Пассивная агрессия" в чем она тут? Что я рассмотрел и ваш вариант? Класс, это вы мне заявляете "нет, вы не знаете, сейчас я расскажу", a когда я соглашаюсь что возможен и ваш вариант, вы начинаете кидаться обвинениями, и уходить от ответа.

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

[Vitsliputsli]

m0ze, ну так по делу, есть что? или по прежнему будете цепляться за слова, и заявлять, что раз нет тупых приписок, я не имею права на мнение?
Обязательно агрессия, раз вам хочется позадираться, то ответ должен быть соответствующим. Забавно то, что мое признание чужого опыта вам показалось пассивной агрессией, похоже вы все так и рассматриваете с точки агрессии, что она вам везде мерещится. Все проходят эту стадию, "есть мое мнение и неправильное" и начинают агрессировать, если кто-то вдруг осмелился иметь отличное мнение. Обычно с возрастом это проходит, но кто-то "застревает" на этом этапе.
Так по делу чтонибудь ответите? Пока вы только цепляетесь к моим словам, подчеркивая что оно неправильное, потому что не ваше. А заявлять, что я не рассматриваю другие точки зрения, на основании того, что я согласился с вашей - это уже клиника.

[Vitsliputsli]

m0ze, что родить? :-D Не говоря уже о том, что ты припсываешь словам свой противоположный смысл, да еще и пытаешься меня в этом убедить. Ты думал только в offline тебя могут на место поставить? Ты же обычный пустобрех, что уже hr определяют и не пропускают дальше, повзрослей и найдешь нормальную работу.

Answer 6

[bro-dev]

Первым словом в первой строчке запроса, а остальные отличия это детали конкретных реализаций.

Answer 7

[Довольный Айтишникъ]

Первая же ссылка из гугла всё прекрасно описывает
https://htmlacademy.ru/blog/best/get-vs-post

Answer 8

[avivasyuta]

Дополню, что GET запросы кешируются. POST - нет