Каковы преимущества использования запроса GET перед запросом POST?

Некоторые из моих приложений ajax в прошлом использовали запрос GET, но теперь я начинаю использовать вместо него запрос POST. Запросы POST кажутся немного более безопасными и определенно более удобными / красивыми. Таким образом, мне интересно, есть ли вообще причина, по которой я должен использовать запрос GET.

Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
30
0
19 420
7
Перейти к ответу Данный вопрос помечен как решенный

Ответы 7

Это может помочь вам решить, где использовать GET и где использовать POST:

URI, адресуемость и использование HTTP GET и POST.

Возможно, самое главное, GET можно отмечать закладками / просматривать в истории URL-адресов и искать в Google.

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

Закладки на самом деле не имеют отношения к AJAX, как просил Опрашивающий.

HalfBrian 22.11.2009 04:41

Неправда, если вы не хотите игнорировать кнопки назад / вперед в своих приложениях AJAX. В противном случае вам необходимо использовать хеши в своих URL-адресах, что напрямую связано с URL-адресом GET и закладками.

jvenema 22.11.2009 17:58

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

  • Повторить без проблем - если браузер обнаруживает ошибку, он может без проблем повторить попытку.
  • Кэшировать результат в браузере
  • Кешироваться через прокси

Все это хорошо. Все, что только извлекает данные (особенно общедоступные), действительно должно быть GET. Сервер должен отправлять разумные заголовки Last-Modified: и Expires:, чтобы при необходимости разрешить кеширование.

Ответ принят как подходящий

Я обычно задаю вопрос следующим образом: Изменилось ли что-нибудь важное после запроса? (несмотря на ведение журнала и т.п.). Если это так, это должен быть запрос POST, если нет, это должен быть запрос GET.

Я рад, что вы называете POST-запросы «немного» более безопасными, потому что это в значительной степени то, что они собой представляют; Подделать POST-запрос пользователя на страницу - тривиально. Однако выполнение этого запроса POST предотвращает случайный повторный запуск действия веб-ускорителями или перезагрузками.

Что касается AJAX, есть еще одно соображение: если вы возвращаете JSON с поддержкой обратного вызова, будьте очень осторожны, чтобы не помещать туда какие-либо конфиденциальные данные, которые вы не хотите, чтобы другие веб-сайты могли видеть там. В Википедии была уязвимость в этом направлении, когда пользовательский токен анти-CSRF был обнаружен через их JSON API.

К сожалению, это не отвечает на вопрос. «What are the advantages of using a GET request over a POST request?» «Thus, i'm wondering if there is any reason why I should use GET request at all.»

Md. Abu Nafee Ibna Zahid 17.03.2018 08:45

Запросы POST так же небезопасны, как и GET. Основное отличие состоит в том, что POST используется для изменения состояния серверного приложения, а GET только запрашивает данные от него.

Разница имеет значение, когда вы используете чистые, «спокойные» URL-адреса, где сам URL-адрес указывает ресурс, а различные методы запускают разные действия на стороне сервера.

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

Jason 12.10.2008 12:17

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

Kibbee 12.01.2009 22:09

Есть еще одно отличие, о котором никто не упоминает.

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

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

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

Было время, когда IE, как мне кажется, имел очень короткую строку GET URL. Некоторые приложения, такие как Lotus Notes, используют большое количество случайных символов для представления идентификаторов документов. У меня было неудовольствие использовать другой продукт, который генерировал случайные строки, поэтому URL-адрес страницы каждый раз был уникальным. Случайная строка была ОГРОМНОЙ ... и она не всегда работала с IE6 по памяти.

Однако все хорошие моменты в ответ на вопрос, запросы GET более полезны в определенных сценариях по сравнению с запросами POST:

  1. Их можно добавить в закладки
  2. Их можно кешировать
  3. Они быстрее
  4. У них есть известные последствия (при условии, что они не изменяют данные), поэтому посещайте их несколько раз. раз это не проблема.

Ради потомков, обновление этого комментария примечаниями к блогу re: point # 3 здесь, вся заслуга Омара А.Л. Забира (автора упомянутого Сообщение блога):

"Atlas by default makes HTTP POST for all AJAX calls. Http POST is more expensive than Http GET. It transmits more bytes over the wire, thus taking precious network time and it also makes ASP.NET do extra processing on the server end. So, you should use Http Get as much as possible. However, Http Get does not allow you to pass objects as parameters. You can pass numeric, string and date only. When you make a Http Get call, Atlas builds an encoded url and makes a hit to that url. So, you must not pass too much content which makes the url become larger than 2048 chars. As far as I know, that’s what is the max length of any url.

Another evil thing about http post is, it’s actually 2 calls. First browser sends the http post headers and server replies with “HTTP 100 Continue”. When browser receives this, it sends the actual body."

«Они быстрее» только потому, что их можно кешировать?

Harold 21.05.2014 17:16

Нет, также из-за того, как они работают; они совершенно разные в том, что и как отправляют данные. См. omaralzabir.com/…

jvenema 24.05.2014 00:16

Это единственный ответ, который отвечает на вопрос OP. Другие говорят о разнице.

Andrew Liu 03.03.2016 04:36

Другие вопросы по теме