Несколько разрработчиков, использующих сервис VIALATM для работы с IOT объектами, обратились ко мне с просьбой реализовать простой http протокол. Ранее они использовали MQTT протокол, но в силу каких-то причин им было необходимо более простое решение. Протокол реализован. В этой статье его краткое описание.

Для поддержки портокола IOTV в сервисе зарезервирован порт 7746 (для работы по протоклу https следеут использовать порт — 7745).

HTTP header


Все запросы по протоколу IOTV должны содержать в заголовке (http header) атрибут «iotv-user». Если в настройках учетной записи «IOTV password» установлен, атрибут «iotv-password» в заголвке должен совпадать с этим значением, в противном случае он может быть опущен.



Обязательный атрибут


Все запросы должны содеражать обязательный атрибут«root».



Дополнительные атрибуты


К запросам может быть добавлен атрибут «time». Он должен быть установлен в формате UNIX STAMP (количество секунд с 1 января 1970 года). Если этот атрибут опущен, то временем события считается время поступления запроса на сервер. Все прочие возможные атрибуты зависят от того, как определен объект IOT в сервисе. В ответ на запрос возвращаются текущие значения всех атрибутов объекта

Примеры


GET
Request: vialatm.com:7746/?root=HOME&A1=5&B1=12
Response: A1=5&B1=12&C1=14

POST
Request: vialatm.com:7746/

JSON
Data: {«A1»:«12»,«root»:«HOME»,«B1»:«44»}
Response: {«A1»:«12»,«B1»:«44»,«C2»:«12»}
XML
Data: <req><A1>73</A1><root>HOME</root><B1>87</B1></req>
Response: <resp><A1>73</A1><B1>87</B1><D1>88</D1></resp>
POST FORM
Data: A1=543&root=HOME&B1=12&
Response: command=12.4&A1=543&B1=12&C1=14

Команды в ответ на запросы


Для IOT объектов можно определить команды



В этом случае, когда задается команда для объекта, она посылается в ответе на IOTV запрос:



Примеры ответов на запросы в этих случаях:

GET
Request: vialatm.com:7746/?root=HOME&A1=5&B1=12
Response: command=12.4&A1=5&B1=12&C1=14

POST
Request: vialatm.com:7746/

JSON
Data: {«A1»:«12»,«root»:«HOME»,«B1»:«44»}
Response: {«command»:«12.4»,«A1»:«12»,«B1»:«44»,«C2»:«12»}
XML
Data: <req><A1>73</A1><root>HOME</root><B1>87</B1></req>
Response: <resp><command>12.4</command><A1>73</A1><B1>87</B1><D1>88</D1></resp>
POST FORM
Data: A1=543&root=HOME&B1=12&
Response: command=12.4&A1=543&B1=12&C1=14

Комментарии (7)


  1. barkalov
    12.08.2017 11:05
    +1

    Так а в чем смысл? С MQTT идея понятна: там узкое место — очереди — перекладываются с плеч слабых контроллеров на плечи брокера (где есть и персистентная БД и нормальный TCP стек).
    А ваш протокол это просто соглашение о формате данных поверх http(s). Я такие «протоколы» раз в неделю пишу, когда становится тесно в парадигме CRUD.


    1. Euler2012 Автор
      12.08.2017 13:12

      В чем смысл? — Я просто поделился новой возможностью с теми разработчиками, которые планируют использовать сервис для работы с IOT.


      1. Shtucer
        12.08.2017 19:28

        "HTTP protocol" — это же масло масляное. Это если по-ерунде прицепиться.
        А остальное вызывает только вопросы: зачем гадить нестандартными полями в заголовки? Какой в этом смысл?
        Ну и юзерней-пароль при каждом запросе передавать… ну не знаю. Ерунда, конечно, но все же.


        1. Euler2012 Автор
          12.08.2017 21:20

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


          1. Shtucer
            12.08.2017 21:37

            Хорошо. Разработчики попросили, вы реализовали. Неужели нельзя было предложить что-то получше?
            Ну, я не знаю. Генерить для каждого узла что-то типа UUID. Пусть они его вместо обязательного root сотоварищи передают, заодно и без нестандартных заголовков, и без логин-паролей? Один такой скомпрометированный ключ скомпрометирует только один узел. Решается генерацией нового ключа для узла. Не идеально. Тем не менее, все укладывается в пейлоад, и уж поверх чего там все это передается неважно, хоть по udp.


            1. Euler2012 Автор
              12.08.2017 22:17

              Спасибо за хорошие идеи. Я буду дорабатывать текущую реализацию. И с помощью ваших советов и замечаний она будет лучше. Очень важно когда пользователи хабра предметно критикуют и дают конкретные советы(как в Вашем случае). Еще раз спасибо.


              1. Shtucer
                12.08.2017 22:32

                Я не уверен, что это "хорошие" идеи. Согласен на то, что это идеи "получше".