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

Question

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

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

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

Edit:

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

Answer 1

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

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

Для вас этот "стежок во времени спасает девять";)

Answer 5

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

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

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

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

Answer 6

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

...

Мне все равно, что делать правильно, нам легче

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

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

Answer 7

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