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

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

Однако, если бы клиент сегодня подошел ко мне и сказал: "Мне все равно, что" Правильный способ "- это сделать, нам проще использовать ваш API, если мы сможем просто использовать URL-адреса и получить некоторые XML назад - мы не хотим создавать HTTP-запросы и POST/PUT XML," какие причины для ведения бизнеса могли бы я дать, чтобы убедить их в противном случае?

Есть ли последствия для кеширования? Проблемы с безопасностью? Я искал больше, чем просто "это не имеет смысла семантически" или "это делает вещи неоднозначными".

Edit:

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

ОТВЕТЫ

Ответ 1

  • Предварительная выборка: Многие веб-браузеры будут использовать предварительную выборку. Это означает, что он загрузит страницу, прежде чем нажимать на ссылку. Предполагая, что вы нажмете на эту ссылку позже.
  • Боты: Есть несколько ботов, которые сканируют и индексируют Интернет для информации. Они будут выдавать только запросы GET. По этой причине вы не хотите удалять что-либо из запроса GET.
  • Кэширование: GET HTTP-запросы не должны изменять состояние, и они должны быть идемпотентными. Idempotent означает, что выдача запроса один раз или выдача его несколько раз дает тот же результат. То есть побочных эффектов нет. По этой причине запросы GET HTTP тесно связаны с кешированием.
  • HTTP-стандарт говорит так. В стандарте HTTP говорится, для чего предназначен каждый метод HTTP. Несколько программ построены для использования стандарта HTTP, и они предполагают, что вы будете использовать его так, как вы должны. Таким образом, у вас будет undefined поведение из множества случайных программ, если вы не выполните.

Ответ 2

Как насчет того, что Google найдет ссылку на эту страницу со всеми параметрами GET в URL-адресе и пересматривает ее время от времени? Это может привести к катастрофе.

Там забавная статья об этом на Daily WTF.

Ответ 3

GET могут быть принудительно применены к пользователю и в результате получить подпрограмму запроса на межсайтовый запрос (CSRF). Например, если у вас есть функция выхода из системы http://example.com/logout.php, которая изменяет состояние сервера пользователя, злоумышленник может разместить тег изображения на любом сайте, который использует указанный выше URL в качестве источника: http://example.com/logout.php. Загрузка этого кода приведет к выходу пользователя из системы. В приведенном примере не так уж много, но если бы это была команда перевода средств из учетной записи, это было бы большим делом.

Ответ 4

Хорошие причины, чтобы сделать это правильно...

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

Одна из моих любимых цитат

Быстрая и грязная... долго после Быстрый покинул грязные останки.

Для вас это одно слово "Сшивание во времени сохраняет девять";)

Ответ 5

Безопасность для одного. Что произойдет, если веб-искатель попадет в ссылку удаления, или пользователь обманут нажатием гиперссылки? Пользователь должен знать, что они делают, прежде чем они это сделают.

Ответ 6

Безопасность: CSRF намного проще в запросах GET.

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

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

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

Ответ 7

Я как бы искал больше, чем просто "это не имеет смысла семантически" или "это делает вещи неоднозначными".

...

Мне все равно, что правильный способ делать вещи, это проще для нас

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

Через 2 месяца будет легче (и дешевле), если вы начнете с чего-то, что имеет смысл семантически. Мы называем это "правильным путем", потому что это облегчает жизнь, а не потому, что мы хотим вас мучить.