目标:将业务逻辑和流程与电子商务购物车分开。我们很清楚，我们是一家规模较大的电子商务商店，但我们这里处理的流量绝不是大量的，每天只有几千名访客。
我们想要一个可维护的外部应用程序来处理诸如:PDF 生成、报价逻辑、发票和采购订单处理等事务。目前，这主要内置于我们的模块化购物车软件中，但为了实现更高的移动性、稳定性和可维护性，我们认为这是最好的方向。我们目前使用 LAMP 进行购物车，使用 MongoDB、Python 进行一些外部数据导入和处理。我们希望在这个特定的应用程序中使用 PHP，开发会更快，因为我们的大部分业务逻辑已经用 PHP 编写，只需要移植即可。
我确信这不是一个新问题。那么大多数较大的网站是如何做到的呢？是否最好使用 SOAP/REST 之类的东西在应用程序之间进行通信，或者这是否太慢，是否有必要构建直接由电子商务购物车使用的 PHP 库。
如果我有选择，我会做一个网络服务，但我担心开销会太大而无法实现。根据我的经验，我知道使用 UPS API 并不有趣!我倾向于将 REST 和 DAO 结合起来，我很想听听任何经历过这种情况或以前见过类似情况的人的意见。还可以添加我们可以使用消息队列，这对于需要花费大量时间的进程非常有用，但不适用于需要即时响应的事情......
最佳答案
协议(protocol)的性能可能是小问题，如果 Web 服务位于不同的计算机中，那么无论您使用什么协议(protocol)，计算机之间的延迟都将成为主要的性能瓶颈。
最好将服务器配置在同一网络中。与往常一样，在查询远程服务时，最好减少查询数量，相反，您应该将 API 设计为尽可能批量执行查询。
REST 或 SOAP 唯一可能的问题是它们没有直接的方法来执行推送通知，而是需要使用 Web Hook 。但这确实是一个小问题。
关于php - REST/SOAP 性能是否足够快，适合在 PHP 应用程序之间使用，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/16660344/