内部REST API

Question

我们目前在我们的网络中有三个站点.一个用Ruby on Rails编写,另外两个用PHP编写.所有站点都倾向于共享许多相同的数据和逻辑.我发现自己不得不在PHP端重复我在rails上做的很多工作.似乎我们需要一个通用的内部API来巩固它.我以前从未构建过API,但我有几个问题.

• 性能如果我将API构建为单独的应用程序,似乎这将是两倍的速度.因为它必须经过API端的整个请求/响应周期,然后再次在公共应用程序端.有没有办法让这更快？或者可能采用不同的方法？

• 通过本地网络访问API如何通过本地网络访问API？我会在Apache中设置一个指向127.0.0.1的虚拟主机吗？

• 主动资源在我的情况下(在rails端),ActiveResource是最好的方法,还是有更好的消费API的选择？我也想知道验证如何在公共方面起作用.ActiveResource是重用验证规则还是我必须在公共端重新创建它们？

• API安全性我认为我现在不必过于担心这一点,因为API只能通过本地网络访问(理想情况下).我在这个假设中是否正确？

Answer 1

有整本书都讨论了这个特定的主题。创建服务时处理延迟、稳定性、灵活性和所有其他问题的管理。

从非常普遍的角度来看，以及听起来相对简单的用例，我会在每个应用程序中推荐简单的、基于 REST 的 API。您绝对不想在 PHP 中重复已经用 Ruby 编写的代码，反之亦然。相互竞争的基于 HTTP 的查询方法之间的响应时间不会相差太多（无论如何，不​​像谈论 HTTP 与 CORBA 那样显着）。编写 REST 资源是 Ruby on Rails 的强项，因此您几乎可以将其作为一种礼物。PHP 有点难，您只需按照遵循 REST 标准的方式构建可查询的 API 即可。之后，您只需要一个 HTTP 客户端即可对任一客户端发出请求。如果您为每个应用程序都有明确定义的端点，那么对它们进行硬编码应该不会有太大问题。如果没有，围绕企业服务总线还有另一种完整的设计模式，可以帮助一个服务找到另一个服务，但通常不具有跨平台功能（至少，不是 PHP 与 Rails 之间的交互——据我所知，那是！）。

对于 Ruby/Rails 世界，我可以推荐 HTTParty 或 Typheous 作为 HTTP 客户端（它将查询其他应用程序的 REST 客户端）。对于 PHP 世界，您可能想看看这个线程。它列出了一些。

需要明确的是，这不是您唯一的选择 - 您可以创建完整的 Web 服务，甚至可以通过创建直接套接字连接等来更深入。这实际上完全取决于您希望系统耦合的紧密程度、它们可以耦合的紧密程度、它们的接近程度（在“网络拓扑”意义上）以及每个系统必须给出的响应速度。

关于安全性：一种选择是在每个系统上设置防火墙，仅接受来自特定 IP 的特定资源的连接。您可以在应用程序级别遵循类似的模式。尽管您可能同样幸运地使用基本/摘要身份验证来保护标准 HTTPS 会话。

希望这可以帮助。我可以继续讨论这个问题更长的时间，但我不知道有什么好方法可以对这个一般性问题给出一个具体的答案。如果有什么我可以扩展的，请随时发表评论，我会尽我所能。