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

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

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

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

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

Вкратце

• Используйте GET для safe and idempotent запросов
• Используйте 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 используется для редактирования ресурса (например, редактирования вопроса или ответа при переполнении стека).

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

Обычно POST используется для создания нового ресурса, например, для создания вопроса NEW 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

Метод 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-адресе. Он отличается от приложения к приложению, но, безусловно, его можно использовать, если в ваших формах есть textareas.

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

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

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

Один из примеров со страницы граватара: 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-адрес содержит информацию о получении в строке запроса, потому что он был предназначен для того, чтобы его можно было легко отправить в другие системы, и людям нравится адрес, где что-то найти.

Предполагается, что сообщение будет использоваться (по крайней мере, архитектурой 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 of 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 имеет документ под названием URI, адресуемость и использование HTTP GET и POST., в котором объясняется, когда что использовать. Цитируя

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

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

и

• Use POST if:
  • The interaction is more like an order, or
  • Взаимодействие изменяет состояние ресурса так, как это будет воспринято пользователем (например, подписка на услугу), или o Пользователь будет нести ответственность за результаты взаимодействия.

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

Практический пример - это когда вы отправляете HTML-форму. Вы указываете либо post, либо get для действия формы. 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-адрес. Во-вторых, как говорит Сиджайоз, существует ограничение на количество символов в URL-адресе.

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

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

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

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

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

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

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

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

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

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

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

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

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