说实话，干工业这行二十年，最烦的就是听人吹PPT上那套“万物互联”。等真到了车间，看到那些传感器、PLC、老式机床，你会发现——数据交互这事儿，远没有想象中那么光鲜。今天不聊大道理，就说说我在搞工业数据开放交互API接口时踩过的坑，和一点点心得。
先扔个观点：工业API和互联网API根本不是一回事。互联网接口挂了，用户刷新一下就好。工业接口要是秒级超时，产线上可能直接停线报警——对，就是这么残酷。所以你问我什么最重要？稳定，稳定，还是稳定。
一、别迷信协议，先问清楚现场有什么
刚接触工业数据时，我特别迷恋OPC UA，觉得它什么都好——跨平台、安全、语义建模，简直是工业通信的救世主。但后来在长三角一个汽配厂，我傻眼了。那车间里一半设备是十年前的西门子200PLC，压根不支持OPC UA，只能走Modbus TCP。当时项目要求把数据统一到MES，你让我怎么办？硬推OPC UA？那得换一堆控制器，预算直接爆炸。
所以，选接口方案第一件事，去车间摸底。看看设备支持什么协议，是老掉牙的Modbus RTU，还是带以太网的PROFINET，或者是那种你怎么都查不到资料的私有协议。然后，再决定是写驱动转换，还是中间加个网关。这过程没什么捷径，就是干。
不过话说回来，OPC UA依然是目前工业数据开放交互的主流——尤其是新建产线，尽量要求设备厂商支持UA。但注意，OPC UA的复杂度会吃掉你的性能，尤其是证书管理和信息模型订阅那套，搞不好能让你的网关CPU飙到100%。我吃过这亏，最后只能用传统OPC DA（现在叫UA的伴生规范）才压下来。
二、RESTful API？轻量，但别乱用
很多搞IT的同事喜欢把REST挂在嘴边，说什么“一切都是资源”。放在工业数据交互上，有时候真不合适。你想想，一台注塑机的实时压力，每秒采样1000次，你用REST GET一次拉一条？不现实吧。所以REST适合低频、配置类、查询类的数据——比如获取设备参数、下发工单。高频实时数据，还是走MQTT或者OPC UA的订阅模式。
我自己做过的方案里，用RESTful API封装了设备报警记录查询、生产工单下发，效果还不错。但有个坑得提醒——REST的语义和工业现场的数据模型常常对不上。比如你说URL是`/api/devices/001/data`，看上去很舒服，可“data”到底是哪个参数？温度？转速？还是整整一条历史曲线？这就得靠接口文档写得清清楚楚。人话就是，REST API的粒度和语义必须按业务场景设计，别套用互联网那套隐式规则。
顺带吐槽一下，有些供应商的所谓“开放API”，文档里全是“Exception Code: E12345，请参考附录”，附录里就一句话“请联系技术支持”——这种破事我遇见不下五次，每次都气得想砸键盘。你们做工业的，能不能把API文档写得像个正常人写的？
三、MQTT来了，但QoS和心跳别搞错
这两年MQTT在工业界火得不行，尤其是配合边缘网关。轻量、发布订阅、支持断线重连，确实适合传感器数据上云。但我得泼盆冷水：MQTT的QoS级别不是摆设。我见过有工程师把QoS全部设为2，结果在弱网环境下消息积压，网关直接内存溢出。后来我们统一规范：设备侧采集用QoS 0，关键指令用QoS 1，QoS 2能不用就不用——除非你有特殊需求。
还有心跳和遗嘱。很多搞嵌入式的人，压根不设置`KeepAlive`和`Will`，导致连接断了自己都不知道。你要知道，在工业现场，网络闪断是常事。有一次我们连的4G网关，信号差的时候一分钟断五六次，如果没有合理的重连机制，数据丢到你怀疑人生。后来给MQTT客户端加了自动重连和消息缓存，才勉强稳住。
说这些不是否定MQTT，而是想说——协议选型，一定要结合现场网络条件和数据特性。别听厂商吹“万金油”，没有万金油。
四、关于接口设计的玄学——超时、重试和幂等
终于聊到代码层了。工业API最核心的三个破事儿：超时、重试、幂等。
**超时**。默认超时你要么设短了，要么设长了。设短了，现场网络稍微抖一下，请求就失败；设长了，一旦设备卡住，接口线程池就被占满，整个系统瘫痪。我一般建议，外部API调用超时在网络良好的情况下5秒，特殊的大数据量查询可以放宽到30秒，但必须用异步。而且——对，就是这里——超时时间一定要可配置，别写死在代码里。我见过有人把超时写死3秒，结果在某个老车间里，Modbus轮询周期都2秒多，那还不天天报错？
**重试**。人总有手滑的时候，但重试不是简单的“再调用一次”。要看场景。比如给PLC下发启动命令，如果你重试两次，可能因为网络延迟导致命令重复执行——PLC可能会误操作。所以写操作必须考虑幂等性。常用方法是在请求里带一个唯一的消息ID，服务端记录这个ID，重复请求直接返回上次结果。这个ID我们习惯用`UUID`或者`时间戳+随机数`。别用自增ID，记住没？
**幂等**。除了上面说的方法，还有更偷懒的——把请求体里的数据本身当作幂等条件。比如按批次号、时间戳去重。不过工业场景往往有现场总线时序问题，最安全还是显式ID。
五、安全这东西，别裸奔
工业数据以前是“内网隔离”，现在动不动就上云，安全可不能光靠VPN。我见过不少工厂，API接口直接裸奔在公网上，连个token都没有。这不是等着被勒索吗？实际上，工业API起码要做三层：传输层TLS加密、应用层认证授权、数据层脱敏。TLS别用SSLv3，那都是旧黄历了。认证推荐OAuth2.0或API Key，但API Key最好有有效期，别一签管十年。
另外有个细节：很多工业API的日志，会把用户名密码直接打出来。我去过一家设备厂商，他们的调试接口，`curl -v`一下居然能看到明文口令——这简直是灾难。记住，日志里永远别打印敏感信息，这不光是为了规范，是为了保命。
结语
说了这么多，其实核心就一句话：工业数据开放交互API接口，不是写几个HTTP端点那么简单，它是连接物理世界和数字世界的桥。桥断了，数据就是孤岛。别贪新潮，别信大全，把基础细节做到位，比什么都强。
好吧，今天先扯到这儿。回头我再写一篇关于OPC UA信息模型怎么建的实操文章，到时候再聊。
