我們如何整合內部部署的兩個rails應用程序

Question

• RESTful服務是將任何應用程序與Rails應用程序（包括任何其他Rails應用程序）集成的唯一途徑，無論它是否在同一網絡中？
• 對於集成兩個應用程序而言，與其他技術（如Java EE）中的基於RMI的集成相比，RESTful服務有多沉重？
• 有沒有辦法使用任何原生理解的二進制格式來集成兩個rails應用程序，這樣可以避免轉換爲不同的格式，如：HTTP請求。

Answer 1

REST方法意味着應用程序A只會使用HTTP協議發出應用程序B的請求（並且可能以其他方式）。數據發送可以是任何你喜歡的格式，儘管JSON現在是默認的（XML是昨天的默認設置，甚至是SOAP - gaq！）。

現在，絕大多數外部API都是以這種方式實現的 - Amazon，Google Maps，Yelp等等等等。爲什麼？因爲HTTP（或HTTPS）協議很好理解和廣泛部署。不需要特殊配置，並且在Web瀏覽器上爲普通用戶提供應用程序的相同協議適用於其他應用程序。 Rails使得這個非常容易（如果你順其自然）。

Java的RMI是一個特定的協議（就像HTTP一樣）。優點是在A中定義的對象可以作爲B中的實例使用（經過大量工作後）。當你有一組前端協同工作的應用程序，並且其主要需求是跨地點，服務器等分佈時，這是非常有意義的.RMI在應用程序之間創建了一個緊密的綁定 - 一個變更通常需要一個變更在另一個。適用於某些類型的應用程序。

但是，如果你有一個公司的兩個部門彼此交談，但不希望被「束縛」，那麼REST界面提供了很大的靈活性。

你的第二個問題（「多重」）很難回答。我在2001年曾經工作過的一家公司有數百臺服務器都運行一個「工作人員」進程的實例 - 他們都設計爲將結果排隊到一個「控制器」進程，該進程將處理輸出並轉發到另一臺專爲處理和管理數據。在2001年，這是正確的架構，因爲它完全是爲了一起工作而設計的 - 在我們的Intranet的單個子網上運行的服務器上的持久套接字連接。現在在2012年，這個充滿了服務器的房間被一些運行64位操作系統的高性能處理器所取代，並且可以處理大量內存 - 這是一個全新的世界。 2001年的業績翻倍可能節省數百萬美元的硬件，業務支持和空間等等。在2012年，最昂貴的是開發者！因此，現在「重」在所有計算密集型操作中都是無關緊要的。 HTTP請求很簡單。最後的問題：原生理解的二進制格式。當然，如果需要的話。最後，通過兩臺服務器之間的線路發送的任何二進制格式都需要序列化和反序列化爲一個流，這對程序員和機器都是有用的。 JSON是一種文本格式，但是它本身可以通過JavaScript（JavaScript對象表示法）理解，並且具有人類可讀性的明顯優勢。鑑於大多數服務器都設置爲自動壓縮輸出，無論是文本還是二進制文件都會變得不那麼相關，至少就I/O和有效負載而言。當然你的可以想出任何相互理解的格式並通過HTTP發送，但這又是十年前的重點，而今天通常不是一個值得考慮的問題。處理器變得越來越快，內存更便宜（而且更大） - 所以（像往常一樣）I/O（無論是網絡還是磁盤）是現代應用中的典型瓶頸。

如果我要重新設計我從2001年提到的應用程序，其中有數百臺（今天的）服務器需要與專門設計用於互操作的（許多）對等服務器通信，我可能會努力確保serialize/deserialize過程儘可能輕巧（但只有如果它竟然是一個瓶頸）。對我來說，綁定到任何給定的平臺或語言是不起的 - 計算世界正在向快速發展。

但是，在今天的幾乎所有現實的商業應用中，保持簡單，標準和直接的事物既具有現在和未來的優點，也需要過度擔心性能問題。

希望這有助於:-)