Comments 24
Не было бы проще и логичнее, просто разрешить серверу и клиенту, принимать и передавать, соответственно, тело в GET, вместо того чтобы вынуждать добавлять обработку целого "нового" метода?
Тем более, что многие серверы и клиенты уже и так позволяют это делать.
то же самое что и можно просто post сделать "безопасным" убрав проверки options и получив тот же qwery
классика из создания проблем, что бы их преодолевать. Ведь этот "стандарт" именно ради затягивания в браузеры по умолчанию и называют "стандартом". Так то можно какой угодно "запрос" собирать и отправлять.
помню была задача сделать нормальный обмен от клиента в условиях плохой сети, то есть без всех этих приседаний с кропсами и options - в итоге данные паковались в get-параметры и "разрешенные" заголовки (подпись в заголовке потому "знать ссылку" недостаточно) и это даже работало! Потому что странные фронт-енд правила - есть разные лимиты на url с параметрами, но к заголовкам лимиты тоже неслабые, даже к "безопасным"
По семантике GET и QUERY ничем не отличаются, в отличие от POST, который подразумевает внесение изменений.
подразумевает кем?
"внесение изменений" некоторые гении и на GET-параметрах делают до сих пор
я еще понимаю момент что GET-параметры попадают в url потому ссылкой можно и нужно поделится, но это QWERY это просто старый добрый POST который переизобретают в облегченном виде что бы не сломать старые наверченые костыли на котрых уже много что работает
И опять таки, все это проблема из жизни фронт-ендов так как в найтиве если уж сильно хочется чего-то странного то создаешь свой заголовок и работаешь с ним, если важно выделить на уровне запросов.
Даже на хабре мелькают время от времени статьи на тему UPDATE или POST, потому проблема уж точно не в людях или удобствах, а в том что бы пропихивать 100500 параметров на сервер и получать ответ быстрее, чем сейчас позволяют браузеры со всеми танцами.
И что то мне кажется что основной потребитель тут будет в лице нейронок, так как с клиентом реактивность давно уже решают через вебсокеты, а вот нейронкам в браузере нужно или слать запрос на свой сервер что бы он запросил "правильно" или упиратся в кропсы и прочие политики междоменного взаимодейсвия.
подразумевает кем?
Вы можете настроить инфраструктуру так, что при разрыве связи внутри — прокси, который торчит наружу — повторит запрос к внутреннему сервису несколько раз, если тот по таймауту отвалился, например. А клиент ничего и не заметит.
Сделать это можно только для идемпотентных запросов, очевидно, каковым POST не является. (Не нужно со мной спорить, я согласен, что это глагол ради глагола, я просто на ваш вопрос ответил.)
По семантике GET и QUERY ничем не отличаются
Отличаются именно в части тела запроса.
У GET тело не имеет общей стандартной семантики, у QUERY имеет. Ради этого метод и появился.
Идея была не в том, чтобы «разрешить отправить ещё один вид запроса», а в том, чтобы одинаково описать его смысл для всей цепочки обработки.
Проблема как раз в том, что GET с телом уже сейчас где-то работает, а где-то нет. RFC 9110 не задаёт для тела GET общей семантики, поэтому каждый участник цепочки передачи может трактовать его по-своему: клиент, прокси, кэш, WAF, фреймворк. QUERY появился не потому, что (на практике) строго нельзя было передавать тело и раньше, а потому, что для такого сценария не было отдельной стандартной семантики на уровне HTTP.
POST /search тоже остаётся рабочим вариантом, но он не сообщает инфраструктуре, что операция безопасная и идемпотентная. QUERY как раз про это: сложный запрос в теле, но с семантикой чтения.
Сделать «безопасный POST» по локальному соглашению можно. Собственно, так многие API и живут. Но это знание остаётся локальным соглашением между клиентом и сервером. Для HTTP-инфраструктуры это всё равно POST.
Семантика GET никогда не запрещала передавать тело, вы же сами об этом сказали. И QUERY ничего нового (включая семантику) не дает, кроме как больших затрат на модификацию существующих библиотек.
Да, это не запрещалось (в смысле, в тело положить что угодно) - но и не было описано как возможное. Вопрос не в запрете, а в том, что это долго оставалось частным соглашением без общей протокольной семантики. А раз нет семантики, нет указания, что тело точно есть - то долетит ли это тело через WAF, и даст ли конкретная библиотека к нему доступ - это, как говорится, частные случаи.
А RFC как раз предлагает вместо частных решений решение общее, стандартное.
Не было бы проще и логичнее, просто разрешить серверу и клиенту, принимать и передавать, соответственно, тело в GET, вместо того чтобы вынуждать добавлять обработку целого "нового" метода?
Не проще, у эндпоинта может быть много получателей, не факт что каждый из них будет корректно использовать новый стандарт старого метода, плюс нужно проследить всю цепочку - прокси, балансировщики, что везде тело передастся и нигде не дропнется.
А еще есть корпоративные системы типа AD FS и WAP, которые при множественных редиректах гарантировано вам поломают проброс тела в GET запросе.
Так ведь с новым стандартом нужно будет также проследить, что вся цепочка серверов умеет работать с новым методом "QUERY".
Если ответным аргументом будет: "Обновится зависимость и достаточно пересобрать".
То и с обработкой тела в GET - то же самое.
Я просто считаю, что убрать отсечение тела, если оно имеется (а оно имеется не у всех), проще, чем добавлять новый метод, который точно отсутствует у всех поголовно. И его добавление обернется куда более обширным вмешательством в код.
Через 10 лет квери в большинство мест завезут. А вот самодельный гет с телом или пост с пометкой - у каждого свой костыль и каждый делает по-своему, удачи в интеграциях. Костыли решили починить и сделать один вариант для всех. Для того и есть стандарты. Так то до HTTP первой версии тоже были самодельные решения. А теперь живем и считаем это обыденным.
Так старый стандарт не запрещал и соответственно нет необходимости вводить "новый стандарт старого метода".
Просто кто-то когда-то придумал "бестпрактикс" и понеслось, что сами себе выдумали ограничения, которых нет в протоколе изначально и в него заложен такой функционал
Люди занимаются какой-то ерундой. Гораздо лучше было бы добавить в GET и DELETE поддержку body, сначала в стандарт, а потом потихоньку в браузеры, серверы, фреймворки и так далее. В статье говориться, что вроде как будет проще что бы все поддерживали новый метод, но мне кажется, что повсеместная поддержка нового метода будет не раньше поддержки IPv6.
Что лучше в этом случае делать? Забить на HTTP-методы с их семантикой и всегда использовать POST в API и GET для статического контента.
А DELETE согласен, а GET подразумевает выборку по ID
Гораздо лучше было бы добавить в GET и DELETE поддержку body
не лучше. Если б добавили официально body в GET, получилось бы две спецификации: старая GETv1 и новая GETv2. И как тогда узнать, какую версию поддерживает определенный клиент/сервер/фреймворк? Да, посмотреть в документации, но где гарантия, что автор не забудет там указать точную версию или не посчитает данное уточнение несущественным? А вот с отдельным названием все становится проще. Написано, что есть поддержка QUERY - значит 100% есть. Не написано - 100% нет.
Не знаю, чего за негатив в комментах, но мне нравится пропозал, использовал бы его там, где надо отправить сложный фильтр и получить по нему данные.
Пост, патч и пут семантически подразумевают изменение или создание данных. А создавать длиннющий урл для гета выглядит не очень эстетично.
А так закинул json с фильтрами в тело, заслал query и получил результат (который сервер или прокси ещё и закэшить может). Красота!
Киллер-фича GET, а именно, что можно этот ужасно некрасивый URL (если конечно не хешировать параметры в строчку аля base64 как в статье предложено) положить в закладку или пошарить с коллегой / дать для дебаггинга разработчику, уходит.
Может если только браузер будет предлагать эту шушлайку скопировать, но опять же стандарт такой строчки надо бы чтобы всеми браузерами поддерживался + строчка должна все равно быть короче + это все равно будет раздолье для фишингов и других видов взломов, вряд ли сразу красиво придумают.
В общем, интересно, но непрактично из-за упомянутого неудобства.
Новый метод не предпологает замену GET, если URL с фильтрами и они помещаются, можно продолжать использовать GET и шарить URL. Новый метод просто дополнителная возможность для тех у кого другие требования
В спецификации нового метода предусмотрено, и в статье это указано, как делать если надо возможность сохраниять поиск для переиспользования или шарить между коллегами.
А всего-то нужно было утвердить тело для GET ну и DELETE заодно, которое, внезапно, из RFC и не было никогда запрещено.
Ещё один пример, того, что люди, которые все это придумывают и сидят в различных коммитетах далеки как от программирования, так и от элементарного здравого смысла.
А потом нам с вами с этим мучиться.
P. S. очень смешно читать, что вот дескать POST меняет данные, а GET нет - это всего лишь соглашение, которое ещё и нарушается довольно часто в сложных проектах, а сделать можно как угодно.
Можно всё сделать на POST с JSON RPC, я в таком проекте участвовал. Или даже без RPC, а просто POST и там по имени в урле что-то делать. Можно сделать чтобы GET менял состояние, иногда это даже оправданно для одноразовых ссылок. Всегда можно изобрести свой стандарт поверх чего угодно и положить болт на все соглашения. И заработать свое законное место в котле в аду, потому что другие люди пытаясь интегрировать самописный велосипед и ловя отсутствие идемпотентности маловероятно что будут вас благодарить.
Стандарт нужен чтобы на него могли ориентироваться и другие люди, ни разу не видевшие проект. Промежуточные системы, прокси, фильтры безопасности и мониторинг. Для блога на пхп оно может и не надо, для любителей педального транспорта в коде - тоже. А вот для остальных стандарт, тем более такого уровня, это важный инструмент для работы.
HTTP получил метод QUERY: зачем понадобился безопасный запрос с телом