供应商拟用非REST HTTP接口替代约定REST接口，寻求技术建议

这种情况我之前也碰到过几次——已经有稳定运行的REST API在支撑主应用，供应商突然要换非REST的HTTP方案，确实头疼。下面是我总结的一些实用建议，希望能帮到你：

1. 先弄明白供应商想换方案的核心原因 #

不要上来就拒绝，先沟通清楚他们的痛点：

• 如果是觉得REST的资源定位、无状态这些约束，在他们的UI场景下不好用（比如需要批量操作、复杂多条件查询或者实时交互），那其实不用完全推翻REST——可以针对性优化现有API，比如加批量处理端点（POST /resources/batch）、灵活的查询参数组合，或者补充WebSocket来满足实时需求。
• 如果是他们团队对REST不熟悉，更习惯RPC风格的HTTP接口（比如直接POST /executeUserAction这种命令式接口），那可以考虑做适配层，而不是换掉现有API。

2. 量化现有API的迁移成本，摆上台面沟通 #

你的主应用已经在使用这套REST API了，完全替换的成本非常高：

• 要算清楚迁移需要的人天、测试成本、可能的业务 downtime风险，把这些量化的数据拿出来和供应商、你的内部团队沟通，让大家清楚全面替换的代价。
• 最好的折中方案是让供应商自己做适配层服务：他们写一个轻量的中间层，把你的REST API转换成他们想要的非REST接口格式。这样你的主应用完全不受影响，他们也能按自己的习惯开发，两边都不用妥协太多。

3. 不管用哪种风格，严格约定接口契约 #

如果最终还是要支持非REST接口，一定要把规则说死：

• 用**OpenAPI（Swagger）**定义所有接口的请求/响应结构、错误码、认证方式，确保两边对接口的理解完全一致，避免后期扯皮。
• 对齐现有体系的规范：比如状态码要正确使用（别不管成功失败都返回200）、认证方式和现有REST API保持一致（比如JWT、API Key），尽量减少后期维护的复杂度。

4. 提醒供应商注意非REST接口的长期维护风险 #

非REST的HTTP接口如果没有规范约束，很容易变成“大泥球”：

• 每个接口都是为特定业务写的命令式接口，后期新增功能或者改需求时，会出现大量重复逻辑，维护成本会翻倍。要把这个风险明确告诉供应商，对比REST风格的可扩展性优势。
• 如果你们需要长期维护这套API，尽量避免同时维护两套不同风格的接口，除非有非常充分的业务理由。

5. 协商折中：在现有REST基础上补充非REST端点 #

如果供应商的需求确实合理（比如REST确实满足不了某些特殊场景），可以考虑增量扩展：

• 只针对他们的特殊需求新增少量非REST端点，比如复杂的批量操作、跨资源的业务命令，其他场景还是用现有REST API。这样既满足了供应商的需求，又不用推翻现有成熟的体系。

内容的提问来源于stack exchange，提问作者Alex Arre