Когда вы используете POST и когда вы используете GET?

344

Из того, что я могу собрать, есть три категории:

  1. Никогда не используйте GETи не используйтеPOST
  2. Никогда не используйте POSTи не используйтеGET
  3. Неважно, какой вы используете.

Правильно ли я предположил эти три случая? Если да, то каковы примеры из каждого случая?

Томас Оуэнс
источник
1
Это на самом деле абсолютно не соответствует действительности. GET и POST оба видны в одинаковой степени, если вы посмотрите заголовки, отправленные вашим браузером, вы увидите список пар «ключ-значение», которые вы
публикуете
1
Не существует стандартного способа кодировать больше, чем имя -> пары значений в строки запроса, поэтому, если ваши запросы не являются очень простыми (т.е. нет массивов или вложенных структур данных), вам следует учитывать только POST, который предоставляет поле тела, которое можно использовать с форматами кодирования (JSON, XML и т. Д.).
Фесихай

Ответы:

377

Используйте POSTдля разрушительных действий, таких как создание (я знаю об иронии), редактирование и удаление, потому что вы не можете нажать на POSTдействие в адресной строке вашего браузера. Используйте, GETкогда это безопасно, чтобы позволить человеку вызвать действие. Таким образом, URL-адрес, как:

http://myblog.org/admin/posts/delete/357

Должен привести вас на страницу подтверждения, а не просто удалить элемент. Так проще избежать несчастных случаев.

POSTтакже более безопасен, чем GET, потому что вы не вставляете информацию в URL. И так , используя GETкак methodдля HTML формы, собирающий пароль или другую конфиденциальную информацию , не самая лучшая идея.

Последнее замечание: POSTможет передавать большее количество информации, чем GET. «POST» не имеет ограничений по размеру для передаваемых данных, в то время как «GET» ограничен 2048 символами.

Брайан Варшоу
источник
83
Ответы на запросы GET могут быть привязаны. Ответы на посты не должны.
mkoeller
31
Как размещение информации в URL не делает ее более безопасной? (Кстати, я один из тех, кто считает, что ложное чувство безопасности более опасно, чем отсутствие безопасности вообще).
ePharaoh
42
@ePharaoh: Он останавливает людей, читающих пароли, глядя через плечо пользователя на адресную строку.
Квентин
35
@ePharaoh: «Предоставление немного меньшего количества данных случайному наблюдателю» было бы, вероятно, лучшей формулировкой, чем «более безопасный» - URL-адреса могут оказаться во многих местах, таких как журналы, рефереры, кэши. Вы, конечно, правы, это не повышает безопасность - но оно ограничивает самые опасные практики (см. Также: thedailywtf.com/Articles/The_Spider_of_Doom.aspx )
Писквор покинул здание
24
@ Дэвид Дорвард: Или его более распространенное название: атака плечом
Идан К
206

Вкратце

  • Использовать GETдля safe andidempotentзапросов
  • Использовать POSTдля neither safe nor idempotentзапросов

В деталях есть подходящее место для каждого. Даже если вы не следуете принципам RESTful , многое можно узнать, узнав о REST и о том, как работает подход, ориентированный на ресурсы.

RESTful приложение будет use GETsдля операций, которые оба safe and idempotent.

safeОперация представляет собой операцию , которая делает not change the dataзапрашивается.

idempotentОперация, в которой результат будет be the sameне важно , сколько раз вы спрашиваете его.

Само собой разумеется, что, поскольку GET используются для безопасных операций, они автоматически также становятся идемпотентными . Обычно GET используется для извлечения ресурса (например, вопроса и связанных с ним ответов о переполнении стека) или сбора ресурсов.

Приложение RESTful будет использовать PUTsдля операций, которые not safe but idempotent.

Я знаю, что вопрос был о GET и POST, но я вернусь к POST через секунду.

Обычно PUT используется для редактирования ресурса (например, для редактирования вопроса или ответа о переполнении стека).

A POSTбудет использоваться для любой операции, которая есть neither safe or idempotent.

Обычно POST используется для создания нового ресурса, например, для создания НОВОГО вопроса SO (хотя в некоторых проектах PUT также будет использоваться для этого).

Если вы запустите POST дважды, вы получите ДВА новых вопроса.

Также есть операция DELETE, но я думаю, я могу оставить это там :)

обсуждение

С практической точки зрения современные веб-браузеры, как правило, надежно поддерживают только GET и POST (вы можете выполнять все эти операции с помощью вызовов javascript, но с точки зрения ввода данных в формы и нажатия кнопки отправки вы обычно получаете две опции). В приложении RESTful POST часто переопределяется, чтобы обеспечить вызовы PUT и DELETE.

Но даже если вы не следуете принципам RESTful, полезно подумать об использовании GET для получения / просмотра информации и POST для создания / редактирования информации.

Вы никогда не должны использовать GET для операции, которая изменяет данные. Если поисковая система сканирует ссылку на ваш злой оператор или закладка клиента, это может привести к большим проблемам.

reefnet_alex
источник
если вы создадите ресурс APIREST для входа в систему, который вы выберете, это безопасно и идемпотентно, я его приглашаю.
Джонни Лопес
1
Безопасное получение не является автоматически идемпотентом. Набор результатов может отличаться при одном и том же неразрушающем запросе.
RichieHH
1
То, как вы это написали, что-то вроде «GET currenttime» будет неправильным, потому что оно не идемпотентно (в том смысле, что повторные запросы могут давать разные результаты); на самом деле все, что запрашивается, может со временем измениться. Поэтому следует выражать идемпотентность скорее в терминах побочных эффектов самого запроса . Поскольку просто запрос текущего времени не имеет побочных эффектов , это - как и следовало ожидать - идеальный кандидат на GET, а не POST.
Хаген фон Айцен
79

Используйте GET, если вы не возражаете против повторения запроса (то есть он не меняет состояние).

Используйте POST, если операция изменяет состояние системы.

Дуглас Лидер
источник
1
Поскольку форма изменяет состояние системы, почему по умолчанию для тега HTML-формы используется метод GET?
ziiweb
3
@ user248959 Меняет ли окно поиска видимое состояние? Значение по умолчанию было установлено давно, вероятно, почти случайно. Я не углубился в историю, чтобы даже знать, был ли POST опцией, а формы были опцией.
Дуглас Лидер
@ziiweb Даже если в большинстве случаев <form> используется POST, лучше определить dafault как «безвредный» GET. Это может показаться абсурдным с точки зрения безопасности, когда приводит к раскрытию данных в файлах журналов и т. Д., Но это отказоустойчиво в отношении данных на стороне сервера (серверу не следует изменять данные при GET). Полагаю, сегодня можно было бы по-другому установить фокус (желательно, если бы мы отказались от любого дефолта и сделали methodобязательным)
Хаген фон Айцен
Предположим, у меня есть конечная точка, которая принимает файл в качестве входных данных, выполняет некоторую обработку файла (пример - извлечение данных на основе регулярных выражений) и возвращает данные JSON, а затем я могу использовать GET-запрос для загрузки файла на сервер. Или я должен использовать запрос POST?
переменная
67

Укороченная версия

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

Преимущества GET:

  • URL можно безопасно добавить в закладки.
  • Страницы могут быть перезагружены безопасно.

Недостатки GET:

  • Переменные передаются через URL как пары имя-значение. (Риск безопасности)
  • Ограниченное количество переменных, которые могут быть переданы. (На основе браузера. Например, Internet Explorer ограничен 2048 символами. )

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

Преимущества POST:

  • Пары имя-значение не отображаются в URL. (Безопасность + = 1)
  • Неограниченное количество пар имя-значение может быть передано через POST. Ссылка.

Недостатки POST:

  • Страница, которая использовала данные POST, не может быть закладкой. (Если вам так хочется.)

Более длинная версия

Непосредственно из протокола передачи гипертекста - HTTP / 1.1 :

9,3 ПОЛУЧИТЬ

Метод GET означает получение любой информации (в форме объекта), идентифицируемой посредством Request-URI. Если Request-URI относится к процессу создания данных, то именно полученные данные должны быть возвращены в качестве объекта в ответе, а не исходный текст процесса, если только этот текст не является выходом процесса.

Семантика метода GET изменяется на «условное GET», если сообщение запроса включает в себя поле заголовка If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match или If-Range. Условный метод GET запрашивает, чтобы объект передавался только при обстоятельствах, описанных в поле (ах) условного заголовка. Метод условного GET предназначен для уменьшения ненужного использования сети, позволяя обновлять кэшированные объекты, не требуя многократных запросов или передачи данных, уже удерживаемых клиентом.

Семантика метода GET изменяется на «частичное GET», если сообщение запроса включает в себя поле заголовка Range. Частичное GET запрашивает, чтобы была передана только часть объекта, как описано в разделе 14.35. Метод частичного GET предназначен для уменьшения ненужного использования сети, позволяя завершить частично извлеченные объекты без передачи данных, уже хранящихся у клиента.

Ответ на запрос GET кэшируется тогда и только тогда, когда он соответствует требованиям для кэширования HTTP, описанным в разделе 13.

См. Раздел 15.1.3 для соображений безопасности при использовании для форм.

9,5 ПОСТ

Метод POST используется для запроса, чтобы исходный сервер принял объект, включенный в запрос, в качестве нового подчиненного ресурса, идентифицируемого Request-URI в строке запроса. POST разработан для того, чтобы унифицированный метод мог выполнять следующие функции:

  • Аннотация существующих ресурсов;

  • Размещение сообщения на доске объявлений, в группе новостей, в списке рассылки или аналогичной группе статей;

  • Предоставление блока данных, такого как результат отправки формы, процессу обработки данных;

  • Расширение базы данных с помощью операции добавления.

Фактическая функция, выполняемая методом POST, определяется сервером и обычно зависит от Request-URI. Размещаемая сущность подчиняется этому URI так же, как файл подчиняется каталогу, в котором он находится, новостная статья подчиняется группе новостей, в которой она размещена, или запись подчиняется базе данных.

Действие, выполняемое методом POST, может не привести к ресурсу, который может быть идентифицирован с помощью URI. В этом случае либо 200 (ОК), либо 204 (Нет содержимого) - это соответствующий статус ответа, в зависимости от того, включает ли ответ объект, который описывает результат.

Cimplicity
источник
2
«Страница, которая использовала данные поста, не может быть добавлена ​​в закладки»: ну, это преимущество, нет? Возможно, вы не хотите, чтобы ваш запрос на изменение данных был добавлен в закладки.
Писквор покинул здание
Я полагаю, что если бы каждый раз, когда использовался пост, вы использовали его в целях безопасности, это было бы преимуществом. Обычно это так, но есть ограничение на длину GET. Может быть, кто-то просто передает тонну данных, не связанных с безопасностью, и хотел бы, чтобы страница была добавлена ​​в закладки? Кто знает ...
Cimplicity
Что касается недостатка GET, а именно того, что «переменные передаются через url как пары имя-значение», MVC устранит эту проблему из-за маршрутизации и получающихся в результате дружественных URL-адресов?
MrBoJangles
@MrBoJangles: использование хороших URL-адресов не предотвращает упомянутый риск «человек смотрит через плечо». Примечание: MVC не требует маршрутизации с хорошими URL, а маршрутизация с хорошими URL не требует MVC; они иногда используются вместе, но могут также использоваться отдельно.
icktoofay
В мире .NET для всех практических целей хорошая возможность URL = MVC. Я полагаю, вы могли бы сделать некоторые переписывания IIS или некоторые странные, основанные на коде, но они еще менее приятны. Нечего и говорить, MVC для победы.
MrBoJangles
28

Первая важная вещь - значение GET против POST:

  • GET следует использовать, чтобы ... получить ... некоторую информацию с сервера,
  • в то время как POST следует использовать для отправки некоторой информации на сервер.


После этого можно отметить пару вещей:

  • Используя GET, ваши пользователи могут использовать кнопку «назад» в своем браузере, и они могут закладки страниц
  • Существует ограничение на размер параметров, которые вы можете передать как GET (2 КБ для некоторых версий Internet Explorer, если я не ошибаюсь) ; предел гораздо больше для POST и обычно зависит от конфигурации сервера.


В любом случае, я не думаю, что мы могли бы «жить» без GET: подумайте, сколько URL-адресов вы используете с параметрами в строке запроса, каждый день - без GET, все эти не будут работать ;-)

Паскаль МАРТИН
источник
Ну, если бы все использовали симпатичные URL в стиле GET: http://example.com/var1/value1/var2/value2/var3/value3мы бы «технически» больше не имели GET…
Тайлер Картер
5
@ Chacha102 За исключением того, что вы все еще должны получить этот ресурс. Почти все страницы, изображения, скрипты и т. Д. Загружаются в веб-браузеры с помощью GET.
Райан
3
@ Chacha102 - Даже www.mypage.com/contact/GET использует внутренне что-то вродеindex.php?url=/contact/
Тьяго Белем
1
Акцент на ограничение размера GET! Кроме того, параметры GET включены в закладки, а параметры POST - нет. И пользователь может обновить страницу с GET-запросом, но не страницу с POST-запросом (без предупреждения о повторной отправке информации).
Рикет
12

Помимо разницы в ограничениях длины во многих веб-браузерах, есть и семантическая разница. Предполагается, что GET являются «безопасными» в том смысле, что они предназначены только для чтения и не изменяют состояние сервера. POST, как правило, изменяют состояние и выдают предупреждения при повторной отправке. Сканеры поисковых систем могут делать GET, но никогда не должны делать POST.

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

Марк Байерс
источник
+1. Это ключевое концептуальное отличие от РФО, из которого следует все остальное. w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3
Франк Фармер,
8

Мое общее правило - использовать Get, когда вы отправляете запросы на сервер, которые не собираются изменять состояние. Сообщения зарезервированы для запросов к серверу, которые изменяют состояние.

TonyLa
источник
8

Одно практическое отличие состоит в том, что браузеры и веб-серверы имеют ограничение на количество символов, которые могут существовать в URL. Это отличается от приложения к приложению, но, безусловно, можно поразить его, если у вас естьtextarea s в ваших формах.

Еще одна ошибка с GET - они индексируются поисковыми системами и другими автоматическими системами. У Google когда-то был продукт, который предварительно выбирал ссылки на странице, которую вы просматривали, поэтому они быстрее загружались, если вы нажимали эти ссылки. Это вызвало серьезный хаос на сайтах, на которых были такие ссылки, как delete.php?id=1- люди потеряли свои сайты целиком.

ceejayoz
источник
1
Ваш веб-сервер, вероятно, также имеет ограничения на это.
Билли ОНил
Ну, есть и предел для POST.
chelmertz
1
Замечательно, @BillyONeal, я добавил это в. @Chelmertz Да, но я могу изменить это, если я хочу, и это намного выше. Например, я поместил 1 гигабайтные файлы в экземпляры Apache.
ceejayoz
Я понимаю, что URL-адреса индексируются поисковыми системами. Я не понимаю, какое это имеет отношение к GET. Я имею в виду, что URL не является просто URL?
Мед
1
Поисковые системы @Honey переходят по ссылкам. Ссылки делают GET запросы. Поисковые системы не отправляют формы (если они это сделают, вы увидите, что Google регистрирует учетную запись на вашем сайте каждые несколько дней) и, следовательно, не будут отправлять запросы POST.
Ceejayoz
7

Используйте GET, когда вы хотите, чтобы URL отражал состояние страницы. Это полезно для просмотра динамически генерируемых страниц, таких как те, что вы видите здесь. POST должен использоваться в форме для отправки данных, например, когда я нажимаю кнопку «Опубликовать свой ответ». Он также производит более чистый URL, поскольку не генерирует строку параметров после пути.

Кайл Кронин
источник
6

Поскольку GET являются чисто URL-адресами, они могут кэшироваться веб-браузером и могут лучше использоваться для таких вещей, как постоянно генерируемые изображения. (Установите время истечения)

Один пример со страницы Gravatar: http://www.gravatar.com/avatar/4c3be63a4c2f539b013787725dfce802?d=monsterid

GET может привести к немного лучшей производительности, некоторые веб-серверы записывают содержимое POST во временный файл перед вызовом обработчика.

Еще одна вещь, чтобы рассмотреть это ограничение размера. GET ограничен размером URL, 1024 байта по стандарту, хотя браузеры могут поддерживать больше.

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

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

davenpcj
источник
4

Там нет ничего, что вы не можете сделать сами по себе. Дело в том, что вы не должны изменять состояние сервера в HTTP GET. Прокси-серверы HTTP предполагают, что поскольку HTTP GET не изменяет состояние, то не имеет значения, использует ли пользователь HTTP GET один раз или 1000 раз. Используя эту информацию, они предполагают, что безопасно возвращать кэшированную версию первого HTTP GET. Если вы нарушите HTTP-спецификацию, вы рискуете сломать HTTP-клиента и прокси-серверы. Не делай этого :)

Гили
источник
Это не только браузеры, которые рассчитывают на то, что GET безопасен и идемпотентен: пауки поисковых систем и браузеры с предварительной загрузкой (например, fastfox) также полагаются на это.
Фрэнк Фармер
@gili, наконец, кто-то с правильным ответом. Я действительно удивлен, как много людей ошиблись. недурно!
lubos hasko
4

Это затрагивает концепцию REST и то, как сеть была своего рода предназначена для использования. На радио Software Engineering есть отличный подкаст , в котором подробно рассказывается об использовании Get и Post.

Get используется для извлечения данных с сервера, где действие обновления не требуется. Идея заключается в том, что вы должны иметь возможность использовать один и тот же запрос GET снова и снова и получать одну и ту же информацию. URL содержит информацию о получении в строке запроса, потому что он должен был легко отправляться в другие системы, и людям нравится адрес, где можно что-то найти.

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

kemiller2002
источник
«На радио Software Engineering есть отличный подкаст, в котором подробно рассказывается об использовании Get и Post». Где это находится?
2010 года
Я добавил ссылку на это.
kemiller2002
Вот эта связь: se-radio.net/2008/05/episode-98-stefan-tilkov-on-rest Я также редактировал ссылку выше, хотя у меня нет прав на редактирование, и она должна быть рецензирована и т.д.
MrBoJangles
Предположим, у меня есть конечная точка, которая принимает файл в качестве входных данных, выполняет некоторую обработку файла (пример - извлечение данных на основе регулярных выражений) и возвращает данные JSON, а затем я могу использовать GET-запрос для загрузки файла на сервер. Или я должен использовать запрос POST?
переменная
4

1.3 Быстрый контрольный список для выбора HTTP GET илиPOST

Используйте GET, если:

    The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).

Используйте POST, если:

    The interaction is more like an order, or
    The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or
    The user be held accountable for the results of the interaction.

Источник .

Anagha
источник
3

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

Использование его для обновления состояния - например, GET delete.php?id=5для удаления страницы - очень рискованно. Люди узнали, что когда веб-ускоритель Google начал предварительную загрузку URL-адресов на страницах, он ударил по всем ссылкам «удалить» и уничтожил данные людей. То же самое может случиться с пауками поисковой системы.

ceejayoz
источник
3

POST может перемещать большие данные, а GET - нет.

Но обычно речь идет не о недостатках GET, а о соглашении, если вы хотите, чтобы ваш веб-сайт / веб-приложение работали хорошо.

Посмотрите на http://www.w3.org/2001/tag/doc/whenToUseGet.html

cherouvim
источник
3

Из RFC 2616 :

9.3 GET
Метод GET означает получение любой информации (в форме объекта), идентифицируемой Request-URI. Если Request-URI относится к процессу создания данных, то именно полученные данные должны быть возвращены в качестве объекта в ответе, а не исходный текст процесса, если только этот текст не является выходом процесса.


9.5 POST
Метод POST используется для запроса, чтобы исходный сервер принял объект, заключенный в запросе, в качестве нового подчиненного ресурса, идентифицируемого Request-URI в строке запроса. POST разработан для того, чтобы унифицированный метод мог выполнять следующие функции:

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

Фактическая функция, выполняемая методом POST, определяется сервером и обычно зависит от Request-URI. Размещаемая сущность подчиняется этому URI так же, как файл подчиняется каталогу, в котором он находится, новостная статья подчиняется группе новостей, в которой она размещена, или запись подчиняется базе данных.

Действие, выполняемое методом POST, может не привести к ресурсу, который может быть идентифицирован с помощью URI. В этом случае либо 200 (ОК), либо 204 (Нет содержимого) - это соответствующий статус ответа, в зависимости от того, включает ли ответ объект, который описывает результат.

Дмитро
источник
2

Я использую POST, когда не хочу, чтобы люди видели QueryString или когда QueryString становится большим. Также POST необходим для загрузки файлов.

Я не вижу проблем с использованием GET, я использую его для простых вещей, где имеет смысл хранить вещи в QueryString.

Использование GET позволит также ссылаться на определенную страницу, где POST не будет работать.

Джон Бокер
источник
Почему мы не можем использовать GET для загрузки файлов?
переменная
1

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

Крис Миллер
источник
1

Прочитайте статью о HTTP в Википедии . Он объяснит, что такое протокол и что он делает:

ПОЛУЧИТЬ

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

и

POST Отправляет данные для обработки (например, из формы HTML) на указанный ресурс. Данные включены в тело запроса. Это может привести к созданию нового ресурса или обновлению существующих ресурсов или обоим.

W3C имеет документ под названием URIs, Addressability и использованием HTTP GET и POST, который объясняет, когда что использовать. Приводя

1.3 Быстрый контрольный список для выбора HTTP GET или POST

  • Используйте GET, если:
    • Взаимодействие больше похоже на вопрос (т. Е. Это безопасная операция, такая как запрос, операция чтения или поиск).

и

  • Используйте POST, если:
    • Взаимодействие больше похоже на заказ, или
    • Взаимодействие изменяет состояние ресурса таким образом, что пользователь будет воспринимать (например, подписка на услугу), или o Пользователь будет нести ответственность за результаты взаимодействия.

Тем не менее, перед окончательным решением использовать HTTP GET или POST, пожалуйста, также рассмотрите соображения относительно конфиденциальных данных и практические соображения.

Практическим примером будет всякий раз, когда вы отправляете форму HTML. Вы указываете либо сообщение, либо получить для формы действий. PHP заполнит $ _GET и $ _POST соответственно.

Гордон
источник
1

В PHP POSTограничение данных обычно устанавливается вашим php.ini. GETя полагаю, ограничен настройками сервера / браузера - обычно это 255байты.

jellyfishtree
источник
1

С w3schools.com :

Что такое HTTP?

Протокол передачи гипертекста (HTTP) предназначен для обеспечения связи между клиентами и серверами.

HTTP работает как протокол запроса-ответа между клиентом и сервером.

Веб-браузер может быть клиентом, а приложение на компьютере, на котором размещен веб-сайт, может быть сервером.

Пример: клиент (браузер) отправляет HTTP-запрос на сервер; затем сервер возвращает ответ клиенту. Ответ содержит информацию о состоянии запроса и может также содержать запрошенный контент.

Два метода HTTP-запроса: GET и POST

Два часто используемых метода для запроса-ответа между клиентом и сервером: GET и POST.

GET - запрашивает данные из указанного ресурса. POST - отправляет данные для обработки в указанный ресурс.

Здесь мы выделяем основные различия:

введите описание изображения здесь

Мадхусудхан Редди
источник
1
Для искателей и читателей было бы намного лучше ввести содержание изображения в ответ. Кроме того, первая часть ответа не очень помогает в ответе на вопрос.
Дэйв Швайсгут
Скопируйте вставку отсюда - вы должны правильно указать свой источник, а лицензия на источник должна разрешать повторное использование, что я не думаю, что w3schools делает. Кроме того, вы действительно думаете, что это добавляет что-то, что не было рассмотрено в других 25 ответах?
Бенджамин В.
1

Простая версия POST GET PUT DELETE

  • использовать GET - когда вы хотите получить любой ресурс, например, список данных, на основе любого идентификатора или имени
  • использовать POST - когда вы хотите отправить какие-либо данные на сервер. имейте в виду, что POST - это тяжелая операция, потому что для обновления мы должны использовать PUT, а не POST. POST создаст новый ресурс.
  • используйте PUT - когда вы
Раджеш
источник
4
«использовать PUT - когда вы» Где остальная часть предложения?
Пан
Замечательно, что кому-то первые две марки этого ответа понравились настолько очевидно, что они проголосовали против, последняя фраза хаха: '-)
pooley1994
0

Что ж, главное, что вы отправите, GETбудет показано через URL. Во-вторых, как говорит Ceejayoz, существует ограничение на количество символов для URL.

prodigitalson
источник
0

Другое отличие состоит в том, что POST обычно требует две операции HTTP, тогда как GET требует только одну.

Изменить: я должен уточнить - для общих шаблонов программирования. Обычно реакция на POST с использованием прямой веб-страницы HTML представляет собой сомнительный дизайн по ряду причин, одной из которых является раздражающее «вы должны повторно отправить эту форму, хотите ли вы это сделать?» при нажатии кнопки назад.

Plynx
источник
2
POST не требует 2 http операций.
Билли ОНил
3
post-redirect-get требует 2 операции: en.wikipedia.org/wiki/Post/Redirect/Get
cherouvim
1
POST может потребовать 2 поездки в оба конца на сервер - обычным явлением является POST с expect: 100-continueзаголовком, а затем отправка данных происходит только после ответа сервера с помощью a 100 CONTINUE.
Фрэнк Фармер
Хорошая статья cherouvim, я никогда не знал, что у шаблона есть имя.
Plynx
@cherouvim: пост редиректа get делает, а обычного post нет. Вы можете просто получить get redirect get с теми же результатами. Это не имеет никакого отношения к протоколу, который ваша форма использует для отправки.
Билли ОНил
0

Как ответили другие, есть ограничение на размер URL с помощью get, и файлы могут быть отправлены только с постом.

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

Автор сценария должен использовать сообщения для изменения базы данных и использовать get только для поиска информации.

Языки сценариев предоставили много средств для доступа к запросу. Например, PHP позволяет использовать $_REQUESTдля извлечения сообщения или получения. Следует избегать этого в пользу более конкретного $_GETили $_POST.

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

Элизабет Баквальтер
источник
0

Gorgapor, mod_rewriteдо сих пор часто использует GET. Он просто позволяет переводить более удобный URL в URL со GETстрокой запроса.

Брайан Варшоу
источник
-1

Данные HTTP Post не имеют определенного ограничения на объем данных, поскольку разные браузеры имеют разные ограничения для GET. RFC 2068 заявляет:

Серверы должны быть осторожны в зависимости от длины URI выше 255 байт, потому что некоторые старые реализации клиента или прокси могут не поддерживать эти длины должным образом

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

HTTP POST используются, когда вы хотите отправить данные по URL-ресурсу.

Типичным примером использования HTTP GET является поиск, то есть поиск? Query = my + query Типичным примером использования HTTP POST является отправка обратной связи в онлайн-форму.

mythz
источник