参考:
结合参考和自己的实践:
- 不要在最前面加
/
比如:/home/device/light, 等于在最前面有一个空字符串层级，这完全没有必要而且增加了broker之类的处理,home/device/light才是合理的。 - 就使用英文+数字字符，不要使用空格、特殊字符
这些都会增加处理的复杂性，有时候还会有兼容性问题 - 将设备ID或识别码包含在topic中
多方面原因：便于订阅特定设备、便于后续的过滤、便于权限控制 - 不要在运行中创建 topic
这个好理解，交流还是有预期比较好。在规模较大的系统中，随意的创建 topic 会导致维护困难、处理复杂度增加，最主要的肯定非常容易导致遗漏和未知行为。 - 命名简单明确
太长了看太累，看不懂会困惑，太累或困惑都容易出错； topic 应该尽可能细致，能详细定位到不同的设备和消息
PS: 据说写代码最难的是命名，对我等非英语母语的更如此吧。
- 命令字保持一致，并放在最后
MQTT不像HTTP有多个方法，RESTful因此将CRUD映射为HTTP方法。当然MQTT通常只有一个控制下发命令字，状态和属性是主动上报的。MQTT可以将方法放在topic最后，这样也便于统一的下发处理， 比如:home/bedroom/bedlight/rgb/set
总结
虽然MQTT和HTTP在实践中有非常大的差异，比如HTTP是请求->响应方式，其有丰富复杂的头部，有明确定义的状态码等。但是 topic 设计和 RESTful URI 设计很多是相通的思想，比如明确的资源路径、无状态、简洁明确、一致的命令字(REST通过方法表达)等。
啰嗦一句, 很多东西的道理都是相通的，个人对很多东西是否合理的基本判断是:
1. 看起来是否很明白
2. 用起来是否很顺利