REST架构下：预订微服务设1个还是2个端点更合理？

从REST架构的核心原则（资源导向、端点语义单一）来看，强烈推荐你倾向的第二种方案：只暴露一个POST /bookings端点，理由如下：

• 符合资源语义一致性：预订是一个完整的业务实体，不管数据拆分存储在本地数据库还是第三方服务，本质都是完成「创建预订」这一个核心业务动作。拆分两个端点会让客户端产生困惑——为什么创建一个预订需要调用两个接口？这违背了REST中「资源是单一业务实体」的设计思路。
• 简化客户端交互：客户端仅需调用一次接口就能完成完整预订流程，无需关心后端数据的存储拆分细节，既降低了客户端开发复杂度，也减少了跨接口调用的出错概率。
• 保障业务流程一致性：在单一端点内处理本地数据库写入与第三方服务调用，能更方便地控制业务逻辑的完整性（比如加入重试机制、补偿逻辑处理第三方调用失败的场景）。如果拆分两个端点，客户端需要自行处理两次调用的一致性问题，极易出现「本地有预订记录但第三方预订失败」的不一致状态。

实现该端点时需要注意几个细节：

• 做好异常处理：若第三方服务调用失败，需考虑回滚本地数据库记录，或标记该预订为「待处理」状态，后续通过异步任务重试。
• 可引入异步化逻辑：如果第三方服务调用耗时较长，端点可先返回预订创建的初步结果，再由后台异步完成第三方服务调用，避免客户端等待过久。

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