OwenCloud. Что это и с чем его едят?

[capzap]

Запрос успешно отправлен на сервер и обработан сервером. Поэтому и код 200, а какой ещё можно вернуть код в этом случае?]

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

[A.Simonov]

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

API в любом случае возвращает в ответ ID группы, и все равно по нему придется проверять, прошла ли запись успешно, так как сервер должен ответить на API запрос сразу, а вот modbus команда на запись встанет в очередь, и может быть выполнена не мгновенно, даже если прибор в сети.

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

[capzap]

но разве если облако знает что прибор не в сети, зачем в очередь вставать?

[A.Simonov]

но разве если облако знает что прибор не в сети, зачем в очередь вставать?

Я на 100% не знаю как устроен обмен, так как не я писал код. Но имею представление об этом:
Запись происходит не мгновенно а с небольшим лагом. Команда попадает на сервер, а далее в составе пакета приходит на шлюз ПМ210, например, а он уже опрашивает приборы и отдает ответ на сервер.
Это все создает задержку, в случае ПМ210 - вообще довольно ощутимую.
Поэтому если вы дадите несколько команд на запись, они точно все попадут в очередь.
И за время пока они стоят в очереди может, например, пропасть мобильная сеть, из-за чего команда не будет исполнена.

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

[capzap]

Команда попадает на сервер, а далее в составе пакета приходит на шлюз ПМ210, например...

еще раз, если команда попала на сервер, а сервер имеет статус прибора не в сети, зачем вставать в очередь и присылать мне ответ на команду 200 когда и так ясно что будет 408

[A.Simonov]

еще раз, если команда попала на сервер, а сервер имеет статус прибора не в сети, зачем вставать в очередь и присылать мне ответ на команду 200 когда и так ясно что будет 408

Не считаю, что 408 код здесь уместен.
https://developer.mozilla.org/ru/doc...TTP/Status/408

Ну и все же, если прибор не в сети, это же не значит что за время ожидания (по умолчанию 900 секунд) он не восстановит соединение, особенно если мы говорим о мобильной сети и ПМ210.

[capzap]

1) да не принципиально, 204 или 504, любой отличный от 200

2) замечательно если восстановится связь, а если на уровне ответа на запись уставки уже маякнуть пользователю, что что то неладно на объекте(даче например), а не ждать гипотетического восстановления

[A.Simonov]

1) да не принципиально, 204 или 504, любой отличный от 200

2) замечательно если восстановится связь, а если на уровне ответа на запись уставки уже маякнуть пользователю, что что то неладно на объекте(даче например), а не ждать гипотетического восстановления

Идея понятна. Но все же, надежнее будет проверять статус записи, а не смотреть на код статуса ответа от сервера.
Так как возможны ситуации когда прибор на связи, а запись не прошла и наоборот.

Поэтому проверку нужно делать в любом случае, какой-бы код не пришел. А раз уж проверку в любом случае нужно делать, то к чему использовать малоиспользуемые коды ответа от сервера.
Сервер команду получил? Получил. Сервер запрос в очередь поставил? Поставил. => API запрос успешно обработан => код 200.

[capzap]

всевозможные проверки, это хорошо для безлимитных тарифов

[A.Simonov]

всевозможные проверки, это хорошо для безлимитных тарифов

Не все запросы сильно ограничены. Вот выдержка из документации:

Скрытый текст:

В случае превышения ограничения
возвращается код состояния 429 (Too Many Requests). Ограничения описаны ниже:
• /v1/parameters/last-data – не более 10 запросов за 10 секунд;
• /v1/device/index – не более 10 запросов за 10 секунд;
• /v1/parameters/data – не более 10 запросов за 10 секунд;
• /v1/auth/open – не более 10 запросов за 10 секунд;
• все остальные запросы – не более 30 запросов за 10 секунд.