去API還是沒有

Question

我的公司有這個巨大的數據庫，得到來自多個來源的（許多）事件，用於監控和報告目的。到目前爲止，數據中的每個新儀表板或圖形都是一個新的Rails應用程序，在巨大數據庫中具有額外的表格，並可以完全訪問數據庫內容。

最近，有一種想法是讓外部（而不是我們的公司，但姊妹公司）客戶訪問我們的數據，並且已經決定我們應該公開一個只讀的RESTful API來查閱我們的數據。

我的觀點是 - 我們是否應該爲我們的自己的項目使用API​​？訪問RESTful API，即使是「本地」項目，而不是直接訪問數據庫，是否矯枉過正？我認爲這會在統一我們團隊對數據的訪問方面取得回報 - 但這是否值得額外往返？ RESTful API能夠滿足每秒運行20次左右查詢的需求並通過JSON公開結果嗎？

感謝您的任何意見！

Answer 1

我認爲有很多要說的一致性。如果你爲你的客戶提供一個API，在我看來，通過使用相同的API你會更好地理解它。爲您的客戶提供支持，您會定期對其進行測試（不包括迴歸測試），並且您發送的消息表明它足夠讓您使用，所以它對您的客戶應該沒問題。

通過隱藏API背後的所有內容，您可以隨意更改數據庫表示，而不必更改 API接口代碼（通過API呈現數據）以及數據庫訪問代碼，家庭應用。你只會改變前者。

最後，這樣的性能問題只能通過嘗試和測量來解決。也許有必要將原型API系統敲在一起並在負載下研究它？

Answer 2

此外，如果您在內部使用Api，那麼您應該能夠減少必須維護的代碼量，因爲您只需維護API而不是API以及您自己的內部訪問數據的方法。

Answer 3

我肯定會去API的路線。這爲所有與您的應用程序交談的應用程序（包括驗證等）提供了一個易於維護的界面。確保您可以通過列限制和存儲過程確保數據庫的完整性，但爲什麼還要保持這一點？

不要忘記 - 您還可以在文件系統，內存或使用memcached（或任何其他服務）中緩存API調用。在數據集沒有改變的地方（使用updated_at或etags進行檢查），您只需返回緩存版本即可獲得極大的速度提升。在我開發的最新應用程序中添加了etags後，HTML加載時間從1.6秒增加到60毫秒。

偏題：我一直在玩的一個想法是根據請求動態加載API版本。像這樣的東西可以讓你在維持向後兼容性的同時大幅改變API。由於不同的版本在不同的文件中，因此分開維護它們會很簡單。

Answer 4

我一直在想我即將開始的一個項目的同樣的事情，是否應該從頭開始構建我的Rails應用程序作爲API的客戶端。我同意在這裏已經提到的優點，我將回顧一下，並加入到：

• 更好的API設計：你成爲你的API的用戶，所以這將是更大量的拋光當你決定打開它;
• 數據庫獨立性：減少耦合，您可以稍後從RDBMS切換到文檔存儲，而不會更改;
• 可比較的性能：性能可以通過HTTP緩存來解決（儘管我希望看到一些比較兩者的數字）。

最重要的是，你還可以得到：

• 更好的可測性：你的整個業務邏輯是黑盒可測試基本的HTTP resquest /響應。無頭瀏覽器/ Selenium僅對應用程序特定的行爲負責;
• 前端獨立性：您不僅可以自由更改數據庫表示形式，還可以自由更改整個前端，從vanilla Rails-HTML-and-Page-Reloads到撒佈Ajax，到完整的純JavaScript（例如GWT），全部共享相同的後端。我最初看到這個方法

---

批評

的一個問題是，它會讓我失去所有的設施和具有靈活性，ActiveRecord的規定，與各協會，named_scopes和所有。但是通過ActveResource使用API​​會帶來很多好東西，看起來您也可以擁有named_scopes。不確定關聯。

更多的批評，請

我們一直都唱這種方法的輝煌，但是，即使答案已經被摘下來，我想從別人那裏聽到的話可能出現的問題這種方法可能會帶來什麼，爲什麼我們不應該使用它。