ПОЛУЧИТЬ против ПОЧТУ это действительно имеет значение?

Question

Хорошо, я знаю разницу в целях. ПОЛУЧИТЬ, чтобы получить некоторые данные. Сделайте запрос и получите данные обратно. POST должен использоваться для операций CRUD, кроме чтения, я считаю. Но когда дело доходит до этого, действительно ли сервер заботится, получает ли он в итоге GET против POST?

Answer 1

Согласно HTTP RFC, у GET не должно быть никаких побочных эффектов, в то время как у POST могут быть побочные эффекты.

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

С помощью RFC вы можете возложить на пользователя ответственность за действия, выполняемые POST (например, за покупку), но не за действия GET. «Боты всегда используют GET по этой причине.

Из RFC 2616, 9.1.1 :

9.1.1 Безопасные методы

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

В частности, конвенция было установлено, что ПОЛУЧИТЬ и
Методы HEAD НЕ ДОЛЖНЫ иметь Значение действия
кроме поиска. Эти методы должен считаться "безопасным". это позволяет агентам пользователя представлять другие методы, такие как POST, PUT и УДАЛИТЬ специальным образом, чтобы Пользователь осознает тот факт, что возможно небезопасное действие просьба.

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

Answer 2

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

http://www.example.com/items.aspx?id=5&mode=delete

Без какой-либо проверки полномочий, выполненной перед удалением, возможно, что робот Googlebot сможет войти и удалить элементы со своей страницы.

Answer 3

Так как вы пишете серверное программное обеспечение (предположительно), вам будет важно, если вы скажете ему это. Если вы обрабатываете данные POST и GET одинаково, то нет, это не так.

Однако браузер определенно заботится. При обновлении или нажатии на страницу, полученную вами в ответ на POST, появляется, например, небольшая подсказка «Вы уверены, что хотите снова отправить данные».

Answer 4

GET имеет ограничения на ограничение данных в зависимости от браузера отправителя:

В спецификации длины URL-адреса не указывается минимальная или максимальная длина URL-адреса, но реализация зависит от браузера. В Windows: Opera поддерживает ~ 4050 символов, IE 4.0+ поддерживает ровно 2083 символа, Netscape 3 -> 4.78 поддерживает до 8192 символов до появления ошибок при завершении работы, а Netscape 6 поддерживает ~ 2000 до появления ошибок при запуске

Answer 5

По спецификации HTTP, GET безопасен и идемпотентен, а POST - нет. Это означает, что запрос GET может повторяться несколько раз, не вызывая побочных эффектов.

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

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

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

Это очень простой взгляд на это. Для получения дополнительной информации вы можете рассмотреть книгу "RESTful Web Services" Руби и Ричардсона (пресса О'Рейли).

Для быстрого ознакомления с темой REST рассмотрите этот пост:

http://www.25hoursaday.com/weblog/2008/08/17/ExplainingRESTToDamienKatz.aspx

Самое смешное, что большинство людей обсуждают достоинства PUT v POST. Проблема GET v POST была и всегда была очень хорошо решена. Игнорируйте это на свой страх и риск.

Answer 6

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

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

источник

Answer 7

Если вы используете GET-запрос для изменения внутреннего состояния, вы рискуете получить плохие вещи, если какой-либо веб-сканер пересекает ваш сайт. Назад, когда вики впервые стали популярными, были ужасные истории об удалении целых сайтов, потому что функция «удалить страницу» была реализована как запрос GET, что привело к катастрофическим результатам, когда робот Google стучал ...

Answer 8

Я думаю, что более подходящий ответ: вы можете делать одно и то же с обоими. Однако это не столько вопрос предпочтения, сколько правильное использование 1002 *. Я бы порекомендовал вам использовать GET и POST, как они были предназначены для использования.

Answer 9

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

Answer 10

Должен ли пользователь иметь возможность добавить закладку на полученную страницу? Стоит также подумать о том, что некоторые браузеры / серверы неправильно ограничивают длину GET URI.

Редактировать: исправлено примечание об ограничении длины символа - спасибо ars!