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

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

Сообщения

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

1. Сообщение от Аноним (1), 18-Июн-26, 09:36	–3 +/–
И так браузеры еле работают, простое открытие хрома, файрфокса, браве без отображения страниц запускает по 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, #44

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

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

7. Сообщение от q (ok), 18-Июн-26, 10:21	–2 +/–
Обнови комп. Удали нескучные расширения. Закрой миллиард вкладок, которые накопились на 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

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	–1 +/–
Обнови комп. Удали нескучные расширения. Закрой миллиард вкладок, которые накопились на 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ообщить модератору

24. Сообщение от qrKot (?), 18-Июн-26, 10:59	+1 +/–
>> С какого времени пост стал ориентированным на запись и изменение состояния? Собственно, всегда был. Ну, точнее, немного не так. В этих ваших интернетах больше роляет ИДЕМПОТЕНТНОСТЬ запроса. И вот 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	+/–
Раньше было лучше!
Ответить | Правка | Наверх | 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

44. Сообщение от Аноним (42), 18-Июн-26, 12:00    Скрыто ботом-модератором	+/–
ты бы и собаку...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

45. Сообщение от qrKot (?), 18-Июн-26, 12:00	+/–
Кхм, а что у него общего с 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

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

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

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

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

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

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

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