接口协议基础（上）：HTTP/HTTPS协议详解、RESTful API设计原则、JSON/XML数据格式对比
各位好，我是老张。在MES这个行当摸爬滚打了十几年，要说最基础也最绕不开的，就是接口协议。你想想看，MES系统要跟ERP、PLC、SCADA、WMS这些兄弟系统打交道，没有一套靠谱的协议，数据根本传不通。今天咱们就聊聊HTTP/HTTPS、RESTful API和JSON/XML这些老面孔。
一、HTTP/HTTPS协议：MES通信的"普通话"
HTTP协议，说白了就是Web世界的通用语言。MES系统跟外部系统交互，大部分时候用的就是它。我刚开始做集成那会儿，总觉得HTTP就是个简单的请求-响应模型，后来踩了坑才发现，里面的门道真不少。
1. HTTP的核心机制
HTTP是"无状态"的协议。什么意思？就是每次请求都是独立的，服务器不记得你是谁。这在MES场景下其实是个优点——你想想，产线上的设备成千上万，每个设备发个请求，服务器要是都得记住状态，那内存早爆了。
但无状态也有麻烦。比如用户登录后，每次操作都得重新验证身份。所以后来有了Cookie和Session，再后来有了Token。我个人习惯在MES接口中用JWT（JSON Web Token），轻量、无状态，适合工业场景。
| HTTP方法 | MES中的典型场景 | 示例 |
|---|---|---|
| GET | 查询工单状态、获取设备参数 | GET /api/orders/status?orderId=123 |
| POST | 创建工单、上报生产数据 | POST /api/orders |
| PUT | 更新物料批次信息 | PUT /api/materials/batch/456 |
| DELETE | 删除无效的质检记录 | DELETE /api/quality/records/789 |
2. HTTPS：给数据加把锁
HTTPS就是HTTP + SSL/TLS。为什么MES要用HTTPS？我遇到过一件事：某工厂的MES跟ERP之间传工单数据，用的HTTP。结果有一天，生产计划莫名其妙被改了，查了半天才发现是中间人攻击。从那以后，凡是涉及生产指令、质量数据、成本信息的接口，我全部强制HTTPS。
HTTPS的握手过程其实挺有意思。客户端先发个"你好"，服务器回个证书，客户端验证证书，然后双方协商一个对称密钥。之后的通信就用这个密钥加密。嗯，这里要注意：证书的有效期、CA的可信度，这些都得检查。我曾经见过一个项目，证书过期了三个月没人管，接口一直报错，排查了两天才发现。
二、RESTful API设计原则：让接口"好懂"又"好用"
RESTful API，现在几乎是MES集成的标配。为什么？因为它简单、直观、符合直觉。你想想，一个资源（比如工单、物料、设备），用URL表示，用HTTP方法操作，多清晰。
1. 资源命名：用名词，别用动词
这是RESTful设计的第一条铁律。比如获取工单列表，应该是GET /api/orders，而不是GET /api/getOrders。我见过不少新手把接口写成/api/createOrder、/api/deleteOrder，这其实是在用RPC的思路写REST，不伦不类。
资源命名还有一些约定俗成的规则：
- 使用复数名词：
/api/orders而不是/api/order - 层级关系用斜杠：
/api/orders/123/items表示工单123下的物料项 - 查询参数用于过滤：
/api/orders?status=completed&date=2024-01-01
2. 状态码：别偷懒，用对码
HTTP状态码是RESTful API的"表情"，告诉客户端请求结果如何。我见过最坑的接口，不管成功失败，一律返回200，然后在响应体里写个{"code": 0, "msg": "success"}。这种做法，说白了就是给自己挖坑。
正确的做法：
- 200 OK：请求成功
- 201 Created：资源创建成功（比如POST创建工单）
- 400 Bad Request：客户端请求有误（比如参数缺失）
- 401 Unauthorized：未认证
- 403 Forbidden：无权限
- 404 Not Found：资源不存在
- 500 Internal Server Error：服务器内部错误
3. 版本控制：给接口留条后路
MES系统上线后，接口不可能一成不变。今天加个字段，明天改个逻辑，后天换个数据源。如果没有版本控制，一改接口，所有调用方都得跟着改，那场面...想想就头疼。
我常用的方式是在URL中加版本号：/api/v1/orders、/api/v2/orders。这样新旧版本可以共存，调用方可以逐步迁移。当然，也有用请求头（如Accept: application/vnd.mes.v1+json）的，但我觉得URL方式更直观，调试起来也方便。
三、JSON/XML数据格式对比：选对格式，事半功倍
数据格式，就是接口传输的"语言"。JSON和XML是两大主流。MES集成中，JSON用得越来越多，但XML在某些场景下依然不可替代。
1. JSON：轻量、灵活、好解析
JSON的优势很明显：体积小、结构清晰、解析速度快。你看下面这个工单数据的JSON表示：
{
"orderId": "WO-2024-001",
"productName": "轴承套圈",
"quantity": 500,
"status": "in_progress",
"startTime": "2024-01-15T08:00:00Z",
"operations": [
{"step": 1, "name": "车削", "duration": 120},
{"step": 2, "name": "热处理", "duration": 180}
]
}一眼就能看懂，对吧？而且JavaScript、Python、Java这些语言解析JSON都特别方便。我个人习惯在MES接口中优先使用JSON，除非有特殊要求。
2. XML：严谨、可扩展、有标准
XML虽然看起来啰嗦，但它的优势在于严谨。有Schema约束，有命名空间，支持复杂的数据结构。在MES跟ERP（尤其是SAP）集成时，XML还是很常见的。
同样的工单数据，用XML表示：
<Order>
<OrderId>WO-2024-001</OrderId>
<ProductName>轴承套圈</ProductName>
<Quantity>500</Quantity>
<Status>in_progress</Status>
<StartTime>2024-01-15T08:00:00Z</StartTime>
<Operations>
<Operation>
<Step>1</Step>
<Name>车削</Name>
<Duration>120</Duration>
</Operation>
<Operation>
<Step>2</Step>
<Name>热处理</Name>
<Duration>180</Duration>
</Operation>
</Operations>
</Order>你看，XML的标签是成对出现的，结构非常清晰。但缺点也很明显：冗余信息多，同样的数据，XML的体积可能是JSON的2-3倍。
3. 怎么选？我的经验
没有绝对的"好"与"坏"，只有"合适"与"不合适"。我一般这样判断：
- 新系统对接：优先用JSON。开发效率高，调试方便。
- 跟传统ERP（SAP、Oracle EBS）对接：大概率要用XML。这些老系统对XML支持更成熟。
- 需要严格数据校验：XML + XSD Schema更合适。比如质量数据、批次追溯数据，容不得半点差错。
- 移动端或IoT设备：必须用JSON。带宽有限，解析能力有限，JSON更友好。
Accept字段。客户端想要JSON就传Accept: application/json，想要XML就传Accept: application/xml。服务端根据这个字段返回对应格式。这叫"内容协商"，RESTful API的标准做法。
四、知识体系总览
说了这么多，咱们用一张图把今天的内容串起来。这张图展示了HTTP/HTTPS、RESTful API和JSON/XML在MES集成中的位置和关系。
这张图把今天讲的内容串起来了。从上往下看：MES集成接口在最顶层，下面分三大块——传输协议、设计风格、数据格式。每一块都有各自的要点和适用场景。你想想看，实际做集成的时候，这三块缺一不可。协议选错了，数据传不过去；风格设计差了，接口难维护；格式选错了，解析效率低。
好了，今天的内容就到这儿。接口协议这块，说白了就是"选对工具、用对方法"。下次咱们聊接口调试工具和实战技巧，到时候拿几个真实案例来拆解，更有意思。