內部REST API

Question

我們目前在我們的網絡中有三個站點。一個用Ruby on Rails編寫，另外兩個用PHP編寫。所有這些網站都傾向於共享大量相同的數據和邏輯。我發現自己不得不重複我在PHP方面的許多工作。好像我們需要一個通用的內部API來整合這一點。我從來沒有建立過API，我有幾個問題。

• 性能如果我打造的API作爲一個單獨的應用程序，它看起來這將是慢一倍。因爲它必須經歷API端的整個請求/響應循環，然後再通過公共應用程序端。有沒有辦法讓這個更快？或者，也許是另一種方法？

• 通過本地網絡訪問API如何通過本地網絡訪問API？我會在Apache中設置指向127.0.0.1的虛擬主機嗎？

• 活動資源在我的情況下（在rails端）是ActiveResource最好的方式去或有更好的選擇消費API？我也想知道驗證如何在公共方面起作用。 ActiveResource會重用驗證規則還是必須在公共方面重新創建它們？

• API安全我在想，我就不必太擔心這個，現在因爲API只能（理想）通過本地網絡訪問。我在這個假設中糾正了嗎？

Answer 1

有whole books已解決這個特定的主題。在創建服務時處理管理延遲，穩定性，靈活性和所有其他功能。

從一個非常普遍的觀點和相對簡單的用例，聽起來就像你有，我會在每個應用程序中推薦簡單的基於REST的API。你絕對不想在PHP中重複使用Ruby編寫的代碼，反之亦然。競爭的基於HTTP的查詢方法之間的響應時間不會太多（不像談論HTTP或CORBA之類的東西時那樣大）。編寫REST資源是Ruby on Rails擅長的，因此您幾乎可以將它作爲一個gimme。 PHP比較困難，你只需要按照REST標準來構建可查詢的API。之後，您只需要一個HTTP客戶端來對任一客戶端進行請求。如果您對每個應用程序都有明確的端點，那麼對它們進行硬編碼不應該是一個太大的問題。如果不是，還有另一個圍繞enterprise service buses的整體設計模式，它們可以幫助一個服務找到另一個服務，但通常不具備跨平臺功能（至少不是PHP和Rails方式），我知道這是！）。

對於Ruby/Rails的世界，我可以推薦HTTParty或Typheous作爲HTTP客戶端（它將查詢其他應用程序的REST客戶端）。對於PHP世界來說，您可能需要查看this thread。它列出了一些。

要清楚的是，這不是您唯一的選擇 - 您可以創建完整的Web服務，甚至通過創建直接套接字連接來更深入，等等。這實際上完全取決於你希望系統的耦合程度如何，它們的耦合程度如何，它們有多接近（以「網絡拓撲」的意義來說），以及每個系統響應速度有多快。

關於安全性：一種選擇是在每個系統上設置防火牆，只接受去往特定資源的連接，如果它們來自特定IP。您可以在應用程序級別遵循類似的模式。儘管通過基本/摘要身份驗證確保標準HTTPS會話的運行可能同樣多。

希望這會有所幫助。我可以繼續討論這個問題，但我不知道有什麼好的辦法可以給一個具體的答案這個問題的一般問題。如果有什麼我可以擴展，隨時評論，我會盡我所能。