Подтвердить что ты не робот

Почему я должен получать данные POST, а не GET?

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

Почему я должен использовать POST через GET? Я не понимаю преимуществ одного над другим. Я замечаю, что POST не добавляет данные в историю /URL и предупреждает вас об обновлении страницы, но это единственные две отличия, которые я знаю. Почему, как разработчик, я могу использовать один над другим?

4b9b3361

Ответ 1

Каждый метод HTTP: POST, GET, PUT, DELETE и т.д. кариет собственную семантику. При выборе правильного метода важно понять HTTP и REST, поскольку это способ, которым должен был работать HTTP, и способ, лежащий в основе сетевой инфраструктуры работает.

Хороший учебник по REST доступен здесь. Вот что говорит о методах POST и GET:

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

    Гарантия idempotence означает, что вы можете просто повторно отправить запрос. Idempotence также гарантируется для PUT (что в основном означает "обновить этот ресурс с помощью этих данных или создать его в этом URI, если его уже нет" ) и для DELETE (который вы можете просто попробовать снова и снова, пока не получите результат - удаление что-то, что нет, не проблема). POST, который обычно означает "создать новый ресурс", также может использоваться для вызова произвольной обработки и, следовательно, не является ни безопасным, ни идемпотентным.

Ответ 2

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

В дополнение к техническим различиям, есть вопрос о намерении. Стандарт HTTP описывает способы использования различных запросов (GET, POST, PUT, DELETE, HEAD); например, PUT предназначен для добавления ресурса, DELETE предназначен для его удаления, а POST предназначен для его изменения. Можете ли вы использовать запрос GET вместо PUT или DELETE? Конечно, но следующие стандарты делают намерение явным.

Подробнее см. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html.

Ответ 3

Если вы хотите idempotent запрашивать URI (т.е. ответ всегда тот же), используйте GET, else POST.

Ответ 4

Помимо всего прочего, GET ограничивается 2K (некоторые браузеры будут принимать больше), и он отображается в URL

Ответ 5

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

Всем семантике принадлежит весь веб-сайт. Это безопасно кэшировать GET-запрос, но не команду POST - так, что делают кеширующие прокси. Это безопасно, чтобы ПОЛУЧИТЬ ресурс несколько раз, поэтому у вас есть предварительные выборки ссылок, которые делают именно это. Это безопасно для закладки и обновления GET, поэтому нет предупреждений от браузеров и т.д. И т.д.

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