REST API，跟蹤多個資源的變化，前端同步

Question

我有一個相當複雜的業務邏輯系統，到目前爲止，我有大約10-15個數據庫表（資源），這個數字還在增長。用戶的前端是angularjs單頁面應用程序。問題是與後端數據通信並保持角度前端與後端數據同步。

後端保留它們之間的所有資源和關係，這是顯而易見的。前端獲取這些資源並將它們保存在本地，以使界面對用戶更加敏感，並避免在每次請求時獲取數據。這真棒。

服務器端有很多操作會一次影響很多資源。這意味着添加/刪除/編輯一個資源（通過REST API）可以修改很多其他資源。

我希望前端應用程序數據始終與後端數據完全同步。這使我可以保持數據完整性並保持我的應用程序無缺陷。任何類型的失步都是一個很大的「不」，它引入了數百個可能會在我的前端應用程序中發生未定義行爲的地方。

問題是：達到這個目標的最佳方法是什麼？我的想法/見解：

1. 業務邏輯（修改/編輯/刪除資源，管理關係，保持數據完整性）只能執行一次。實現業務邏輯實現的兩倍（前端一個，後端一個）引入了很多潛在的錯誤，並涉及代碼重複，這顯然是一件壞事。如果業務邏輯是在前端實現的，後端仍然需要驗證數據並保持其完整性 - 重複業務邏輯。所以，業務邏輯必須處於後端階段。

2. 我使用REST API。當我的前端更新一個資源（或通過PATCH方法提供的許多資源）時，服務器端會發生很多副作用，其他資源也會被修改。我希望我的前端角度應用知道哪些資源被修改並更新它們（以保持完全同步）。 REST只返回最初請求更新的資源，沒有其他受影響的資源。

我知道我可以使用某種形式的鏈接資源，併發送原始更新的資源以及指向其他受影響資源的鏈接。但如果有100個呢？向服務器發出100個請求是完全性能損失。

1. 我不是非常依賴REST，因爲我的API不公開，它可能是任何東西。我認爲最好的解決方案是後端發回所有修改過的資源。這將允許我的前端總是與後端同步，會很快，並且會是原子的（在多個請求到服務器之間沒有無效的中間狀態）。我認爲這個架構會很棒。問題是：這是一種常用的方法嗎？有沒有任何協議/標準/庫允許我這樣做？我們可以從頭開始編寫它，但我們不想重新發明輪子。

2. 其實，我認爲在前端和後端有業務邏輯會很好，但只有在實施一次的情況下。這意味着Javascript後端應用程序。不幸的是，目前，這對我來說不是可能的解決方案。

任何見解都會受到歡迎！

增加了主幹。js標籤，因爲問題比任何特定的技術都要多得多。

Answer 1

你走在正確的軌道上，這是你現在面臨的常見問題。如您所說，在REST世界中，您的API會返回請求/更改的資源。您的問題的一個簡單示例：

您 - 作爲用戶X - 想跟隨另一個用戶Y.前端顯示您自己的下一個計數器（X）和另一個用戶（Y）的跟隨者計數器。 http調用將如下所示：

PUT /users/X/subscribe/Y 

該API將返回用戶Y資源，但是X缺失，或者相反。

爲了處理這個情況下，我用我的標準API響應結構的擴充結構，我的標準結構是：

• 元對象 - 包括HTTP狀態代碼，並解釋爲什麼習慣了這種代碼，其中應用服務器處理的響應和更
• 通知對象 - 包括在加工過程中和錯誤的信息（如果有的話），爲開發特殊消息的詳細

• 資源 - 這得到了所請求的資源/改性，該屬性的名稱是singl的單數資源類型電子資源（例如用戶），或在多個資源集合（例如，用戶）

  { 元：{ 狀態：200， 消息： 'OK'， APPSERVER：APP3 }， 通知：{ 錯誤：[] }， 用戶：{ ID：3123212， 訂戶：123， 訂閱：3234 } }

爲了噸o還返回其他受影響的資源並保持REST方式+我的靜態標準響應結構我將另一個對象附加到名爲'affectedResources'的響應中，該響應是所有其他受影響資源的數組。在這個非常簡單的例子中，數組只包含用戶X資源對象。前端迭代數組，並在前端明智地處理所有必要的更改。