Почему GET-запрос не должен изменять данные на сервере?

По всему интернету я вижу следующий совет:

GET никогда не должен изменять данные на сервере - используйте для этого запрос POST

Что лежит в основе этой идеи?

Если я создаю php-сервис, который вставляет данные в базу данных и передает их параметры в строку запроса GET, почему это неправильно? (Я использую подготовленные операторы, чтобы заботиться о SQL-инъекции). Является ли POST-запрос более безопасным?

Или есть какая-то историческая причина для этого? Если да, насколько актуален этот совет сегодня?

Это не совет.

A GETопределяется таким образом в протоколе HTTP . Он должен быть идемпотентным и безопасным .

Что касается того, почему - GETможно кэшировать и обновлять в браузере. Снова и снова и снова.

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

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

Я также предлагаю читать URI, адресуемость и использование HTTP GET и POST .

Существует также проблема с предварительной загрузкой ссылок в некоторых браузерах - они будут вызывать ссылки предварительной выборки, даже если автор страницы не указал это.

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

Каждый HTTP-глагол имеет свою ответственность. Например GET, как определено RFC

означает извлечение любой информации (в форме объекта), идентифицируемой посредством Request-URI.

POSTс другой стороны, означает вставить или более формально

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

Причины для сохранения этого пути:

• Это очень просто и работает в глобальном масштабе Интернет с 1991 года
• Придерживайтесь принципа единой ответственности
• Другие стороны используют GETв качестве средства поиска информации и добычи данных
• Предполагается, что GET является безопасной операцией, которая никогда не изменяет состояние ресурса.
• Соображения безопасности GET- это, по сути, чтение , тогда как, POSTпо сути, запись
• GET кэшируется браузерами, узлами в сети, интернет-провайдерами
• Если содержимое не изменяется, один GETи тот же URL-адрес должен возвращать одинаковые результаты всем пользователям, иначе вы не будете доверять возвращаемому результату.

Для полноты и просто для обеспечения правильного использования (источник) :

• GETпараметры передаются как часть URL, который по умолчанию имеет небольшую и ограниченную длину в 256 символов, при этом некоторые серверы поддерживают более 4000 символов. Если вы хотите вставить длинную запись, нет законного способа передать эти данные в
• При использовании защищенного соединения ̶ , такие , как Tls, ̶ Ссылка не получает зашифрованы, ̶ Поэтому все параметры ̶ ̶G̶E̶T̶̶ передаются открытым текстом. URL-адрес фактически зашифрован с помощью TLS, поэтому с TLS все в порядке.
• Вставка двоичных данных или символов, отличных от ASCII GET, нецелесообразна
• GET повторяется, если пользователь нажимает кнопку «Назад» в браузере
• Некоторые старые сканеры могут не индексировать URL-адреса со ?знаком внутри

РЕДАКТИРОВАТЬ: Ранее я сказал, что POST помогает защитить вас от CSRF, но это неправильно. Я не продумал это правильно. Вы должны требовать уникальный скрытый маркер области сеанса во всех ваших запросах, чтобы изменить данные для защиты от CSRF.

В первые дни Интернета были браузерные ускорители. Эти программы начнут щелкать ссылки на странице для кэширования содержимого. Google Web Accelerator был одной из таких программ. Это может нанести ущерб приложению, которое вносит изменения при нажатии на ссылку. Я бы сделал предположение, что есть еще люди, использующие программное обеспечение ускорителя.

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

Если я создаю php-сервис, который вставляет данные в базу данных и передает их параметры в строку запроса GET, почему это неправильно?

Самый простой ответ - «потому что это не GETзначит».

Использование GETдля передачи данных для обновления похоже на написание любовного письма и отправку его в конверте с пометкой "СПЕЦИАЛЬНОЕ ПРЕДЛОЖЕНИЕ - ДЕЙСТВУЙ!" В обоих случаях вы не должны удивляться, что получатель и / или посредники неправильно обрабатывают ваше сообщение .

Для ваших операций CRUD в приложении, ориентированном на базу данных, используйте следующую схему:

Использовать HTTP GET для операций чтения (SQL SELECT)

Использовать HTTP PUT для операций обновления (SQL UPDATE)

Использовать HTTP POST для операций создания (SQL INSERT)

Использовать HTTP DELETE для операций удаления (SQL DELETE)

GET никогда не должен изменять данные на сервере - используйте для этого запрос POST

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

GET редко должен изменять данные на сервере - используйте для этого запрос POST

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

Это, очевидно, крайний случай, но, безусловно, стоит отметить.