Хорошо, я знаю разницу в цели. GET - получить некоторые данные. Сделайте запрос и верните данные. POST должен использоваться для операций CRUD, кроме чтения, я считаю. Но когда дело доходит до этого, действительно ли сервер заботится о том, получает ли он в конечном итоге GET или POST?
Так как вы пишете серверное программное обеспечение (предположительно), то это волнует, если вы расскажете ему об этом. Если вы обрабатываете данные POST и GET одинаково, то нет, это не так.
Однако браузер определенно заботится. Обновление или щелчок назад к странице, которую вы получили в ответ на POST, выдает небольшую подсказку "Вы уверены, что хотите отправить данные снова", например.
Согласно HTTP RFC, GET не должен иметь никаких побочных эффектов, в то время как POST может иметь побочные эффекты.
Самый простой пример состоит в том, что GET не подходит ни для чего, как покупка-транзакция, или для публикации статьи в блоге, тогда как POST подходит для действий, которые имеют последствия.
В RFC вы можете удерживать пользователя, ответственного за действия, выполняемые POST (например, покупка), но не для действий GET. "Боты всегда используют GET по этой причине.
Из RFC 2616, 9.1.1:
9.1.1 Безопасные методы
Исполнители должны знать, что программное обеспечение представляет пользователя в
их взаимодействия через Интернет, и должны быть осторожны, чтобы пользователь должен знать о любых действиях, которые они может занять, что может иметь неожиданное значение для самих себя или другие.В частности, конвенция было установлено, что GET и
Методы HEAD НЕ ДОЛЖНЫ важность принятия мер
кроме поиска. Эти методы следует считать "безопасным". Эта позволяет агентам пользователей представлять другие методы, такие как POST, PUT и УДАЛИТЬ, особым образом, чтобы пользователю становится известно о том, что возможно, небезопасное действие просил.Естественно, невозможно убедитесь, что сервер не использует генерировать побочные эффекты в результате выполнение запроса GET; на самом деле, некоторые динамические ресурсы считают, что особенность. Важное различие вот что пользователь не запрашивал побочные эффекты, поэтому не могут нести ответственность за них.
Это происходит, если поисковая система сканирует страницу, так как они будут делать запросы GET, но не POST. Скажите, что у вас есть ссылка на вашей странице:
http://www.example.com/items.aspx?id=5&mode=delete
Без какой-либо проверки авторизации, выполняемой до удаления, возможно, что Googlebot мог войти и удалить элементы со своей страницы.
GET имеет ограничения на ограничение данных на основе отправляющего браузера:
Спецификация длины URL-адреса не определяет минимальную или максимальную длину URL-адреса, но реализация зависит от браузера. В Windows: Opera поддерживает ~ 4050 символов, IE 4.0+ поддерживает ровно 2083 символа, Netscape 3 → 4.78 поддерживает до 8192 символов, прежде чем вызывать ошибки при выключении, а Netscape 6 поддерживает ~ 2000, прежде чем вызывать ошибки при запуске
Если вы используете запрос GET для изменения состояния в исходном состоянии, вы рискуете иметь плохие вещи, если веб-браузер каким-то образом пересекает ваш сайт. Назад, когда wikis впервые стали популярными, были ужасные истории о всех сайтах, которые были удалены, потому что функция "удалить страницу" была реализована как запрос GET, с катастрофическими результатами, когда робот Googlebot стучал...
"Используйте GET, если: взаимодействие больше похоже на вопрос (т.е. это безопасная операция, такая как запрос, операция чтения или поиск).
"Использовать POST, если: взаимодействие больше похоже на заказ, или взаимодействие изменяет состояние ресурса таким образом, чтобы пользователь воспринимал (например, подписку на услугу) или пользователь считался ответственным за результаты взаимодействия.
По спецификациям HTTP GET является безопасным и идемпотентным, а POST - ни тем, ни другим. Это означает, что запрос GET может повторяться несколько раз, не вызывая побочных эффектов.
Даже если вашему серверу все равно (и это маловероятно), между вашим клиентом и сервером могут быть промежуточные агенты, все из которых имеют это ожидание. Например, прокси-серверы кэшируют данные у вашего интернет-провайдера или других поставщиков для повышения производительности. Подобное ожидание справедливо для ускорителей, например, плагин предварительной выборки для вашего браузера.
Таким образом, запрос GET может быть кэширован (на основе определенных параметров), и если он терпит неудачу, он может быть автоматически повторен без каких-либо последствий вредных эффектов. Итак, на самом деле ваш сервер должен стремиться выполнить этот контракт.
С другой стороны, POST небезопасен, а не идемпотентен, и каждый агент знает, что он не кэширует результаты запроса POST, или автоматически запрашивает запрос POST. Так, например, транзакция с кредитными картами никогда бы никогда не была запросом GET (вы не хотите, чтобы счета дебетовали несколько раз из-за сетевых ошибок и т.д.).
Это очень простой подход к этому. Для получения дополнительной информации вы можете рассмотреть книгу "RESTful Web Services" Руби и Ричардсона (пресс-релиз O'Reilly).
Для быстрого перехода по теме REST рассмотрите этот пост:
http://www.25hoursaday.com/weblog/2008/08/17/ExplainingRESTToDamienKatz.aspx
Самое забавное, что большинство людей обсуждают достоинства PUT v POST. Проблема GET v POST и всегда была очень хорошо решена. Игнорируйте его на свой страх и риск.
Должна ли у пользователя быть возможность закладки на полученную страницу? Другое дело, что некоторые браузеры/серверы неправильно ограничивают длину URI GET.
Изменить: исправлено char примечание ограничения длины - спасибо ars!
GET имеет ограничения на стороне браузера. Например, некоторые браузеры ограничивают длину запросов GET.
Я думаю, что более подходящий ответ, вы можете в значительной степени сделать то же самое с обоими. Однако это не столько вопрос предпочтения, сколько вопрос правильного использования. Я бы рекомендовал вам использовать GET и POST, как они были предназначены, которые будут использоваться.
Вы знаете несколько тонких различий в безопасности. См. Мой вопрос
По существу важно помнить, что GET войдет в историю браузера и будет передаваться через прокси в виде простого текста, поэтому вам не нужна конфиденциальная информация, например пароль в GET.
Очевидно, возможно, но стоит упомянуть.
Это зависит от программного обеспечения на сервере. Некоторые библиотеки, такие как CGI.pm в perl, обрабатывают оба по умолчанию. Но бывают ситуации, когда вы более или менее должны использовать POST вместо GET, по крайней мере для того, чтобы нажимать данные на сервер. Большие объемы данных (где соответствующий URL-адрес GET станет слишком длинным), двоичные данные (во избежание проблем с кодированием/декодированием), многочастные файлы, не прошедшие анализ заголовков (для непрерывного обновления до AJAX-стиля...) и аналогичных.
Технически сервер не может заботиться о том, какой запрос он получает. Он будет слепо выполнять любой запрос, проходящий через провод.
В чем проблема. Если у вас есть действие, которое уничтожает или изменяет данные в действии GET, Google будет разорвать ваш сайт, когда он просканирует с помощью индексации.
Обычно серверу все равно. Но это в основном для соблюдения передовых практик, как вы упомянули. Клиентская сторона также имеет значение - как уже упоминалось, вы не можете обычно класть закладку POST'd, а некоторые браузеры имеют ограничения на длину URL-адреса для действительно длинных запросов GET.
Поскольку GET предназначен для указания ресурса, который вы хотите получить, в зависимости от точного программного обеспечения на стороне сервера, веб-сервер (или балансировщик нагрузки перед ним) может иметь ограничение по размеру в запросах GET для предотвращения атак типа "отказ в обслуживании"...
Помните, что браузеры могут кэшировать GET-запросы, но обычно не кэшируют запросы POST.
Да, это имеет значение. GET и POST на самом деле очень разные.
Вы правы в этом, как правило, GET - это "получение" данных с сервера и отображение страницы, а POST - для "отправки" данных на сервер. Внутри ваши сценарии получают одни и те же данные, независимо от того, GET или POST, так что нет, сервер действительно не заботится.
Основное отличие - параметры GET указаны в URL-адресах, а POST - нет. Вот почему POST используется для регистрации и регистрационных форм - вы не хотите, чтобы ваш пароль был указан в URL-адресе. Аналогично, если вы просматриваете разные страницы или показываете конкретное представление некоторых данных, вам обычно нужен уникальный URL.
Технически, нет. Все GET - это публикация материала в первой строке HTTP-запроса, а POST-сообщения - в теле.
Однако, как "веб-инфраструктура" рассматривает различия, мир становится разным. Мы могли бы написать целую книгу об этом. Однако я дам вам несколько "лучших практик":
Используйте "POST", когда ваш HTTP-запрос изменит что-то "конкретное" внутри веб-сервера. Т.е. вы редактируете страницу, создаете новую запись и так далее. POSTS с меньшей вероятностью будут кэшироваться или рассматриваться как нечто "повторяемое без побочных эффектов"
Используйте "GET", если хотите "посмотреть на объект". Теперь такой взгляд может изменить что-то "за кулисами" с точки зрения кеширования или записи, но он не должен ничего менять "существенным". То есть, я мог бы повторять мой GET снова и снова, и ничего плохого не произошло бы, кроме завышенных значений хита. GET должны быть легко заклассифицированы, поэтому пользователь может вернуться к этому же объекту позже.
Параметры для GET (материал после "традиционно" ) следует рассматривать как "атрибуты представления" или "что посмотреть" и т.д. Опять же, это ничего не должно изменить: используйте для этого POST.
И, наконец, когда вы POST что-то (например, вы создаете новый комментарий), обработайте сообщение post 302, чтобы "перенаправить" пользователя на новый URL-адрес, который просматривает этот объект. Т.е. POST обрабатывает информацию, затем перенаправляет браузер в инструкцию GET для просмотра нового состояния. Отображение информации в результате POST также может вызвать проблемы. Выполнение перенаправления часто используется и улучшает работу.
Нет, они не должны за исключением @jbruce2112 Ответ и загрузка файлов требуют POST.