企业系统接口对接协议，风格上主要分两种，风格上主要分两种：RESTful请求响应和消息驱动异步。选择标准不是哪个更流行，而是看业务对实时性的要求和双方系统的解耦需求。选错风格，要么响应慢，要么耦合死。下面从特征、选择标准、协议设计三方面讲清。

两种风格的特征

RESTful请求响应

REST风格是"调用方主动请求，被调方立即返回"。A系统发一个HTTP请求到B系统的URL，B处理完同步返回结果。整个过程是阻塞的——A在等B响应期间什么都不能做。

这种风格的好处是简单直观：一个URL、一个HTTP方法（GET/POST）、一段JSON数据，调通了就能用。调试方便，浏览器或Postman直接模拟。哈尔滨企业内部系统之间、需要立即拿到结果的查询类接口（查库存、查订单状态），基本都用REST。

REST还有一个好处：无状态。每次请求带全参数，服务端不记会话，水平扩展容易。缺点是请求方要处理超时、重试、幂等，这些都得自己设计。

消息驱动异步

消息风格是"A发个消息到队列就走，B什么时候处理、处理完怎么通知A，都异步进行"。A不等待B的响应，甚至不知道B是谁。B处理完如果需要通知A，再反过来发一个消息。

这种风格解耦程度高：A和B不需要同时在线，B挂了消息在队列里存着，B恢复后继续消费。适合耗时操作（生成报表、发通知、批量处理）。缺点是调试复杂，看不到"谁调用了谁"，要靠日志和链路追踪排查。

消息驱动还要配消息顺序保证。订单创建、支付、发货三个事件必须按顺序消费，不能乱序。Kafka这类中间件支持按key分区，同一订单的消息进同一分区，保证顺序。

实际项目中，REST和消息经常搭配使用。核心查询用REST（要立即拿结果），状态变更通知用消息（解耦）。一个系统对外提供的接口里，两种风格并存是常态。

对接文档还要包含错误码表。每个错误码什么含义、调用方该怎么处理，都写清楚。不要只返回一个HTTP 500，调用方根本不知道是参数错了还是服务挂了。

选择标准

实时性与解耦需求

判断用哪种风格，先问两个问题：第一，调用方需要立即拿到结果吗？需要（如下单时校验库存）就用REST，等不了异步。第二，调用方能接受下游系统挂掉吗？不能接受下游挂（如下单必须同步扣库存）用REST加重试；能接受下游稍后处理（如下单后发短信）用消息队列。

实时性和可靠性是两个维度。REST天然实时但脆弱（网络一抖就失败），消息天然可靠但有延迟。哈尔滨企业的核心交易链路用REST+补偿机制，外围通知链路用消息队列，是常见组合。

调用方能力差异

还要看对接方的技术能力。如果对方是老系统、没有开发资源，让他部署消息队列不现实，那就用REST——他只要会发HTTP请求就行。如果双方都是现代系统、团队能力强，用消息队列能减少耦合。

另外，对接方数量也影响选择。一个上游对十个下游，用消息队列广播，上游只发一次；用REST，上游要循环调十次，任一失败都要重试。

协议设计要点

数据格式约定

不管用哪种风格，数据格式要统一。推荐JSON：字段名用小写下划线（order_id），时间统一用毫秒时间戳或ISO 8601格式，金额用整数（单位分）避免浮点误差。不要一个接口用XML、另一个用JSON，对接两边都累。

版本管理策略

接口会变，但不能一变就把老调用方搞挂。URL里带版本号（/api/v1/orders），新版本走v2路径，老版本保持三个月以上兼容期。哈尔滨企业的系统对接往往涉及三方甚至四方，没有版本管理，一方升级全链路崩。

对接协议还要配联调环境。双方各起一套测试环境，在测试环境里把接口调通，再上生产。不要直接在生产环境联调，出了问题影响真实业务。

接口对接最容易忽略的是文档。双方都以为对方知道，结果联调时鸡同鸭讲。一份写清楚的对接文档，能省一半联调时间。

接口版本升级时，要给老调用方留过渡期。v2上线后，v1至少保留三个月，通知调用方切换。一刀切停掉v1，老系统全崩。

接口安全也要做。不能谁都能调，要有鉴权token、IP白名单、请求签名。接口暴露在公网，没有防护就是后门。

联调时还要模拟异常。网络超时、服务不可用、参数错误，这些场景都要测。正常流程调通不算完，异常处理也要验证。

对接文档还要有示例。每个接口给一个真实的请求和响应示例，调用方照着填就行。光说参数名，对接方还是要猜。

接口上线后还要做监控。调用量多少、成功率多少、响应时间多少，都要监控。异常了自动告警，不要等业务部门报错才知道。

对接协议的细节决定联调效率。文档越细，联调越快；文档越粗，来回沟通越多。

接口对接是系统集成的基本功。基本功扎实，后面扩展才省心。

对接协议写好后，要形成一份联调文档：每个接口的URL、参数、返回值、错误码、示例请求响应。双方按文档联调，不要靠口头描述。