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

@panem_alba

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

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

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

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


Решения вопроса 1

@NikFaraday

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

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

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

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

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

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

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

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

Другие ответы на вопрос:

@vabka

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

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

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

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

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

@xez
vabka, Я бы не говорил, что GET прям идемпотентный. Скорее, это рекомендация к реализации, в т.ч. в связи с таким поведением браузеров.
@vabka
xez, ну его очень рекомендуют делать идемпотентным.
Рекомендация прям на уровне спецификации.
Можно пример ситуации, когда он на самом деле не идемпотентный?
@xez
vabka, ну вот, например, делаем два запроса get, допустим /get/user. Между ними данные пользователя изменятся, по какому-то бизнес-процессу. Получается, в первый раз какие-то одни данные прилетают, а второй — уже другие.

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

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

@Vitsliputsli
xez, цитирую:

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

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

@stas1212

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

@borisdenis

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

@sergiks

Общение веб-браузера c сервером по протоколу HTTP напоминает обычный текстовый чат. Никакой магии.Браузер устанавливает соединение с сервером и пишет ему текстом, как будто, «Привет, как дела».
Веб сервер в ответ что-то возвращает, типа «Ничего так, пойдёт».Настоящий диалог строго регламентирован протоколом. Первая строчка, которую должен прислать браузер содержит название метода, адрес и версию протокола:GET /about/index.html HTTP/1.1Ну, или POST /guestbook HTTP/1.1. Или ещё какой-то из методов и адресов.Вы можете подключиться к веб-серверу обычным telnet’ом по 80-му порту, если найдёте веб-сервер, позволяющий подключаться без SSL (без https://), и попробовать вообще вручную вводить все эти строки, изображая браузер.Таким образом, различие методов GET и POST — целиком зависит от веб-сервера. Существует стандарт, описывающий все ньюансы. Рекомендации, которых лучше придерживаться. Но в конечном счёте это всего лишь чат )

@avivasyuta

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

@Vitsliputsli

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

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

@m0ze
Vitsliputsli, так это собеседование было, и, вроде, логично, что интервьюируемого проверяют в т.ч. и такими «размытыми» вопросами. И тут уже с ходу становится ясно, что кандидат в вопросе, мягко говоря, плавает.
Ловушка в том, что @panem_alba попытался играть на их поле по их правилам, а мог бы перенять инициативу уточняющими вопросами. Правда, для этого нужно как раз разбираться в вопросе, иначе себя можно в тупик загнать ещё сильнее. Но в целом, именно это и выявляется в процессе интервью.

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

@m0ze
Vitsliputsli, цитирую:

«перенять инициативу» — это больше про умение собеседоваться, а не про знания в вопросе.

Без знания вопроса это будет пустой трёп, который опытный HR заметит за километр.

«Размытые» вопросы это не про собеседование, это про желание покрасоваться. И тем более, когда речь про неопытного разработчика.

Как раз и про собеседование, только никто не говорит об идеальном собеседовании, а на практике они именно такие, когда кандидата выводят из зоны комфорта и «покупают» за гроши, что в большинстве случаев и происходит с джунами. Странно было бы этому удивляться.

разве что поможет «загнать» его, он перестанет понимать, что от него хотят и будет тупить

Это и есть цель в подавляющем числе таких собеседований. Заметьте, и в случае с автором вопроса тоже прокатило.

И хотя ответ автора не выглядит очень профессионально, он вполне правильный с определенной точки зрения.

С «определённой точки зрения» всё может показаться правильным в той или иной степени, но суть в том, что этот вопрос на собеседовании интервьюируемый провалил. Да и судя по постановке вопроса тут, знания по данной теме у него отсутствуют, равно как и навык добывать нужную информацию самостоятельно.

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

@xPomaHx

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *