Дата рождения: 26.08.1976
schors
А кто мне может объяснить реальный смысл HTTP POST/PUT/PATCH/UPDATE? Я читал RFC, да. А зачем? Чтобы надпись на заборе красивее была?
arts
Tenno-Seremel
Желаю что б у тебя все действия GET запросами выполнялись на сайтах.
schors
вижу только одну проблему для этого. длину строки запроса
arts
<img src="http://you.host/drop/all/my/databases"/>И ты даже ничего не заметишь при заходе на страницу.
schors
ключ авторизации сам передастся?
arts
schors, сессия? Если ты залогинен, то да.
schors
это не рест-вей ) и утт я с ними согласен
schors
уболтали черти. может что-то в этом и есть. где посмотреть документы на тему QUERY_STRING и там передачи параметров в POST и что с этим в DELETE/PUT? чего-то нарыть не могу
arts
schors, DELETE обычно не передают параметров — это запрос на удаление ресурса, указанного в URI. А у PUT формат такой же, как и у POST.
schors
мы сейчас вернемся к разубеждению меня опять. а токен доступа по ментальной связи прилетит? :)
arts
schors, в заголовках же.
schors
хм... мысль интересная. и ведь есть такие
arts
schors, так обычно и делают.
зачем семантика в низкоуровневом протоколе? прости, но три адаптера на три простых действия - это пиздец
schors, даже в протоколах ещё более низкого уровня есть место какой-нибудь важной информации или тому же флагу. а HTTP — вообще прикладной.
и что? зачем в нём плодить сущности?
schors, затем, что иначе эти сущности будут плодить разработчики, причём, кто во что горазд.
а и так придётся. GRUD мягко говоря недостаточно для REST. в итоге и там сущности, и там сущности
schors, затем, что они появляются там далеко не просто так. и помогают разрабам ещё более прикладных протоколов отлаживать свои идиотские творения
угу. пися 120 функций одного и тгго же с заменой имени метода. ппц как удобно
schors, а ты предпочитаешь всё в одну функцию упихать?
нет. но я бы претпочёл func_http_post(url,data_dict) четырем идентичным func_http_<method>, различающимся внутри только параметрами в curl и методам запихивания data_dict - в строку или в тело
schors, приведи конкретный пример такого.
чего пример? то что POST надо пихать переменные в тело, а в GET в строку - это понятно? То что CURL имеет опцию метода (причём разную) для методов это понятно? понятно что на каждый метод надо свою обёртку написать?
schors, GET для получения контента, POST для добавления. Совершенно разный функционал. Вполне логично сделать две функции, а не одну.
блять. это один функционал. это запрос-ответ к веб серверу. за то что туда пихается и как интерпретируется ответ отвечает всё равно не curl
Ты вообще в курсе, что гет - идемпотентен? Ну хотя бы это уже их разделяет. Дальше. При чем тут вообще куча функций к протоколу? Пиши одну, на всё.
я не понимаю что такое "идемпотентен". по факту я в телнет пишу URI+QUERY_STRUNG, всякие HTTP-заголовки, тело, получаю ответ в виде HTTP-заголовков и тела. что в POST, что в GET, что в остальных. GET может быть хоть импотентен - это будет зависеть от того, как приложение обработает запрос. я не понимаю зачем каблуком забивать в транспортный протокол логику приложения, один хер он её обработать не сможет
schors, затем, блять, что на этом стоит весь веб, а не твоё импотентное приложение. если ты не понимаешь хттп — хуле ты вообще спор завёл? пользуйся одним гетом на всё.
а идемпотентен - чтоб ты знал - это значит, что сервер ОБЯЗАН вернуть один ответ на один и тот же запрос.
не понимаю кейса этого. вот реально. я понимаю что написали и что это. но я не понимаю зачем это
schors, ну, хттп писали чуваки явно не тупее нас с тобой. кейс гета - поиск, запрос. кейс поста - сохранение. остальное - для удобства, ну даже чтения логов.
не надо переоценивать ум тех, кто дорвался до IETF. они просто дорвались до IETF и уболтали тусовку. слушай, я даже видел какие-то документы для SOAP
я в шоке вообще такие вещи слышать от хостера.
думаешь все хостеры дураки и не умеют думать и никогда не прграммируют?
schors, после этого треда — да, я буду так думать. до него — не представлял даже, что такое бывает.
да чушь. я наверное в пятый раз говорю - я не понял зачем я сделал 4 обёртки на curl программируюя просто смену IP в API одной известной фирмы. два экрана кода блять только потому что кому-то всралось побравировать словами "идемпотентен"
schors, чтение логов упрощается в разы. а твоя лень — она твоя. лень.
чтение логов? какая тебе разница какую часть парсить - метод или URI? хоть авто, хоть глазами
schors, это один из примеров. второй - чтение своего же кода становится проще.
да чем оно проще, если из двухмерной ситемы URI|BODY я вдруг получаю двумерную URI|METHOD|BODY?
трехмерную конечно
schors, как минимум, всем.
лишней сущностью, забитой в нижестоящий протокол
schors, POST предназаначен для операций, имеющих последствия (вот тут man идемпотентность).
Не все для серфинга пользуются curl'ом, как ты:-) Есть такая штука, браузер называется. И в этом самом браузере для разных методов определено разное поведение с учётом задач, на эти методы возложенных, и последствий выполнения этих задач.
А в случае с API — семантика и только семантика. Если тебе удобнее использовать только GET — используй на здоровье. Здесь принципиальной разницы нет.
Только тогда тебе придётся прибивать дополнительные костыли для защиты от CSRF.
что такое CSRF?
https://en.wikipedia.org/wiki/Cross-site_request_forgery
ты смеешься надо мной? как раз браузер кроме GET/POST ничего и не умеет
schors, а на остальные методы можешь забить.
schors, а остальные для всяких API нужны в первую очередь.
чушь. только потому что их браузер не умеет :)
schors, js умеет.
ну js это js. это понятно
schors, ну так в вебе всё запрос-ответ, и что теперь, всё в одну кучу валить?
да. именно так. потому что это суть этого уровня прослойки.
schors, так тебе никто не запрещает так делать. Ты можешь вообще вообще весь сайт в один файл запихать, вместе с вёрсткой, скриптами и стилями, если тебе так удобно.
дурной пример. зачем css/js/html в разных файлах или в одном - вполне имеет логику. зачем внезапно какую-то часть логики дублировать в транспортный протокол я пока не понял
schors, хттп - прикладной протокол. прекрати уже.
это он в модели OSI или TCP прикладным называется. а если мы рассматриваем модель веб-приложений, то он как раз транспортный
schors, даже TCP-пакет имеет параметры, флаги и уровень срочности.
прекрасно. напомни, где в TCP указывается Conent-type для HTTP? так было бы удобно
schors, нахуй? для этого есть http ^_^
вот и я спрашиваю - нахуй HTTP знать добавил я или удалил пост на форуме, один хрен это делает не HTTP
schors, и совершенно непонятно, при чём тут вообще curl.
ну возьми не curl, а arts_super_http_client_lib. суть не изменится.
данные в GET ты всё один будешь через & пихать в строку запроса, а в POST тем же раком в тело. в PUT/DELETE кстати не знаю - не могу найти где посмотреть
schors, низкоуровневый — это TCP. А это самый верхний уровень. Ну удобно же, когда API можно сформулировать понятиями самого протокола, без велосипедов. Единообразие и стандартизация опять же.
а его нельзя сформулировать, в том и дело. представь, что ты пишешь ну пусть ну питоне API для А-записи DNS. добавить, изменить, удалить. тебе минимум две функции адаптера придётся писать только потому что они параметры по разному воспринимают. не знаю как там DELETE. для трёх простейших действий максимум с двумя параметрами. что ты там куда вынес? ты дрочишь потом на HTTP что ли? ты его не видишь вообще, что там за инкрустации-то?