Зачем нам нужен HTTP GET? Есть ли что-то, чего нельзя достичь с помощью HTTP POST?

Question

Насколько я знаю, что может делать GET, того же можно достичь с помощью POST. Итак, почему GET требовался в первую очередь при определении протокола HTTP. Если GET предназначен только для извлечения ресурса, люди могут обновлять ресурсы, отправляя значения параметров в URL. Почему эта лазейка? Или парень, который делал кодирование на стороне сервера, чтобы обновить ресурс по GET-запросу, написал неверный код?

Answer 1

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

В частности, было установлено, что методы GET и HEAD НЕ ДОЛЖНЫ иметь значение действия, отличного от извлечения.

И отправка идентичного запроса несколько раз приводит к тому же результату, что и отправка его только один раз:

Методы также могут обладать свойством «идемпотентности» в том смысле, что (кроме ошибок, связанных с ошибками или истечением срока), побочные эффекты от N> 0 идентичных запросов такие же, как и для одного запроса. Методы GET, HEAD, PUT и DELETE разделяют это свойство.

Answer 2

Практически, ни один браузер не реализует POST, щелкая ссылки (без перехвата события click в JavaScript) и не добавляя в закладки данные POST.Кроме того, семантически POST и GET служат различным целям.Один для размещения данных в приложении, другой для получения данных из приложения.Эта семантика имеет практическое значение, но она также имеет теоретические последствия для проектирования, которые говорят о качестве дизайна вашего приложения: приложение, которое не обрабатывает GET иначе, чем POST, вероятно, имеет множество проблем безопасности и ошибок рабочего процесса.

Answer 3

С RFC 2616 :

9.3 GET

Метод GET означает получение любой информации (в форме объекта), идентифицированной Запросом.-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

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

  - Annotation of existing resources;
  - Posting a message to a bulletin board, newsgroup, mailing

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

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

Если ресурс был создан нана исходном сервере ответ ДОЛЖЕН быть 201 (Создан) и содержать объект, который описывает состояние запроса и ссылается на новый ресурс, а также заголовок Location (см. раздел 14.30).

Ответы на этот метод:не кэшируется, если ответ не включает в себя соответствующие поля заголовка Cache-Control или Expires.Однако ответ 303 (см. «Другое») может использоваться для того, чтобы пользовательский агент мог извлечь кэшируемый ресурс.

POST-запросы ДОЛЖНЫ соответствовать требованиям к передаче сообщений, изложенным в разделе 8.2.

раздел 15.1.3 по соображениям безопасности.

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

Answer 4

Каждый раз, когда вы выполняете поиск в Интернете и хотите связать кого-то с ним, вы можете легко сделать это через:

http://www.google.com/search?q=lol

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

У них просто разные цели, как указано в других ответах. GET для получения, POST для размещения.

Answer 5

Все также может быть достигнуто с помощью необработанных TCP-соединений.Тем не менее, мы часто используем HTTP, а не необработанные TCP-соединения, потому что HTTP предлагает уровень абстракции и, следовательно, удобство и соответствующие реализации.Аналогично, мы используем HTTP правильно (GET, POST, PUT, DELETE и т. Д.), А не тупо (только POST), потому что эти глаголы предлагают дополнительный уровень абстракции и, следовательно, удобство и соответствующие реализации.

Answer 6

Вы правы, все можно туннелировать через HTTP POST. На самом деле, веб-сервисы SOAP делают именно это. Все это POST с использованием веб-сервисов SOAP.

В этом случае вы туннелируете через HTTP, а не используете HTTP в полной мере. Если это все, что вы хотите сделать, тогда это нормально.

Однако, если вы хотите использовать HTTP для функций и преимуществ, которые он предоставляет помимо простой передачи сообщений, вам следует прочитать RFC и изучить остальные части протокола HTTP, включая GET, PUT, POST, DELETE и все заголовки, управление кешем и коды результатов.

Answer 7

Допустим, я хочу отправить переменную на страницу по ссылке, могу ли я сделать это с помощью POST?Нет, но с помощью GET я могу что-то отправить, выполнив ?variableName=someValue