Из того, что я могу собрать, есть три категории:

1. Никогда не используйте GETи не используйтеPOST
2. Никогда не используйте POSTи не используйтеGET
3. Неважно, какой вы используете.

Правильно ли я предположил эти три случая? Если да, то каковы примеры из каждого случая?

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

http://myblog.org/admin/posts/delete/357

Должен привести вас на страницу подтверждения, а не просто удалить элемент. Так проще избежать несчастных случаев.

POSTтакже более безопасен, чем GET, потому что вы не вставляете информацию в URL. И так , используя GETкак methodдля HTML формы, собирающий пароль или другую конфиденциальную информацию , не самая лучшая идея.

Последнее замечание: POSTможет передавать большее количество информации, чем GET. «POST» не имеет ограничений по размеру для передаваемых данных, в то время как «GET» ограничен 2048 символами.

Вкратце

• Использовать GETдля safe andidempotentзапросов
• Использовать POSTдля neither safe nor idempotentзапросов

В деталях есть подходящее место для каждого. Даже если вы не следуете принципам RESTful , многое можно узнать, узнав о REST и о том, как работает подход, ориентированный на ресурсы.

RESTful приложение будет use GETsдля операций, которые оба safe and idempotent.

safeОперация представляет собой операцию , которая делает not change the dataзапрашивается.

idempotentОперация, в которой результат будет be the sameне важно , сколько раз вы спрашиваете его.

Само собой разумеется, что, поскольку GET используются для безопасных операций, они автоматически также становятся идемпотентными . Обычно GET используется для извлечения ресурса (например, вопроса и связанных с ним ответов о переполнении стека) или сбора ресурсов.

Приложение RESTful будет использовать PUTsдля операций, которые not safe but idempotent.

Я знаю, что вопрос был о GET и POST, но я вернусь к POST через секунду.

Обычно PUT используется для редактирования ресурса (например, для редактирования вопроса или ответа о переполнении стека).

A POSTбудет использоваться для любой операции, которая есть neither safe or idempotent.

Обычно POST используется для создания нового ресурса, например, для создания НОВОГО вопроса SO (хотя в некоторых проектах PUT также будет использоваться для этого).

Если вы запустите POST дважды, вы получите ДВА новых вопроса.

Также есть операция DELETE, но я думаю, я могу оставить это там :)

обсуждение

С практической точки зрения современные веб-браузеры, как правило, надежно поддерживают только GET и POST (вы можете выполнять все эти операции с помощью вызовов javascript, но с точки зрения ввода данных в формы и нажатия кнопки отправки вы обычно получаете две опции). В приложении RESTful POST часто переопределяется, чтобы обеспечить вызовы PUT и DELETE.

Но даже если вы не следуете принципам RESTful, полезно подумать об использовании GET для получения / просмотра информации и POST для создания / редактирования информации.

Вы никогда не должны использовать GET для операции, которая изменяет данные. Если поисковая система сканирует ссылку на ваш злой оператор или закладка клиента, это может привести к большим проблемам.

Используйте GET, если вы не возражаете против повторения запроса (то есть он не меняет состояние).

Используйте POST, если операция изменяет состояние системы.

Укороченная версия

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

Преимущества GET:

• URL можно безопасно добавить в закладки.
• Страницы могут быть перезагружены безопасно.

Недостатки GET:

• Переменные передаются через URL как пары имя-значение. (Риск безопасности)
• Ограниченное количество переменных, которые могут быть переданы. (На основе браузера. Например, Internet Explorer ограничен 2048 символами. )

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

Преимущества POST:

• Пары имя-значение не отображаются в URL. (Безопасность + = 1)
• Неограниченное количество пар имя-значение может быть передано через POST. Ссылка.

Недостатки POST:

• Страница, которая использовала данные POST, не может быть закладкой. (Если вам так хочется.)

Более длинная версия

Непосредственно из протокола передачи гипертекста - HTTP / 1.1 :

9,3 ПОЛУЧИТЬ

Метод GET означает получение любой информации (в форме объекта), идентифицируемой посредством Request-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 используется для запроса, чтобы исходный сервер принял объект, включенный в запрос, в качестве нового подчиненного ресурса, идентифицируемого Request-URI в строке запроса. POST разработан для того, чтобы унифицированный метод мог выполнять следующие функции:

• Аннотация существующих ресурсов;

• Размещение сообщения на доске объявлений, в группе новостей, в списке рассылки или аналогичной группе статей;

• Предоставление блока данных, такого как результат отправки формы, процессу обработки данных;

• Расширение базы данных с помощью операции добавления.

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

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

Первая важная вещь - значение GET против POST:

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

После этого можно отметить пару вещей:

• Используя GET, ваши пользователи могут использовать кнопку «назад» в своем браузере, и они могут закладки страниц
• Существует ограничение на размер параметров, которые вы можете передать как GET (2 КБ для некоторых версий Internet Explorer, если я не ошибаюсь) ; предел гораздо больше для POST и обычно зависит от конфигурации сервера.

В любом случае, я не думаю, что мы могли бы «жить» без GET: подумайте, сколько URL-адресов вы используете с параметрами в строке запроса, каждый день - без GET, все эти не будут работать ;-)

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

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

Мое общее правило - использовать Get, когда вы отправляете запросы на сервер, которые не собираются изменять состояние. Сообщения зарезервированы для запросов к серверу, которые изменяют состояние.

Одно практическое отличие состоит в том, что браузеры и веб-серверы имеют ограничение на количество символов, которые могут существовать в URL. Это отличается от приложения к приложению, но, безусловно, можно поразить его, если у вас естьtextarea s в ваших формах.

Еще одна ошибка с GET - они индексируются поисковыми системами и другими автоматическими системами. У Google когда-то был продукт, который предварительно выбирал ссылки на странице, которую вы просматривали, поэтому они быстрее загружались, если вы нажимали эти ссылки. Это вызвало серьезный хаос на сайтах, на которых были такие ссылки, как delete.php?id=1- люди потеряли свои сайты целиком.

Используйте GET, когда вы хотите, чтобы URL отражал состояние страницы. Это полезно для просмотра динамически генерируемых страниц, таких как те, что вы видите здесь. POST должен использоваться в форме для отправки данных, например, когда я нажимаю кнопку «Опубликовать свой ответ». Он также производит более чистый URL, поскольку не генерирует строку параметров после пути.

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

Один пример со страницы Gravatar: http://www.gravatar.com/avatar/4c3be63a4c2f539b013787725dfce802?d=monsterid

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

Еще одна вещь, чтобы рассмотреть это ограничение размера. GET ограничен размером URL, 1024 байта по стандарту, хотя браузеры могут поддерживать больше.

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

Еще меньше, чем этот предел, является проблемой, как писал другой автор, все, что в URL, может оказаться в других частях пользовательского интерфейса браузера, например в истории.

Там нет ничего, что вы не можете сделать сами по себе. Дело в том, что вы не должны изменять состояние сервера в HTTP GET. Прокси-серверы HTTP предполагают, что поскольку HTTP GET не изменяет состояние, то не имеет значения, использует ли пользователь HTTP GET один раз или 1000 раз. Используя эту информацию, они предполагают, что безопасно возвращать кэшированную версию первого HTTP GET. Если вы нарушите HTTP-спецификацию, вы рискуете сломать HTTP-клиента и прокси-серверы. Не делай этого :)

Это затрагивает концепцию REST и то, как сеть была своего рода предназначена для использования. На радио Software Engineering есть отличный подкаст , в котором подробно рассказывается об использовании Get и Post.

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

Предполагается, что post используется (по крайней мере, в архитектуре REST, на которой основывается сеть) для передачи информации на сервер / указания серверу выполнить действие. Примеры, такие как: обновить эти данные, создать эту запись.

1.3 Быстрый контрольный список для выбора HTTP GET илиPOST

Используйте GET, если:

    The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).

Используйте POST, если:

    The interaction is more like an order, or
    The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or
    The user be held accountable for the results of the interaction.

Источник .

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

Использование его для обновления состояния - например, GET delete.php?id=5для удаления страницы - очень рискованно. Люди узнали, что когда веб-ускоритель Google начал предварительную загрузку URL-адресов на страницах, он ударил по всем ссылкам «удалить» и уничтожил данные людей. То же самое может случиться с пауками поисковой системы.

POST может перемещать большие данные, а GET - нет.

Но обычно речь идет не о недостатках GET, а о соглашении, если вы хотите, чтобы ваш веб-сайт / веб-приложение работали хорошо.

Посмотрите на http://www.w3.org/2001/tag/doc/whenToUseGet.html

Из RFC 2616 :

9.3 GET
Метод GET означает получение любой информации (в форме объекта), идентифицируемой Request-URI. Если Request-URI относится к процессу создания данных, то именно полученные данные должны быть возвращены в качестве объекта в ответе, а не исходный текст процесса, если только этот текст не является выходом процесса.

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

• Аннотация существующих ресурсов;
• Размещение сообщения на доске объявлений, в группе новостей, в списке рассылки или аналогичной группе статей;
• Предоставление блока данных, такого как результат отправки формы, процессу обработки данных;
• Расширение базы данных с помощью операции добавления.

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

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

Я использую POST, когда не хочу, чтобы люди видели QueryString или когда QueryString становится большим. Также POST необходим для загрузки файлов.

Я не вижу проблем с использованием GET, я использую его для простых вещей, где имеет смысл хранить вещи в QueryString.

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

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

Прочитайте статью о HTTP в Википедии . Он объяснит, что такое протокол и что он делает:

ПОЛУЧИТЬ

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

и

POST Отправляет данные для обработки (например, из формы HTML) на указанный ресурс. Данные включены в тело запроса. Это может привести к созданию нового ресурса или обновлению существующих ресурсов или обоим.

W3C имеет документ под названием URIs, Addressability и использованием HTTP GET и POST, который объясняет, когда что использовать. Приводя

1.3 Быстрый контрольный список для выбора HTTP GET или POST

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

и

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

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

Практическим примером будет всякий раз, когда вы отправляете форму HTML. Вы указываете либо сообщение, либо получить для формы действий. PHP заполнит $ _GET и $ _POST соответственно.

В PHP POSTограничение данных обычно устанавливается вашим php.ini. GETя полагаю, ограничен настройками сервера / браузера - обычно это 255байты.

С w3schools.com :

Что такое HTTP?

Протокол передачи гипертекста (HTTP) предназначен для обеспечения связи между клиентами и серверами.

HTTP работает как протокол запроса-ответа между клиентом и сервером.

Веб-браузер может быть клиентом, а приложение на компьютере, на котором размещен веб-сайт, может быть сервером.

Пример: клиент (браузер) отправляет HTTP-запрос на сервер; затем сервер возвращает ответ клиенту. Ответ содержит информацию о состоянии запроса и может также содержать запрошенный контент.

Два метода HTTP-запроса: GET и POST

Два часто используемых метода для запроса-ответа между клиентом и сервером: GET и POST.

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

Здесь мы выделяем основные различия:

Простая версия POST GET PUT DELETE

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

Что ж, главное, что вы отправите, GETбудет показано через URL. Во-вторых, как говорит Ceejayoz, существует ограничение на количество символов для URL.

Другое отличие состоит в том, что POST обычно требует две операции HTTP, тогда как GET требует только одну.

Изменить: я должен уточнить - для общих шаблонов программирования. Обычно реакция на POST с использованием прямой веб-страницы HTML представляет собой сомнительный дизайн по ряду причин, одной из которых является раздражающее «вы должны повторно отправить эту форму, хотите ли вы это сделать?» при нажатии кнопки назад.

Как ответили другие, есть ограничение на размер URL с помощью get, и файлы могут быть отправлены только с постом.

Я хотел бы добавить, что можно добавлять вещи в базу данных с помощью get и выполнять действия с постом. Когда скрипт получает сообщение или получает, он может делать все, что хочет автор. Я полагаю, что отсутствие понимания происходит из-за формулировки, которую выбрала книга, или из-за того, как вы ее читаете.

Автор сценария должен использовать сообщения для изменения базы данных и использовать get только для поиска информации.

Языки сценариев предоставили много средств для доступа к запросу. Например, PHP позволяет использовать $_REQUESTдля извлечения сообщения или получения. Следует избегать этого в пользу более конкретного $_GETили $_POST.

В веб-программировании гораздо больше возможностей для интерпретации. Есть то, что нужно и что можно сделать, но какой из них лучше, часто обсуждается. К счастью, в этом случае нет никакой двусмысленности. Вы должны использовать сообщения для изменения данных, и вы должны использовать get для получения информации.

Gorgapor, mod_rewriteдо сих пор часто использует GET. Он просто позволяет переводить более удобный URL в URL со GETстрокой запроса.

Данные HTTP Post не имеют определенного ограничения на объем данных, поскольку разные браузеры имеют разные ограничения для GET. RFC 2068 заявляет:

Серверы должны быть осторожны в зависимости от длины URI выше 255 байт, потому что некоторые старые реализации клиента или прокси могут не поддерживать эти длины должным образом

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

HTTP POST используются, когда вы хотите отправить данные по URL-ресурсу.

Типичным примером использования HTTP GET является поиск, то есть поиск? Query = my + query Типичным примером использования HTTP POST является отправка обратной связи в онлайн-форму.