REST在事务与传输可靠性上的局限源自协议选择而非缺陷

两条常见的”REST不行”批评，拆开看会发现根源不在REST本身。”REST不利于事务 支持”：如果指的是数据库式刚性ACID事务，只要系统持有状态就与分布式天然 矛盾（CAP不可兼得），这是分布式系统的通病而非REST的错；如果指的是像 WS-AtomicTransaction那样跨服务的统一提交协调能力，REST确实不支持，需要 时该选Web Service；如果只是要最终一致性，用REST完全没有阻碍，只是REST 本身对此也没有额外帮助，事务设计终究取决于系统架构而非协议。”REST没有 传输可靠性支持”：确实没有，收不到响应时无法判断请求到底有没有被处理。 最简单的应对是重发请求，但这要求服务具备幂等性（重复执行效果等于执行 一次）——HTTP协议本身就要求GET、PUT、DELETE具备幂等性，映射到这些方法 上的REST服务因此天然具备了重发兜底的基础，POST则需要业务层自己做预校验 或返回425状态码。这两条局限的共同教训是：评价一个技术选型的”缺点”前， 要先分清这是它本身的设计缺陷，还是它所选协议/场景带来的固有约束。