SOAP到REST转换：新鲜还是重用？

Question

我的团队的任务是将应用程序的现有SOAP API转换为REST。我倾向于从头开始重新编写API（仅重用每个操作执行的实际业务逻辑）。我团队中的其他人希望将REST作为现有SOAP的包装器。这意味着我们将公开REST服务，但是当我们的应用程序中出现请求时，内部将调用现有的SOAP操作。

请您就哪一种最佳方法提出建议？看起来我的方式更干净，更轻，更快，但他们的方式允许一些代码重复使用。

Answer 1

这取决于您的优先级和天气，您将收到过多的API行为变更请求。

• 预计会有充足的时间和更多的变化：

  

如果你有时间，当然建议从头开始写作   它意味着更清洁，更轻，更快。这也将使   轻松发布新功能。

• 减少预期的时间和更少的变化。 API太大而无法进行回归测试：

  

但如果你有时间限制，我建议你去REST   SOAP api。无论如何，你只会向客户端公开REST api，所以   你可以在内部重构和逐步淘汰SOAP   时间允许你。改变整个代码意味着回归测试   整个模块

Answer 2

您必须将REST调用转换为SOAP调用才能重用当前代码这一事实肯定会对我进行重写！

为了使测试，调试和分析更容易，您应该拥有一个由REST API调用的基于POJO的纯API。

您使用的是哪种后端服务器？由于一些比较流行的Java Web服务器具有使创建REST API非常容易的工具。

Answer 3

  

请您提供一些关于哪些是最好的建议   进场？看起来我的方式更清洁，更轻，更快但是   他们的方式允许一些代码重用。

我编写了一个执行SOAP的框架 - ＆gt; REST转换。它曾在我曾经工作过的公司内部使用过。该框架能够在不到10分钟的时间内使用映射文件执行此操作，但我们并未将其用于所有服务。这就是为什么......

• 并非所有服务（基于WSDL）都是基于REST设计的。其中一些只是在服务上调用的远程方法，仅此而已。
• 该服务可能没有可以映射的resources。
• 即使有资源，它们也可能无法正确映射到REST（GET / POST等），而且有些调用不易翻译。
• 映射框架具有自己的开销。框架的SLA非常低（单位数毫秒），但即使很小的开销也可能不适合关键服务。不应低估分析和降低开销所需的时间。

总之，该方法适用于某些服务，但需要一些工程努力才能实现。如果您已经说过需要在短时间内快速转换的500多项服务，那么这样做是有意义的。