内部 REST API
目前，我们的网络中有三个站点。一个是用 Ruby on Rails 编写的，另外两个是用 PHP 编写的。所有站点往往共享许多相同的数据和逻辑。我发现自己必须在 PHP 方面重复我在 Rails 方面所做的很多工作。看来我们需要一个通用的内部 API 来巩固这一点。我以前从未构建过 API，我有几个问题。
性能 如果我将 API 构建为单独的应用程序，速度似乎会慢一倍。因为它必须在 API 端经历整个请求/响应周期，然后在公共应用程序端再次经历。有没有办法让它更快？或者也许是不同的方法？
通过本地网络访问 API 我如何通过本地网络访问 API？我需要在 Apache 中设置一个指向 127.0.0.1 的虚拟主机吗？
Active Resource 就我而言（在轨道端）ActiveResource 是最好的方法还是有更好的选择来使用 API？我还想知道验证将如何在公共方面进行。 ActiveResource 是否重用验证规则，还是我必须在公共端重新创建它们？
API 安全性 我想我现在不必太担心这个问题，因为 API 只能（理想情况下）通过本地网络访问。我的这个假设是否正确？
We currently have three sites in our network. One written in Ruby on Rails and the other two written in PHP. All of the sites tend to share a lot of the same data and logic. I find myself having to repeat a lot of the work I do on the rails side on the PHP side. Seems like we need a common internal API to consolidate this. I've never built an API before and I have a few questions.
Performance If I build the API as a separate application, it seems like this is going to be twice as slow. As it has to go through the entire request/response cycle on the API end and then again on the public application side. Is there a way to make this faster? Or maybe a different approach?
API access via local network How would I access the API via the local network? Would I setup a virtualhost in Apache that points to 127.0.0.1?
Active Resource In my case (on the rails end) is ActiveResource the best way to go or are there better options for consuming the API? I'm also wondering how validations will work on the public side. Does ActiveResource reuse the validation rules or will I have to recreate them on the public side?
API Security I'm thinking that I won't have to worry too much about this right now since the API can only be accessed (ideally) via the local network. Am I correct in this assumption?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（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 会话。
希望这有帮助。我可以继续讨论这个问题更长的时间，但我不知道有什么好方法可以对这个一般性问题给出一个具体答案。如果有什么我可以扩展的，请随时发表评论，我会尽我所能。
There are whole books that have tackled this particular topic. Dealing with managing latency, stability, flexibility and all the other -ilities when creating services.
From a very general standpoint, and the relatively simple use case that it sounds like you have, I would recommend simple, REST based APIs in each application. You definitely don't want to repeat code in PHP that is already written in Ruby, and vice versa. Response times wont very too much between competing HTTP based query methods (not as drastically as it would when talking about something like HTTP vs CORBA, anyways). Writing up REST resources is what Ruby on Rails is good at, so you pretty much have that as a gimme. PHP is a bit harder, and you just have to structure your queryable API in such a way that it follows REST standards. After that, you just need an HTTP Client to do requests against either client. If you have well defined end points for each application, that shouldn't be too much of a problem to hard code them. If not, there's another whole design pattern around enterprise service buses that help one service find another, but doesn't generally have cross platform capability (at least, not PHP to-and-from Rails-wise-- That I am aware of, that is!).
For the Ruby/Rails world, I can recommend HTTParty or Typheous as HTTP Clients (that will query the REST client of the other application). For the PHP world, well, you may want to peek at this thread. It has a few listed.
To be clear, this isn't your only option- You could create full on web services, and even go deeper yet by creating direct socket connections, et al. It really all depends on just how tightly coupled you want the systems to be, how tightly coupled they can be, how close they are (in a "network topology" sense), and how fast of a response each system has to give.
Regarding Security: One option would be to set up your firewall on each system to only accept connections going to a particular resources if they're from a particular IP. You could follow a similar pattern at an application level. Though you might have just as much luck with securing a standard HTTPS session with basic/digest auth.
Hope this helps. I could go on about this for much longer, but I don't know that there's any good way to give one specific answer to this general of a question. If there is something I can expand on, feel free to comment and I will as I can.