奇怪的網站導航機制

Question

我在別人的基於Web的應用程序上執行UAT。該系統相當龐大，數十種形式，以及數百個獨立的輸入字段。總的來說，它看起來很好，可用。

我注意到有一件事對我來說似乎很陌生。我點擊的每個鏈接都實際執行一個POST請求（包含我想要的頁面的詳細信息）到我已經在的頁面，然後HTTP響應會重定向到我想要的頁面。我可以理解，對於數據已更改的頁面，可以這樣做 - 這將允許系統在沒有用戶明確強制它的情況下保存數據。但是，此行爲也用於沒有用戶輸入的頁面。

爲什麼這樣做？這似乎是在推動系統中一些主要的減速。

如果是幫助，則使用JSF編寫此係統。

Answer 1

我不會假裝是一名開發人員，他曾廣泛地使用過JSF。但是，我在其他技術上創建了許多Web應用程序。

一般來說，對於使用POST請求進行導航的發送額外數據的請求確實會增加數據負載並可能導致速度的小幅下降。通常，導航執行GET請求被認爲是最佳做法。 POST請求通常保存用於執行需要輔助數據的操作的情況。

現在POST'ing然後接收響應中的重定向，這是奇怪的，並會導致放緩，因爲你是兩個網絡請求而不是一個。我會問，「爲什麼不把鏈接指向我正在被重新指向的頁面？」。我能夠理解的唯一答案是某種不使用cookie或url會話參數的自定義會話管理。

可能有更多的原因，但這種設計類型似乎是非常不必要的，老實說，無論原因是什麼，我相信有一個更好的方法來實現系統不這樣做。

Answer 2

當您在JSF頁面中使用<h:commandButton>或<h:commandLink>時，它將執行HTTP POST;從來沒有一個GET。

如果需要GET，那麼應該使用<h:outputLink>，但是開發人員經常使用前兩個標籤，因爲它們允許機會在導航之前調用動作 - 也就是說，在打開某個頁面之前，開發人員可能需要一個支持bean中的方法來運行該設置/初始化一些變量。因此，Web應用程序執行POST的原因可能有充分的理由。

如果不需要任何操作，例如，如果導航是菜單，那麼我會考慮更改爲使用<h:outputLink>或僅使用Facelets和常規錨標記。