本地应用程序之间的安全通信是一个好主意？
我想知道让本地应用程序（在同一台服务器上）完全通过Restful API相互通信是否是一个好主意？
我知道这并不罕见，因为我们已经有了使用HTTP REST进行通信的应用程序，例如CouchDB，即使是本地应用程序也是如此。
但是我想通过创build类似于更大应用程序模块的应用程序来实现更高级别的应用程序，也可以将其作为另一个应用程序的模块等等。 换句话说，会有很多本地应用程序/模块正在与Restful API进行通信。
通过这种方式，这些应用程序/模块可以使用任何语言，并且可以通过服务器之间的线路进行通信。
但是我有一些问题：
- 这是一个好主意吗？
- 他们之间的数据传输会慢吗？
- 如果我这样做，那么每个应用程序/模块必须是一个HTTP服务器？ 因此，如果我的应用程序使用100个应用程序/模块，那么每个应用程序必须是本地HTTP Web服务器，每个服务器运行在不同的端口上（http：// localhost：81， http：// localhost：82 ， http：// localhost ：83等等）对不对？
- 任何我应该知道的最佳实践/陷阱？
- 这是一个好主意吗？
当然，也许。
- 他们之间的数据传输会慢吗？
对！ 但是比较起来呢？ 相比本地，内部呼叫，绝对 – 这将是冰河。 相比其他一些networkingAPI，呃不一定慢。
- 如果我这样做，那么每个应用程序/模块必须是一个HTTP服务器？ 因此，如果我的应用程序使用100个应用程序/模块，我必须有100个本地HTTP Web服务器启动并运行每个不同的端口（http：// localhost：81， http：// localhost：82 ， http：// localhost：83和等等）？
那么，没有理由分配每个模块的端口。 各种各样的方式来做到这一点。
- 任何我应该知道的最佳实践/陷阱？
如果你所说的服务足够粗糙，唯一的办法就是成功。 这些必须是大型的，黑盒子的服务，这使得他们称为值得的费用。 您将在每次交易中产生连接成本，数据传输成本和数据编组成本。 因此，您希望这些交易尽可能less，并且您希望有效载荷尽可能大以获得最佳效益。
你是说使用REST架构，还是通过HTTP来回发送内容？ （这些是不同的东西）REST会产生自己的成本，包括embedded式链接，无处不在和常见的数据types等等。
最后，你可能不需要这样做。 这可能是“挺酷的”，“很高兴有”，“在白板上看起来不错”，但如果真的不需要，那就不要这样做。 只需遵循隔离内部服务的良好实践，以便稍后决定如何执行此类操作，就可以插入pipe理通信所必需的粘合层。添加远程分发将增加风险，复杂性和较低的性能（缩放！=表演），所以应该有一个很好的理由去做。
这可以说是所有人的“最佳做法”。
编辑 – 对评论的回应：
所以你的意思是我运行一个Web服务器来处理所有传入的请求？ 但是，这些模块不会是独立的应用程序，而是完整的目的。 我希望每个模块都能够自行运行。
不，它并没有达到目的。
这是交易。
假设你有3个服务。
一眼就可以说，这是三种不同的服务，在三个不同的机器上运行，在三个不同的Web服务器上运行。
但事实是，这些都可以运行在相同的机器上，在同一个Web服务器上，甚至可以运行在完全相同的逻辑上。
HTTP允许你映射各种各样的东西。 HTTP本身就是抽象机制。
作为一个客户端，你所关心的是要使用的URL和有效载荷。 什么机器结束了谈话，或者它执行的实际代码不是客户端问题。
在架构层面，您已经实现了抽象和模块化的方式。 url让你组织你的系统是任何你想要的逻辑布局。 物理实现不同于逻辑视图。
这3种服务可以在单个进程中运行的单台机器上运行。 另一方面，他们可以代表1000台机器。 您认为有多less台机器回应“www.google.com”？
您可以轻松地在一台机器上托pipe所有3种服务，无需共享任何代码，保存Web服务器本身。 使服务从原始机器移动到其他机器变得容易。
主机名是将服务映射到机器的最简单的方法。 任何现代Web服务器都可以服务于任何数量的不同的主机 每个“虚拟主机”可以为该主机的名称空间内的任意数量的单个服务端点提供服务。 在“主机”级别，将代码从一台机器重新定位到另一台机器时，如果必须的话，它是微不足道的。
您应该探索更多现代Web服务器的function，将任意请求引导到服务器上的实际逻辑。 你会发现他们非常灵活。
这是一个好主意吗？
是。 这是一直做的。 例如，这就是所有数据库服务器的工作原理。 Linux充满了通过TCP / IP进行通信的客户机/服务器应用程序。
他们之间的数据传输会慢吗？
TCP / IP使用localhost作为一个捷径，以节省做实际的networkingI / O。
HTTP协议不是专用连接的最佳select，但它很简单，支持也很好。
如果我这样做，那么每个应用程序/模块必须是一个HTTP服务器？
不必要。 一些模块可以是客户端，没有服务器。
因此，如果我的应用程序使用100个应用程序/模块，那么每个应用程序必须是本地HTTP Web服务器，每个服务器运行在不同的端口上（http：// localhost：81， http：// localhost：82 ， http：// localhost ：83等等）对不对？
是。 这是它的工作方式。
任何我应该知道的最佳实践/陷阱？
不要“硬编码”端口号。
不要使用“特权”端口号（1024以下）。
使用WSGI库，你会很高兴地把你所有的模块都变成WSGI应用程序。 然后你可以使用一个简单的2行HTTP服务器来包装你的模块。
在使用应用程序集成的稳定解决scheme时，我认为这是一个好主意，并在另一个问题上提出了类似的观点。
- 如何在组织间共享数据
坦白说，我不认为你需要100个服务器100个应用程序，也许只是在同一台服务器上使用100个端口。
而且，RESTful接口将使您能够灵活地扩展服务器并实现负载均衡，如果您想要将其扩展到巨大的潜力。
不，如果你没有很好的理由，这不是一个好主意。 将应用程序的代码分层是一个好主意，以便在需要时可以在稍后的阶段“rest”。 （或者无论性能改善是否被认为是必要的）。“基于服务器的层”的增加的部署复杂性是不这样做的好理由。 我会build议：
- 用良好，干净的代码编写结构良好的应用程序。
- 用预期的生产负荷进行testing
- 如果需要的话 – 重构成服务器层 – 但是…..
更好的方法是负载均衡整个应用程序。 如果您在应用程序服务器中执行类似rails的任何状态，那么并行运行多个实例应该不成问题。
如果你正在寻找复杂性 – 无视我的答案。 🙂