设备端接口
一直以来，IoT的设备端接口的标准化程度较低，其多样化一直是一件让人挠头的事情。要么需要码农提供深度定制的服务，耗时耗力，要么会导致项目中断。
标准化接口
就我自己来说，在EPIC架构的Connector端一直推荐采用标准化的方法：
- 传输层：TLS
- 应用层：MQTT
- 表达层：JSON
然后数据就可以一路沿着队列传送到其他服务如数据库和API接口。但是由于资源原因，设备接口端一直存在定制需要。虽然大多数设计都比较落伍，尤其在安全性和语义性上缺乏合理的设计。
接口定制服务化
我们来观察其他供应商的做法：
- 机智云提供的Agent，其实是将接口工作统一到设备领域中，这样开发中直接访问设备的Agent，接口工作可以减少。
- 中移动OneNet，提供了Lua透传和JSON Schema两种方式，一种是让用户自己写代码，另外一种是利用JSON来定义编码解码对接工作。
- 华为OceanConnect，提供了编解码插件，本质上也是类似与OneNet的第二种方式。
以上三种方式都有可取之处，目的只有一个：加速设备对接和应用集成速度。
利用标记语言如JSON/XML，甚至Markdown/CSV格式语言都可以实现从编解码定义到编解码代码转换，但是没有标准化。而直接使用编程语言有一定风险，这也是为何OneNet采用嵌入式脚本Lua的原因吧。
此外需要设计者提供工具来实现：规划、验证、设备端代码生成。
类似设计
Yahoo pipes曾经是接合网络爬虫和非结构化数据解析的一种实验性工具。Twisted上也曾经有人提供过开源的替代品。如果将pipes作为通用编解码器来考虑，那么这个设计可以作为一个参考。
Google ProtocolBuf 也是一个相对完整的设计，包括.proto定义和代码生成器。除了JSON，还有msgpack和BSON等二进制序列化标准。替代品还有：Thrift，Hessian，Kiro......
在这些开源设计基础上，通过增加callback等其他定义，也可以构成一个相对完整的设计。
