Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Стандартизирован HTTP-метод QUERY, комбинирующий возможности GET и POST"	+/–
Сообщение от opennews (??), 18-Июн-26, 09:36
Инженерный комитет IETF (Internet Engineering Task Force), занимающегося развитием протоколов и архитектуры сети Интернет, придал HTTP-методу QUERY статус "Предложенного стандарта" и опубликовал связанную с ним спецификацию RFC 10008. Метод QUERY по  способу отправки данных на сервер повторяет метод POST, но отличается от него ориентацией не на запись данных и изменение состояния, а на формирование запросов на чтение... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=65713
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 18-Июн-26, 09:36	–4 +/–
И так браузеры еле работают, простое открытие хрома, файрфокса, браве без отображения страниц запускает по 25-30 процессов, жрет память и процессор...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #15

2. Сообщение от Аноним (2), 18-Июн-26, 09:53	+5 +/–
https://xkcd.com/927/ Раньше разработчики срались из-за организации поиска на POST вместо GET когда надо изобразить что-то сложное. Теперь будут сраться в выборе из 3 методов, великолепно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #42, #52

3. Сообщение от Хрю (?), 18-Июн-26, 09:57	–1 +/–
>метод POST, но отличается от него ориентацией не на запись данных и изменение состояния, С какого времени пост стал ориентированным на запись и изменение состояния? Пост это пост, какой смысл ему веб. Сервер придаст такой и будет у него смысл. У меня пост readonly, а для изменения есть put, patch, delete.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #24

4. Сообщение от Аноним (4), 18-Июн-26, 10:03	+3 +/–
А кто вам запрещает в GET вставлять ненулевое тело? HTTP это не запрещает, да и я так делал и делаю
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10, #16, #20, #34, #36

5. Сообщение от 1 (??), 18-Июн-26, 10:04	+1 +/–
Нормик - как раз для "плутания" надо не меньше 3 "сосен". Больше - лучше !
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

6. Сообщение от вымя (?), 18-Июн-26, 10:04	+/–
И, эээээ, чем это отличается от PUT?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #13, #30, #45

7. Сообщение от q (ok), 18-Июн-26, 10:21	–3 +/–
Обнови комп. Удали нескучные расширения. Закрой миллиард вкладок, которые накопились на 20 лет бравзинга (я же знаю, что ты их не закрываешь - видел у тебя на скринах, от табов только узенькие полоски, на которые даже кнопка закрытия вкладки не умещается).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #11, #17

8. Сообщение от Аноним (8), 18-Июн-26, 10:25	+4 +/–
По классике пост для создания, пут для изменения, патч для изменения части, делит для удаления. И гет для получения
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #12, #53

9. Сообщение от Аноним (11), 18-Июн-26, 10:26	+1 +/–
Стало хуже.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #27

10. Сообщение от фф (?), 18-Июн-26, 10:26	+1 +/–
а кто запрещает не изменять данные по POST запросу (если логика подразумевает лишь выдачу информации)? или может кто-то запрещает кешировать ответ на такой запрос? Почему тогда уж не сделать один универсальный метод запроса, а в заголовках указывать - можно ли кешировать, можно ли писать в логи итп.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #35

11. Сообщение от Аноним (11), 18-Июн-26, 10:27	–1 +/–
Почикать совместимость с целыми поколениями железа. Это конечно сильно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

12. Сообщение от Хрю (?), 18-Июн-26, 10:39	–4 +/–
Этому уже очень давно мало кто следует ибо это сильно узко и не удобно. Для современных браузеров и веб. серверов это просто слова, возможно, с небольшими настройками по умолчанию, для легаси. Но так хоть гет делай для изменений, хоть делете кешируемый всё это будет работать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #60

13. Сообщение от Жироватт (ok), 18-Июн-26, 10:41	–1 +/–
...Но другая группа в IETF нашла в PUT фатальный недостаток - его писали не они! Для решения этой проблемы они создали QUERY (похожее на PUT, но другое), и я наивно вспоминаю докладчика на IETF-овской конференции, говорящего, что скоро все хттп-запросы будуи ходить исключительно как QUERY через QUIC, и каждая обёртка над серверным API на экране будет исключительно QUERY-ем...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #19

14. Сообщение от Аноним (16), 18-Июн-26, 10:42    Скрыто ботом-модератором	–3 +/–
Старые W3C nepдyны никак не успокоятся со своим устаревшим, убогим, избыточным HTTP! Всё изображают активность стюардессы. Есть JSON-RPC - намного более удобный и гибкий протокол, но клоуны после недельных курсов будут с завидной настырностью лепить свои __овноподелия на REST.
Ответить | Правка | Наверх | Cообщить модератору

15. Сообщение от aname (ok), 18-Июн-26, 10:42	+/–
А поддерживаемые методы тут причём?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

16. Сообщение от Аноним (16), 18-Июн-26, 10:44	+/–
Вставлять никто не запрещает :) Но стандартный сервер может просто отбросить всё после хэдера и будет прав.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #31, #33

17. Сообщение от анон (?), 18-Июн-26, 10:44	–2 +/–
Обнови комп. Удали нескучные расширения. Закрой миллиард вкладок, которые накопились на 20 лет бравзинга. Выбери жизнь. Выбери работу. Выбери карьеру. Выбери семью. Выбери телевизор с большим экраном. Выбери стиральную машину, музыкальный центр, автомобиль и электрический консервный нож. Выбери здоровый желудок, зубы и медицинскую страховку. Выбери недвижимость и аккуратно выплачивай взносы. Выбери свой первый дом. Выбери друзей. Выбери курорты и шикарные чемоданы. Выбери костюм-тройку в самой лучшей фирме из самой дорогой материи. В свой выходной выбери диван, чтобы развалиться и смотреть отупляющее шоу. Набивай брюхо всякой всячиной. Выбери загнивание, в конце концов, и со стыдом вспомни подонков, которых ты заложил, чтобы выбраться самому. Выбери своё будущее. Выбери жизнь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #26

18. Сообщение от Аноним (20), 18-Июн-26, 10:48	+/–
QUERY энтерпрайзно. Изживают потихонечку хакерскую культуру, выдавливают по капле.
Ответить | Правка | Наверх | Cообщить модератору

19. Сообщение от Аноним (19), 18-Июн-26, 10:49	+/–
И чем же это будет отличаться от текущего балагана, кроме того что его просто узаконят и подметут в помойку бесконечно растущих хедеров?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #21

20. Сообщение от Аноним (20), 18-Июн-26, 10:50	+/–
Ага, причем сразу multipart/form-data, чтобы вообще )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

21. Сообщение от Жироватт (ok), 18-Июн-26, 10:54	+/–
Ничем.  "xckd - 15й стандарт". Но с другой стороны - зря что ли инженегры зарплату в этих комитетах получают? Нужно рожать Новый&УлуДшенный стандарт даже через "не могу", иначе кто заметит усилий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

22. Сообщение от localhostadmin (ok), 18-Июн-26, 10:56	+/–
Я не совсем понял. Че  оно отличается от обычного POST? В чем проблема принимать POST запросы и обрабатывать их как QUERY?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #29, #32, #47

23. Сообщение от Соль земли2 (?), 18-Июн-26, 10:58	–1 +/–
> даёт возможность скрыть конфиденциальные данные из логов прокси-серверов Решение проблемы через Ж, вместо нормальной настройки прокси.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #65

24. Сообщение от qrKot (?), 18-Июн-26, 10:59	+2 +/–
>> С какого времени пост стал ориентированным на запись и изменение состояния? Собственно, всегда был. Ну, точнее, немного не так. В этих ваших интернетах больше роляет ИДЕМПОТЕНТНОСТЬ запроса. И вот GET (бай дизайн) - идемпотентный (т.е. его можно безопасно закешировать, что важно, с учетом ограниченности, например, пропускной способности этих ваших интернетов). Т.е. GET дает гарантию, что два-десять-стопицот одинаковых запросов подряд по результату не будут отличаться от одного запроса. POST же - ровно тот же GET, только без всяких гарантий. У него нет гарантий идемпотентности, что по сути говорит о том, что состояние он в любой момент поменять может.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #38, #54

25. Сообщение от IdeaFix (ok), 18-Июн-26, 11:00	+/–
Пару дней назад попросил безопасника открыть 43 порт, ну надо мне было whois чтобы банить автономками. Готовая скриптовая оснастка уже была, и в других местах она работала, а тут 43 закрыт. Безопасник сказал - у ripe есть rest api, перепиши свои скрипты под https и не нужен тебе 43 порт. Я конечно сказал что скоро мы и пинговать будем по rest api через https, но пошел переписывать скрипты. А тут вон оно чо... http query.
Ответить | Правка | Наверх | Cообщить модератору

26. Сообщение от Жироватт (ok), 18-Июн-26, 11:02	–2 +/–
Обнови комп. Удали нескучные расширения. Закрой миллиард вкладок, которые накопились на 20 лет бравзинга. Выбери жизнь. Выбери работу. Выбери карьеру. Выбери семью. Выбери смарт-телек на ведроиде с большим, полутораметровым экраном. Выбери робота-пылесоса, голосового ассистента-в-колонке, электромобиль-Теслу и очередной сверхполезный гаджет с Алиэкспресс. Выбери здоровый желудок, зубы и ДМС. Выбери квартиру-апартаменты внутри МКАДа и аккуратно выплачивай ипотеку. Выбери свою первую дачу. Выбери друзей. Выбери сказочное_бали, Хайнань и невскрываемые бронированные чемоданы. Выбери мешковатый костюм от самой дизайнерской фирмочки МСК из самой дорогой, хотя бы без примесей полиэстера и вискозы, материи. В свой выходной выбери диван, чтобы развалиться и смотреть отупляющие видосы с ю- и рутуба. Набивай брюхо всякой дешёвой и илитной всячиной. Выбери загнивание, в конце концов, и со стыдом вспомни подонков, которых ты заложил, чтобы выбраться самому. Выбери своё будущее. Выбери жизнь. Адаптировать надо, адаптировать. Текст актуален для Штатов 90х-00х, но уже не для СНГ второй половины 20х.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

27. Сообщение от LaunchWiskey (ok), 18-Июн-26, 11:03	+1 +/–
Раньше было лучше!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

28. Сообщение от Аноним (33), 18-Июн-26, 11:04	+1 +/–
> Подобный подход даёт возможность передавать большой объём параметров в запросе, превышающий лимит на размер параметров в методе GET (8000 байт). Никто и ничто не мешает передавать параметры запроса точно также как в посте - через тело гета. Спека это разрешает. Люди этим пользуются. Единственный "бонус" от появления query - явно описанная семантика в отличие от гета, но так себе. Функционально оно ничего не меняет.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #37, #51

29. Сообщение от Жироватт (ok), 18-Июн-26, 11:06	+/–
Стандарты мутятся - лавэшка (на миграциях, переписывании и доработках) крутится. А потом отключат и GET, и POST для защиты детей от Ынтернета^W^W^W^W безопасности парсеров от хакеров и всё. Будет тебе кури вместо 2х типов запросов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

30. Сообщение от Аноним (30), 18-Июн-26, 11:06	+/–
Это GET-овый PUT, как будто бы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

31. Сообщение от Dmitry (??), 18-Июн-26, 11:07	–1 +/–
Стандартный сервер это какой? Как я напишу, так и будет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #39

32. Сообщение от Аноним (33), 18-Июн-26, 11:10	+1 +/–
POST - семантически про изменение данных. Query/get - про чтение данных, ожидая, что состояние запрашиваемых данных от этого запроса не изменится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

33. Сообщение от Аноним (33), 18-Июн-26, 11:12	+1 +/–
"стандартный сервер" - это который нарушает хттп спеку? Оставьте такие сервера себе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #40

34. Сообщение от qrKot (?), 18-Июн-26, 11:14	+/–
Принятые соглашения и сторонние прокси, например? Да, в стандарте напрямую про игнор body ничего не говорится, но там говорится следующее: ```The GET method means retrieve whatever information (in the form of an    entity) is identified by the Request-URI.``` Ну т.е. "запрос для получения информации, идентифицируемой Request-URI". А body в Request-URI не входит, т.е. запросы с одинаковой урлой и разными body, согласно стандарту, должны возвращать одну и ту же информацию. На основании этого есть СОГЛАШЕНИЕ об идемпотентности запроса. Пока ты на локалхосте пилишь сайты на PHP, по сути, никто тебе не запретит body в GET-запросе читать или аплоадить фоточки GET-запросом через multipart-form. Однако как только ты чуть-чуть за пределы локалхоста выберешься... Ну задеплоился ты, например, в какой-нибудь гуглоклауд-апп-энжин, а потом удивляешься, почему тебе body в GET-запросах не приходит, например...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

35. Сообщение от qrKot (?), 18-Июн-26, 11:27	+/–
>> а в заголовках указывать - можно ли кешировать Ну ващет можно указывать. Прям заголовки специальные есть даже. Вот тут с механикой ознакомиться можно: https://datatracker.ietf.org/doc/html/rfc2616#section-13 >> а кто запрещает не изменять данные по POST запросу Никто не запрещает. И изменять никто не запрещает. По факту - POST-запрос вообще без всяких гарантий, может делать все, что угодно. Это специальный такой запрос без семантики вообще. >> или может кто-то запрещает кешировать ответ на такой запрос? Здравый смысл, например? Метод не гарантирует идемпотентность - что вы кешировать собрались? >> Почему тогда уж не сделать один универсальный метод запроса На JSON-API посмотрите - один универсальный POST, везде 200-Ок в ответах. HTTP - строго транспорт, вся информация об ошибках и т.д. - в BODY. За пределами же API-применения на локальной машинке есть всяческие border-gateway и реверс-прокси, маппинг, CORS'ы и прочее-прочее, которым удобнее иметь методы и заголовки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #50

36. Сообщение от фняк. (?), 18-Июн-26, 11:42	+/–
Просто решили в стандарте прописать явным образом. Давно ковырял, но была там какая-то неоднозначность, хотя на практике работало
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

37. Сообщение от Аноним (37), 18-Июн-26, 11:48	+/–
> Спека это разрешает. пруф в студию, пожалуйста. заранее спасибо. с ув.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

38. Сообщение от Bonifatium (?), 18-Июн-26, 11:49	–1 +/–
> GET (бай дизайн) - идемпотентный > GET дает гарантию за это отвечает приложение. GET сам по себе не дает гарантий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #43, #56

39. Сообщение от qrKot (?), 18-Июн-26, 11:52	+/–
Стандартный - это реверс-прокси или boder-gateway хостера. Что бы ты ни писал, настройкам ингресса на это по барабану.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

40. Сообщение от qrKot (?), 18-Июн-26, 11:55	+/–
Где нарушает-то? Читаем спеку: '''The GET method means retrieve whatever information (in the form of an    entity) is identified by the Request-URI.''' Метод GET служит для получения любой информации, идентифицируемой Request-URI. Body частью Request-URI не является - можно смело выкидывать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

42. Сообщение от Аноним (42), 18-Июн-26, 11:57	+/–
Теперь будут гадать почему в ответ прилетает протухший кэш. POST то никто в адеквате не кэширует
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

43. Сообщение от Аноним (42), 18-Июн-26, 11:59	+/–
За это надо бить разрабов приложения, потому что мутировать данные в GET - это ССЗБ
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #49

45. Сообщение от qrKot (?), 18-Июн-26, 12:00	+1 +/–
Кхм, а что у него общего с PUT? PUT - создай/измени запись. QUERY - выбери мне данные, удовлетворяющие запросу, который лежит в body.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

46. Сообщение от GrandProgrammer (ok), 18-Июн-26, 12:06	+/–
Теперь еще деприкейт GET метода сделают лет через двадцать.
Ответить | Правка | Наверх | Cообщить модератору

47. Сообщение от qrKot (?), 18-Июн-26, 12:11	+/–
У POST особой семантики нет. POST - это "вот запрос к серверу, отдай как есть, сервер сам знает, что с этим делать". POST может запрашивать данные, изменять данные, создавать, удалять - да все может (с точки зрения семантики). QUERY - больше про выборку данных. Фильтры, запросы "отдай мне пользователей с датой рождения позднее 2006 года" и т.д. Условно SELECT-запросы. По факту, запрета на изменение данных нет, и в случае неидемпотентных запросов действительно от POST не отличается. Зато для идемпотентных (SELECT-запросов) есть механика со специальными заголовками про кеши/протухание кешей/ссылками на повтор запроса/ссылками на получение данных из прошлых запросов. Кажется, конечно, что херня ненужная, но это если не задумываться о реверс-прокси и прочих border-gateway'ях. Вот пришел к тебе запрос "выбери мне всех блондинов с голубыми глазами и членом 35 см." - ты в базу сходил, получил мой профиль, и в кеше у себя прихранил. Наружу отдал заголовки "за следующую минуту вряд ли чего изменится", "данные запроса я у себя храню в кеше следующий час по ссылке1" и "повторно запросить можно по ссылке2". Следующий запрос через 30 секунд отдастся прямо из кеша реверс-прокси (до тебя даже не дойдет, нахрена тебе лишние запросы). Потом еще час запросы будут отдаваться из твоего уже кеша, и только через час оно начнет опять в базу ломиться. Офигительно же. И двухуровневый кеш самому пилить не надо, тупо заголовки правильно расставь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

48. Сообщение от Аноним (48), 18-Июн-26, 12:19	+/–
Говорили-же им: не плоди сущности без надобности. Все равно плодят. А что в итоге? >могут напрямую использоваться расширенные форматы, такие как .... SQL (application/sql) что чревато иньекциями, т.к. WAFы не смогут очищать SQL запросы в BODY ЗЫ. Выглядит прямо как сознательная диверсия.
Ответить | Правка | Наверх | Cообщить модератору

49. Сообщение от Анонисссм (?), 18-Июн-26, 12:20	+/–
>бить разрабов приложения, потому что мутировать данные в GET - это ССЗБ сюрприз, данные могут меняться даже без запросов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

50. Сообщение от фф (?), 18-Июн-26, 12:20	+/–
это всё понятно. Моя мысль была про зачем выдумывать новые методы, если можно всё это реализовать на уже имеющихся? про идемподентость вот только - а кто ее гарантирует в гет запросе, или вот в этом новом? сервер вполне и базу может грознуть и диск отформатировать после первого гет, и на второй уже физически не сможет прочитать инфу для ответа. Идемпотентность можно задекларировать в апи. И тогда пофиг как вы будете слать запросы - soap вон вобще по smtp умеет работать - ответы можно будет кешировать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #64

51. Сообщение от qrKot (?), 18-Июн-26, 12:27	+/–
>> Никто и ничто не мешает передавать параметры запроса точно также как в посте - через тело гета. Спека это разрешает. Никто и ничто не мешает реверс-прокси, ингрессам, бордер-гейтвеям и т.д. игнорировать тело запроса при передаче. Спека это разрешает. >> Единственный "бонус" от появления query - явно описанная семантика в отличие от гета The GET method means retrieve whatever information (in the form of an    entity) is identified by the Request-URI. GET-метод служит для получения любой информации (в форме сущности), идентифицируемой Request-URI. В чем "не явная семантика"? 2 важных положения "ПОЛУЧЕНИЕ сущности" и "идентифицируемой Request-URI". Т.е. содержимое body (не часть Request-URI) не может быть используемо для идентификации. Поясню: два GET-запроса с одинаковой урлой, но с разными body должны и обязаны возвращать идентичные ответы (идентичные GET-запросу на ту же урлу вообще без body). Поэтому в спека НЕ ЗАПРЕЩАЕТ передачу body в GET-запросе, но явным образом лишает body GET-запроса всякого смысла. Если body не имеет право изменить что-то в процессинге запроса, нахрена его вообще передавать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

52. Сообщение от penetrator (?), 18-Июн-26, 12:33	+/–
срались только долбанариумы, GET в принципе не нужен для API, это просто семантика GET надо только для подсасывания ресурсов самим браузером теперь все будут использовать QUERY но только не в старых версиях браузеров, но цирк сохранится
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #58

53. Сообщение от penetrator (?), 18-Июн-26, 12:36	+/–
кто сделал это классикой? а если сценарий отработки предполагает вызов внешнего сервиса и тип операции определяется внешним сервисом? тогда что? стройная (нет) семантическая модель идет лесом? )))))) я не использую вообще семантику HTTP для API, это бред, одни статус коды чего стоят лучше обращать на технические ограничения и особенности использования VERBS а не вот это вот всё
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #61

54. Сообщение от penetrator (?), 18-Июн-26, 12:38	+/–
не дает, потому что данные могут поменяться, и один и тот же гет будет выдавать уже обновленные данные только если ты не захочешь делать версионирование по хешу, но это бред хранить это все, скажем так - это узко специализированное решение
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #57

55. Сообщение от Аноним (55), 18-Июн-26, 12:45	+/–
По GET спецификации можно передавать тело. Зачем новый "квари" потребовался?!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #67

56. Сообщение от qrKot (?), 18-Июн-26, 12:58    Скрыто ботом-модератором	+/–
>> за это отвечает приложение. GET сам по себе не дает гарантий. Ну, по сути, у нас тогда вообще никаких гарантий нет. У нас даже нет гарантии, что приложение в принципе запустится! И гарантий, что приложение СООТВЕТСТВУЕТ спецификации - у нас тоже нет. Да и, по большому счету, если приложенька на локалхосте крутится - да кому какая разница на спеки! Работает как-то и ладно! Просто потом сюрпризы начинаются. Деплоишься на новый хостинг - все раком стоит. А разраб такой "ничего не знаю, у меня все работает!" Если приложение корректно и соответствует спеке - GET должен давать гарантию идемпотентности. Иначе говно он, а не GET)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

57. Сообщение от qrKot (?), 18-Июн-26, 13:02	+/–
Гарантия идемпотентности не в том, что данные никогда не меняются - это в принципе невозможная гарантия. Гарантия идемпотентности - это гарантия, что N повторяющихся запросов (при любом натуральном N) идентичны по своему результату одному аналогичному запросу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

58. Сообщение от qrKot (?), 18-Июн-26, 13:05	+/–
А версия браузера тут при чем??? Браузер сам по себе ничего, кроме GET и POST не умеет, остальное JS делает. А метод в запросе - просто строка, чо хошь, то и пиши.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #62

59. Сообщение от Аноним (59), 18-Июн-26, 13:05	+/–
А где же RFC 10000
Ответить | Правка | Наверх | Cообщить модератору

60. Сообщение от qrKot (?), 18-Июн-26, 13:06	+/–
>> Для современных браузеров и веб. серверов это просто слова Бгг, особенно для ingress'ов и реверс-прокси, ага.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

61. Сообщение от qrKot (?), 18-Июн-26, 13:09	+/–
>> а если сценарий отработки предполагает вызов внешнего сервиса и тип операции определяется внешним сервисом? А каким образом твоему API-контракту не насрать на контракт внешнего сервиса? Ну вот пришел тебе PUT-запрос - тебе что-то мешает в коде его обработки POST к внешнему сервису сделать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

62. Сообщение от penetrator (?), 18-Июн-26, 13:09	+/–
> А версия браузера тут при чем??? > Браузер сам по себе ничего, кроме GET и POST не умеет, остальное > JS делает. А метод в запросе - просто строка, чо хошь, > то и пиши. VERB должен поддерживаться браузером, с полной реализацией связанной с методом спецификации начиная например от длины GET запроса, до конкретных поддерживаемых Content-Type в том же POST
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

63. Сообщение от Assador (ok), 18-Июн-26, 13:12    Скрыто ботом-модератором	+/–
Надо предложить IETF сделать следующим стандартизированным запросом ASK. А после него — WHATTHEFUCK. 1. Метод ASK Используется, когда тебе _очень_ нужно узнать у сервера, почему что-то пошло не так, но ты не хочешь слать тяжелый QUERY. Тело запроса: пустая строка или лаконичное «Ну и?». Ожидаемый ответ: сервер возвращает текущий экзистенциальный статус базы данных. Поддерживает кэширование, потому что ответ «Всё сложно» обычно не меняется неделями. 2. Метод WHATTHEFUCK (или WTF для экономии трафика) Метод наивысшего приоритета. Вызывается автоматически, когда фронтенд получает «500 Internal Server Error», хотя локально всё работало идеально. Идемпотентность: абсолютно неидемпотентен. Каждый вызов этого метода гарантированно повышает давление у дежурного сисадмина.   Заголовки: обязательно должен содержать заголовок «X-Reason: Kuda-Vse-Delos». Спецификация ответа: сервер обязан в ответ прислать не просто JSON с ошибкой, а полный дамп памяти, историю коммитов за последние три часа и контакты тимлида, который это одобрил. Код ответа для такой связки тоже нужен отдельный: «499 I Am Doing My Best». Осталось только оформить черновик RFC, закинуть в список рассылки IETF и ждать, пока суровые бородатые инженеры в свитерах начнут это комментировать с абсолютно серьезными лицами.
Ответить | Правка | Наверх | Cообщить модератору

64. Сообщение от qrKot (?), 18-Июн-26, 13:30	+/–
>> про идемподентость вот только - а кто ее гарантирует в гет запросе, или вот в этом новом? Реализация от разработчика сервиса, очевидно! Спецификации эти - они для чего, собственно, нужны? Да для того, чтобы минимум удивления было при отладке и поиске багов в продовых окружениях! Пока приложенька запущена на локалхосте с единственным пользователем из браузера на том же локалхосте - можно смело забить на все эти спецификации. Это "набор рекомендаций, не более того" (с) некий Джек Воробей. Вопрос только в том, что будет дальше. Вот раскатался ты на какой-нибудь клауд-нейтив диджитал-оушен, радостный сидишь. А потом не радостный ищешь, какого хрена ничего не работает. Просто у хостера есть border-gateway. А еще хостер знает, что GET должен быть идемпотентным. Ну вот пришел ему запрос GET /some/path - он его у тебя запросил, пользователю вернул, в кеше у себя прихранил. Пришел второй через секунду - а хостер решает "не буду лишний раз стучаться" и отдает ответ из кеша. А ты сидишь, как олень, и пытаешься понять, почему до тебя запросы не доходят, а у пользователей данные устаревшие. Короче, хочешь без сюрпризов - изволь соответствовать спеке! >> Моя мысль была про зачем выдумывать новые методы, если можно всё это реализовать на уже имеющихся? Не получится, да и запутаются все. Вот тут полный тред народа, которые в GET обработку body юзают (я тоже юзаю, на самом деле, но во внутреннем интеропе). А перед всеми этими тысячами приложенек, каждая со своей хотелкой, стоят реверс-прокси, ингрессы всякие и т.д. и т.п. Хостеры, короче, как-то трафиком рулят. Ну вот представь себя хостером. Тебе оно надо свой гейтвей напрягать и всякие мегабайтные body и прочие payload'ы парсить, чтобы понять, что закешировать надо, и как эти запросы отбалансить? А логику кеширования и балансировки ты будешь под каждый возможный ингресс в каждом своем приложении писать? А ты точно не рукожоп и проксю не положишь? Ну вот они и рожают спецификации, чтобы без этих вот приседаний и 100-километровых мануалов было понятно: вот вам QUERY, вот у него 4 заголовка, которые регулируют политику кеширования. И ты читаешь, и в 50 строк поддержку пилишь в своем сервисе. А разрабы проксей - ту же самую спеку читают, и из коробки в своей софте поддержку этих заголовков рожают. Охуенно же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

65. Сообщение от qrKot (?), 18-Июн-26, 13:32	+/–
Ох уж эти админы локалхоста, которые и софт пишут, и прокси сами настраивают...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

66. Сообщение от Аноним (48), 18-Июн-26, 13:37	+/–
Пока curl не реализует новый метод, тот так и останется на бумаге.
Ответить | Правка | Наверх | Cообщить модератору

67. Сообщение от qrKot (?), 18-Июн-26, 13:44	+/–
По GET-спецификации GET возвращает данные, идентифицируемые по Request-URI, в котором body не участвует. Т.е. спека официально разрешает его игнорировать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема