本地应用之间的RESTful通信是个好主意吗？

Question

我在想，让同一台服务器上的本地应用通过Restful API完全互相通信，这样做是否合适？

我知道这种做法并不罕见，因为我们已经有像CouchDB这样的应用，它们使用HTTP REST进行通信，即使是本地应用之间也如此。

但我想把这个想法提升到一个更高的层次，创建一些可以作为更大应用模块的应用，这些模块也可以是其他应用的模块，依此类推。换句话说，会有很多本地应用/模块通过Restful API进行通信。

这样一来，这些应用/模块可以用任何编程语言编写，并且它们可以在不同的服务器之间进行通信。

不过我有一些问题：

• 这样做合适吗？
• 它们之间的数据传输会不会很慢？
• 如果我这样做，那么每个应用/模块都必须是一个HTTP服务器，对吧？所以如果我的应用使用了100个应用/模块，那么每一个都必须是一个本地HTTP网络服务器，每个都在不同的端口上运行（比如http://localhost:81, http://localhost:82, http://localhost:83等等），对吗？
• 有没有什么最佳实践或者需要注意的地方？

Answer 1

关于使用RESTful解决方案来进行应用集成，我认为这是个好主意。在另一个问题中，我也表达过类似的看法。

• 如何在一个组织内部共享数据

Answer 2

这样做是个好主意吗？

是的。这种做法很常见。比如，所有的数据库服务器都是这样工作的。Linux里面有很多客户端/服务器应用程序，它们通过TCP/IP进行通信。

它们之间的数据传输会慢吗？

不会。TCP/IP使用localhost作为快捷方式，这样就不需要真正进行网络输入输出了。

HTTP协议虽然不是专门为专用连接设计的，但它简单且支持得很好。

如果我这样做，那么每个应用程序/模块都必须是一个HTTP服务器，对吧？

不一定。有些模块可以是客户端，而不需要作为服务器。

所以如果我的应用程序使用了100个应用程序/模块，那么每一个都必须是一个本地HTTP网络服务器，每个都运行在不同的端口上（比如 http://localhost:81, http://localhost:82, http://localhost:83，依此类推），对吧？

是的，就是这样。

有没有什么最佳实践或者需要注意的地方？

不要“硬编码”端口号。

不要使用“特权”端口号（1024以下的端口）。

使用WSGI库，这样你会更开心地把所有模块都做成WSGI应用。然后你可以用一个简单的两行代码的HTTP服务器来包装你的模块。

可以看看这个链接。http://docs.python.org/library/wsgiref.html#examples

Answer 3

• 这个主意好吗？

当然，可能是吧。

• 它们之间的数据传输会慢吗？

没错！但慢是相对于什么来说呢？和本地的内部调用比，绝对是慢得像冰一样。但和其他一些网络API比，可能不一定慢。

• 如果我这样做，那么每个应用/模块都得是一个HTTP服务器，对吧？所以如果我的应用用到100个应用/模块，我就得有100个本地HTTP服务器在运行，每个都用不同的端口（比如 http://localhost:81，http://localhost:82，http://localhost:83，等等）？

不，没必要为每个模块分配一个端口。有很多方法可以做到这一点。

• 有没有什么最佳实践或注意事项我应该知道的？

要让这个成功，唯一的办法就是你所说的服务要足够大。这些服务必须是那种大而复杂的黑箱服务，调用它们的成本才值得。每次交易你都会产生连接费用、数据传输费用和数据处理费用。所以，你希望这些交易尽可能少，数据量尽可能大，这样才能获得最大的好处。

你是在说实际使用REST架构，还是只是通过HTTP发送数据？（这两者是不同的）REST会产生自己的费用，包括嵌入的链接、常见的数据类型等等。

最后，你可能根本不需要这样做。它可能“挺酷的”，是“可有可无的”，在白板上看起来不错，但如果你真的不需要，那就别做。只需遵循良好的实践，隔离你的内部服务，这样如果你以后决定做这样的事情，你只需插入必要的连接层来管理通信等。增加远程分布会增加风险、复杂性，并降低性能（扩展不等于性能），所以做这件事必须有充分的理由。

这可以说是“最佳实践”中的最佳。

编辑 -- 对评论的回应：

所以你的意思是我运行一个网络服务器来处理所有的请求？但这样模块就不能独立运行了，这样就违背了初衷。我希望每个模块都能独立运行。

不，这并不违背初衷。

事情是这样的。

假设你有3个服务。

• http://store.example.com/service1

• http://blog.example.com/service2

• http://forum.example.com/service3

乍一看，可以说这三者是不同的服务，运行在三台不同的机器上，使用三台不同的网络服务器。

但实际上，这些服务可以都在同一台机器上，使用同一台网络服务器，甚至可以运行完全相同的逻辑。

HTTP允许你映射各种东西。HTTP本身就是一种抽象机制。

作为客户端，你只关心要使用的URL和要发送的数据。它最终与哪个机器通信，或者执行什么代码并不是客户端的问题。

在架构层面上，你实现了一种抽象和模块化。URL让你可以按照任何逻辑布局来组织你的系统。物理实现与逻辑视图是不同的。

这3个服务可以在一台机器上运行，由一个进程提供服务。另一方面，它们也可以代表1000台机器。你觉得有多少台机器响应“www.google.com”？

你可以轻松地在一台机器上托管这3个服务，而不需要共享任何代码，除了网络服务器本身。这使得将服务从原来的机器移动到其他机器变得简单。

主机名是将服务映射到机器的最简单方法。任何现代网络服务器都可以服务于任意数量的不同主机。每个“虚拟主机”可以在该主机的命名空间内服务于任意数量的单独服务端点。在“主机”级别上，如果需要，将代码从一台机器迁移到另一台机器是非常简单的。

你应该更多地探索现代网络服务器的能力，以将任意请求指向服务器上的实际逻辑。你会发现它们非常灵活。