schors, семантика. Хтмл тоже можно таблицами верстать, но header/content/aside/footer логичнее и понятнее.

зачем семантика в низкоуровневом протоколе? прости, но три адаптера на три простых действия - это пиздец

schors, даже в протоколах ещё более низкого уровня есть место какой-нибудь важной информации или тому же флагу. а HTTP — вообще прикладной.

schors, низкоуровневый — это TCP. А это самый верхний уровень. Ну удобно же, когда API можно сформулировать понятиями самого протокола, без велосипедов. Единообразие и стандартизация опять же.

и что? зачем в нём плодить сущности?

schors, затем, что иначе эти сущности будут плодить разработчики, причём, кто во что горазд.

а его нельзя сформулировать, в том и дело. представь, что ты пишешь ну пусть ну питоне API для А-записи DNS. добавить, изменить, удалить. тебе минимум две функции адаптера придётся писать только потому что они параметры по разному воспринимают. не знаю как там DELETE. для трёх простейших действий максимум с двумя параметрами. что ты там куда вынес? ты дрочишь потом на HTTP что ли? ты его не видишь вообще, что там за инкрустации-то?

а и так придётся. GRUD мягко говоря недостаточно для REST. в итоге и там сущности, и там сущности

Желаю что б у тебя все действия GET запросами выполнялись на сайтах.

вижу только одну проблему для этого. длину строки запроса

schors,

<img src="http://you.host/drop/all/my/databases"/>

И ты даже ничего не заметишь при заходе на страницу.

ключ авторизации сам передастся?

schors, сессия? Если ты залогинен, то да.

это не рест-вей ) и утт я с ними согласен

schors, затем, что они появляются там далеко не просто так. и помогают разрабам ещё более прикладных протоколов отлаживать свои идиотские творения

угу. пися 120 функций одного и тгго же с заменой имени метода. ппц как удобно

schors, а ты предпочитаешь всё в одну функцию упихать?

нет. но я бы претпочёл func_http_post(url,data_dict) четырем идентичным func_http_<method>, различающимся внутри только параметрами в curl и методам запихивания data_dict - в строку или в тело

schors, приведи конкретный пример такого.

чего пример? то что POST надо пихать переменные в тело, а в GET в строку - это понятно? То что CURL имеет опцию метода (причём разную) для методов это понятно? понятно что на каждый метод надо свою обёртку написать?

schors, GET для получения контента, POST для добавления. Совершенно разный функционал. Вполне логично сделать две функции, а не одну.

блять. это один функционал. это запрос-ответ к веб серверу. за то что туда пихается и как интерпретируется ответ отвечает всё равно не curl

Ты вообще в курсе, что гет - идемпотентен? Ну хотя бы это уже их разделяет. Дальше. При чем тут вообще куча функций к протоколу? Пиши одну, на всё.

schors, ну так в вебе всё запрос-ответ, и что теперь, всё в одну кучу валить?

schors, и совершенно непонятно, при чём тут вообще curl.

я не понимаю что такое "идемпотентен". по факту я в телнет пишу URI+QUERY_STRUNG, всякие HTTP-заголовки, тело, получаю ответ в виде HTTP-заголовков и тела. что в POST, что в GET, что в остальных. GET может быть хоть импотентен - это будет зависеть от того, как приложение обработает запрос. я не понимаю зачем каблуком забивать в транспортный протокол логику приложения, один хер он её обработать не сможет

да. именно так. потому что это суть этого уровня прослойки.

ну возьми не curl, а arts_super_http_client_lib. суть не изменится.

schors, затем, блять, что на этом стоит весь веб, а не твоё импотентное приложение. если ты не понимаешь хттп — хуле ты вообще спор завёл? пользуйся одним гетом на всё.

а идемпотентен - чтоб ты знал - это значит, что сервер ОБЯЗАН вернуть один ответ на один и тот же запрос.

schors, так тебе никто не запрещает так делать. Ты можешь вообще вообще весь сайт в один файл запихать, вместе с вёрсткой, скриптами и стилями, если тебе так удобно.

данные в GET ты всё один будешь через & пихать в строку запроса, а в POST тем же раком в тело. в PUT/DELETE кстати не знаю - не могу найти где посмотреть

я в шоке вообще такие вещи слышать от хостера.

не понимаю кейса этого. вот реально. я понимаю что написали и что это. но я не понимаю зачем это

schors, ну, хттп писали чуваки явно не тупее нас с тобой. кейс гета - поиск, запрос. кейс поста - сохранение. остальное - для удобства, ну даже чтения логов.

дурной пример. зачем css/js/html в разных файлах или в одном - вполне имеет логику. зачем внезапно какую-то часть логики дублировать в транспортный протокол я пока не понял

не надо переоценивать ум тех, кто дорвался до IETF. они просто дорвались до IETF и уболтали тусовку. слушай, я даже видел какие-то документы для SOAP

schors, хттп - прикладной протокол. прекрати уже.

думаешь все хостеры дураки и не умеют думать и никогда не прграммируют?

schors, после этого треда — да, я буду так думать. до него — не представлял даже, что такое бывает.

это он в модели OSI или TCP прикладным называется. а если мы рассматриваем модель веб-приложений, то он как раз транспортный

schors, даже TCP-пакет имеет параметры, флаги и уровень срочности.

да чушь. я наверное в пятый раз говорю - я не понял зачем я сделал 4 обёртки на curl программируюя просто смену IP в API одной известной фирмы. два экрана кода блять только потому что кому-то всралось побравировать словами "идемпотентен"

прекрасно. напомни, где в TCP указывается Conent-type для HTTP? так было бы удобно

schors, чтение логов упрощается в разы. а твоя лень — она твоя. лень.

schors, нахуй? для этого есть http ^_^

чтение логов? какая тебе разница какую часть парсить - метод или URI? хоть авто, хоть глазами

вот и я спрашиваю - нахуй HTTP знать добавил я или удалил пост на форуме, один хрен это делает не HTTP

schors, это один из примеров. второй - чтение своего же кода становится проще.

да чем оно проще, если из двухмерной ситемы URI|BODY я вдруг получаю двумерную URI|METHOD|BODY?

трехмерную конечно

schors, как минимум, всем.

лишней сущностью, забитой в нижестоящий протокол

schors, POST предназаначен для операций, имеющих последствия (вот тут man идемпотентность).

Не все для серфинга пользуются curl'ом, как ты:-) Есть такая штука, браузер называется. И в этом самом браузере для разных методов определено разное поведение с учётом задач, на эти методы возложенных, и последствий выполнения этих задач.

А в случае с API — семантика и только семантика. Если тебе удобнее использовать только GET — используй на здоровье. Здесь принципиальной разницы нет.

Только тогда тебе придётся прибивать дополнительные костыли для защиты от CSRF.

ты смеешься надо мной? как раз браузер кроме GET/POST ничего и не умеет

что такое CSRF?

https://en.wikipedia.org/wiki/Cross-site_request_forgery

уболтали черти. может что-то в этом и есть. где посмотреть документы на тему QUERY_STRING и там передачи параметров в POST и что с этим в DELETE/PUT? чего-то нарыть не могу

schors, а на остальные методы можешь забить.

schors, а остальные для всяких API нужны в первую очередь.

чушь. только потому что их браузер не умеет :)

schors, DELETE обычно не передают параметров — это запрос на удаление ресурса, указанного в URI. А у PUT формат такой же, как и у POST.

schors, js умеет.

мы сейчас вернемся к разубеждению меня опять. а токен доступа по ментальной связи прилетит? :)

schors, в заголовках же.

ну js это js. это понятно

хм... мысль интересная. и ведь есть такие

schors, так обычно и делают.