在單頁面應用程序中創建臨時URL

Question

在我的基於反應的單頁面應用程序中，我的頁面分為兩個窗格。

左窗格：過濾面板。

右窗格：網格（包含通過應用過濾器的數據的表）

總之，我有一個看起來非常類似於amazon.com的應用程序。 默認情況下，當用戶在瀏覽器中點擊應用程序的根端點（/）時，我會從服務器獲取最近7天的數據並將其顯示在網格中。

過濾器面板有幾個過濾器（例如，時間過濾器用於獲取落在指定時間間隔內的數據，ID用於搜索具有特定ID的數據等）以及附加在過濾器面板標題中的搜索按鈕。 點擊搜索按鈕通過在帖子表單體內提供選定的過濾器來對服務器進行調用，服務器返回匹配傳遞的過濾器的數據，並且我的前端應用程序顯示從網格內的服務器返回的這些數據。

現在，當某人點擊過濾器面板中的搜索按鈕時，我想在URL的查詢參數中反映所選過濾器，因為它可以幫助我與我網站的其他用戶共享這些URL，以便他們可以看到我應用的過濾器和查看僅與這些過濾器匹配的網格內的數據。

這里的問題是，如果在搜索按鈕上單擊，我使用帶有查詢參數的http get，由於不同瀏覽器對URL長度的限制，我將最終破壞應用程序。

請建議我正確的解決方案來創建這樣的URL，這將幫助我在過濾器面板中設置選定的過濾器，而不會在我的應用程序中造成任何副作用。

可能的解決方案：考慮到我們不能直接在查詢參數中添加普通字符串，因為不同瀏覽器的URL長度限制（注意：規范不限制HTTP Get請求的長度，但不同的瀏覽器實現自己的限制），我們可以使用類似於消息摘要或散列（將任意長度的輸入轉換為固定長度的輸出）並將其保存在DB中以供服務器理解請求並提供內容。 這只是一個想法，我不確定這是否是解決這個問題的理想方案。

其他頻繁使用的網站的行為：

• amazon.com，newegg.com - >使用散列網址。
• kayak.com - >因為他們有非常明確的關鍵字，他們使用簡短的形式，如印度的IN，班加羅爾的BLR等，並將其與否定邏輯相結合，以進一步優化最大網址長度。 沒有選中，但在大量選擇過濾器后理想情況下會中斷。
• flipkart.com - >將字符串直接附加到查詢參數，並在違反限制后中斷。 驗證了這個。

Answer 1

讓我們分析您的問題和解決方案。 問題：您需要一個URL，其中包含有關應用過濾器的信息，以便在您共享該URL時，用戶不會落在任意頁面上。

解決方案：

1）附加應用URL的過濾器。 要實現這一點，您需要縮短過濾器類型的鍵和過濾器的值，以便每個過濾器的URL長度不會超過。

缺點：這不是最可靠的解決方案，因為過濾器增加URL長度的數量必須增加其他選項。

2）使用URL附加應用過濾器（哈希）的唯一鍵。 為此，您需要在服務器和客戶端上進行一些更改。 在客戶端，您將需要一種編碼算法，該算法將應用於特定哈希的過濾器轉換 在服務器端，您將需要解碼算法，將唯一散列轉換為應用的過濾器。 現在客戶端每當有這樣的URL被命中時，你就可以進行POST api調用，這個哈希給你應用的過濾器數組，或者在客戶端只有邏輯轉換這個哈希。 在componentWillMount完成所有這些以避免任何副作用。

我認為第二種解決方案幾乎在所有情況下都是可擴展且高效

Answer 2

為了回應@ cauchy的回答 ，我們需要區分散列和加密 。

哈希

哈希必然是不可逆轉的。 為了將散列映射到特定的過濾器組合，您可能需要

1. 對每個請求嘗試匹配所請求的散列（計算密集型）或服務器的服務器上的過濾器的每個排列進行散列
2. 存儲哈希映射以過濾服務器上的組合（內存密集型）。

對於絕大多數情況，選項1將太慢。 根據過濾器和選項的數量，選項B可能需要一個相當大的地圖，但它仍然是您的最佳選擇。

加密

在此方案中，服務器將其公鑰發送到客戶端，然后客戶端可以使用它來加密其過濾器選項。 然后，服務器將使用其私鑰解密加密數據。 這很好，但您的加密數據不會是固定長度 。 因此，當選擇更多選項時，會遇到不確定參數長度的相同問題。

因此，為了確保您的URL不包含任意數量的過濾器和選項，您需要在服務器上維護hash-> selection的映射。

我們應該如何處理永久鏈接和臨時鏈接？

您在上面的評論中提到過

如果我們使用一些持久性存儲來保存此哈希與實際過濾器之間的映射，我們理想地希望將長期存在的“永久鏈接”與短暫的短暫URL隔離，並使用該理解來有效地使短暫的哈希值過期。

您可能在服務器上有一個服務，它處理您在應用程序中支持的所有過濾器。 這里的訣竅是讓該服務也管理hashmap。 隨着添加/刪除更多過濾器和選項，服務將需要重新排列過濾器選擇的每個排列。

如果您需要對永久鏈接的強大支持，那么每當您刪除過濾器或選項時，您都希望保持“過期”哈希並更改其映射以指向合理的替代哈希。

我們什么時候更新數據庫中的哈希值？

有很多選擇，但我通常更喜歡構建時間 。 如果您正在使用Jenkins，Travis，AWS CodePipeline等CI解決方案，那么您可以添加構建步驟來更新您的數據庫。 基本上，你要......

1. 保留所有現有支持的過濾器的持久記錄。
2. 在構建時，檢查是否有任何新過濾器。 如果是這樣的話...
   1. 將這些過濾器添加到步驟1中的記錄中。
   2. 散列所有新的過濾器排列（僅包含新過濾器的排列）並將其存儲在散列數據庫中
3. 檢查是否已刪除任何過濾器。 如果是這樣的話...
   1. 從步驟1中的記錄中刪除這些過濾器。
   2. 找到包含那些過濾器的排列的所有哈希值，並且......
      • 從DB中刪除這些哈希值（弱永久鏈接），或
      • 將哈希指向DB中的合理替代哈希（強固定鏈接）