Всю жизнь передавал данные cgi скриптам методом get. А тут говорят так нельзя.

у меня есть устройство на котором есть по написанное на си++, которое шлет гет запросы php скрипту на сервере.

а будет слать демону, который будет отсылать websocketd который будет асинхронно читаться из браузера

заменили php скрипт на сервере на жаваскрипт в браузере

Если у тебя там нет проверки что именно нужный девайс прислал данные, то передача гетом данных не самая большая проблема.

В общем случае упомянутая идемпотентность определяет политику ретрая для клиента, например гет хром долбит сам при отвале связи, а пост даже по ф5 спросит осылать или нет. Но т.к. у тебя там вряд ли клиент, который сам по себе будет что-то делать, то особой разницы как пересылать дынные нет.

Для такого - можно. Сам такое делал через wget в cron'е. Ты же ничего конкретного в базу не пишешь на основании этих данных. Но управление так лучше не делать.

Как-то так вышло, что писал post/get запросы и особенно не задумывался. Простенькие типы данных передавал get, бинарные post,

Какие нах бинарные данные? Учи английский. Гет — получить данные, пост — передать данные.

По-другому делают только мудаки, електронщики-сишнеги и прочие некомпетентные полудурки.

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

Да, я ещё не договорил, он это дело вылечил забанив всех ботов в robots.txt, но, как ты уже это понял, помогло не очень надолго)

В другой конторе, я уже лично видел сверхразума, который принципиально не делал бекапов, ведь у него везде был рейд)))

Я чет думал, вебсокет это обычно приложение, которое с браузером общается, а оно получается еще и с устройством может взаимодействовать. Т.е. если раньше у меня была схема «устройство»--«пхп скрипт»--«бд»--«пхп скрип»--«браузер», то будет «устройство» --«веб сокет»-«браузер». Верно?

Длина URL у браузера ограничена (около 2000 символов)

да.

вебсокет это протокол, так что точнее будет что-то вроде:

«устройство» --«прога»+«websocketd»-«браузер»

где websocketd это демон, который читает выхлоп проги и отправляет по протколу вебсокетов, ну и в браузере через JS это асинхронно получает и читает через коллбеки, далее обрабатывает, возможно используя DOM

Эдик ты вернулся? ))

Я аж глаза начал протирать и на дату поста таращиться :-D

Рад приветствовать старожила.

Get это неудобно, но если надо наверняка доставить запрос прицепите в get параметры случайное число или набор символов.

Если же хотите без геморроя, то post

Остальные варианты не нужны, ибо post делает все что нужно

Все методы различаются по идемпотентности. GET - идемпотентен, POST - нет.

Только в приложениях следующих REST-идеологии, RFC это не гарантирует

Get это неудобно... Если же хотите без геморроя, то post

Для многих наоборот, POST менее удобен, так как нельзя просто так взять и дернуть урл браузером

Я аж глаза начал протирать и на дату поста таращиться :-D

+1, думал кто то старый тред оживил.

Посмотрел бы я, как ты пару мегабайт в урл запихнешь… Файлы гетом на сервер никак не залить! Здесь, к сожалению, единственный способ — POST, т.к. даже вебсокеты в этом деле вряд ли помогут. А то ведь любой желающий мог бы просто брать, и качать твои базы данных с паролями к сайтам!

Да не обязательно демон должен быть отдельным процессом!

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

Отличную ты разницу нашел между не обязан и не гарантирует

ну да. просто конкретно этот websocketd, написанный на go позволяет в полпинка прикрутить любой шеллскрипт, который умеет обычный stdin/stdout, ничего особенного ему не надо. или тот же CGI. или REPL в каком-нибудь лиспе.

Почему плохо, обосновать не смог

полагаю, он не смог, не потому что не было аргументов, а потому что ты достаточно невосприимчив чтобы их воспринять.

А так да, нет ни одной причины передавать данные GET-ом, а вот подводных камней достаточно.

Отличную ты разницу нашел между не обязан и не гарантирует

В одном проекте я приводил поведение к RFC, а несколько сервисов заложились как раз на не RFC'шное поведение. На текущий момент у нас все по RFC, но не все готовы читать RFC до конца. Хотя когда писал работу с заголовками кэширования, то я только с 3 подхода смог более или менее понять как оно там работает.

ИМХО стандарт надо проще делать, а не мудрить, так что все зевают. От этого только хаос

Только в приложениях следующих REST-идеологии, RFC это не гарантирует

Это RFC HTTP, если приложение REST идеологии его нарушает, то это плоховато.

У меня тут знакомые могут переслать твое резюме чувакам, которые занимаются стандартизацией. Можешь попробовать свои силы.

da17 Не слушай это веб-макаку. Она тебе впаривает какое-то го-говно.

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

Какой-то там демон - это птушное говно убогое.

Может быть есть подводные камни которых я не знаю?

Да, фундаментальный камень - это http-говно, которое использовать никогда нельзя для каких-то реалтайм-состояний/нотификаций. Да и вообще использовать это говно ненужно.

Ну дак нужно понимать, что всё это http-говно создано для веб-макак. Они по определению не может быть нормальным. Это просто мусор.

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

с т.з. сервера все входящее по http есть запросы

Только в приложениях следующих REST-идеологии, RFC это не гарантирует

see https://tools.ietf.org/html/rfc2616#section-9.1.2

url это вообще плохо, даже доменные имена - отправляй post-запросы без url прямо на ip'шник...

GET - идемпотентен

Твои бы слова, да всем веб-макакам мира в уши.