前些日子在開發公司專案介面的時候，由於需要與第三方平台對接，由於介面之前的層層封裝，不斷的需要**，把人差點搞糊塗了。本來以為之前對redirect的認識足夠清楚，可是到實際開發之前我還是沒有把這個問題想清楚，從而造成了需要花費更多的時間解決問題。總結下，並分享。
1.請求**（forward）:
當客戶端（瀏覽器）向遠端伺服器傳送乙個url(請求後，伺服器接收到請求後，會在伺服器內部直接通過另外的乙個url獲取資源，並將此資源再響應給瀏覽器，也就是說請求**整個過程是一次性的。列如：
->在瀏覽器中看到這url（
->通過頁面上的點選操作後，
->伺服器響應了其他頁面內容到瀏覽器，但是瀏覽器的url位址仍然是原來的url.
2.重定向（redirect）:
當客戶端（瀏覽器）向伺服器傳送乙個url請求後，但是資源並不在當前請求的伺服器上，此時伺服器會告訴瀏覽器，資源在另外乙個url位址上，此時瀏覽器會重新傳送請求到新的資源位址。例如：
->在瀏覽器中看到這url（
->伺服器a響應瀏覽器重定向
->瀏覽器重新定位新的url位址到伺服器b
->伺服器b響應內容到瀏覽器，此時瀏覽器上面的url已經換位了新的資源請求位址
3.場景：
現在又伺服器：a,b,c,d, abc都是本公司伺服器，a伺服器為web伺服器，而d為合作夥伴提供的介面伺服器。
公司web專案a需要呼叫伺服器d的遠端鑑權介面，而我司又通過b,c兩個伺服器對d伺服器的鑑權介面進行了封裝，
然後web伺服器a會通過呼叫伺服器b，b呼叫伺服器c，c呼叫d的方式呼叫鑑權介面（有點煩人，但是他們要求這麼做）。
伺服器d本來可以直接通過響應json/xml資料來提供介面的，但是他們做了業務邏輯封裝，
當發現請求鑑權不通過的時候，d伺服器會重定向到他們的web頁面，當使用者在介面上操作完成後，d伺服器會傳送重定向請求到呼叫者制定的介面，然後呼叫者通過解析重定向請求的資料完成接下來的操作。
當呼叫者傳送的請求通過了伺服器d鑑權的時候，伺服器d會直接重定向響應到呼叫者制定的介面，然後呼叫者通過解析重定向請求的資料完成接下來的操作。
簡而言之，對接伺服器d,需要其他服務端不斷的傳送重定向請求。愚蠢的是，由於當時沒想明白整個重定向流程，對接的時候，我把伺服器d重定向的結果位址寫在了伺服器b上接收，然後把資料封裝成了json。最後造成的結果就是，當使用者在瀏覽器上訪問伺服器a時，伺服器響應的都是資料，web伺服器a根本就沒有進行過業務邏輯處理。最後又不得重新修訂了下介面，重定向結果請求還是得放在web端。
4.總結
介面的制定是一深度技術活，設計不好就是個大坑。了解清楚重定向，以後碰到了少走點彎路，少入點坑。（描述的肯能不是很清楚，見諒）
重定向Redirect 的常識
今天下班的時候看到了一些重定向的基礎知識，也算開了眼界。以前也經常使用301和302，但從來沒有使用過和了解過其他的3xx的狀態碼，發現原來裡面涉及的知識和解決的問題的還不少。瀏覽器首先訪問伺服器a的url，伺服器a返回帶著location為b的url的 header 和3xx的狀態碼，瀏覽器讀取響...
重定向Redirect 的知識
今天下班的時候看到了一些重定向的基礎知識，也算開了眼界。以前也經常使用301和302，但從來沒有使用過和了解過其他的3xx的狀態碼，發現原來裡面涉及的知識和解決的問題的還不少。瀏覽器首先訪問伺服器a的url，伺服器a返回帶著location為b的url的 header 和3xx的狀態碼，瀏覽器讀取響...
認識Linux資料重定向redirection
今天kiddd帶大家學習的是linux的乙個知識內容 redirection，重定向。了解重定向之前首先需要知道linux的三種檔案描述符。當我們正常執行linux命令時，linux命令行會將命令寫入後的輸出，寫入到標準輸出檔案當中，並將輸出的結果列印到螢幕上，如 這種檔案叫做標準輸出檔案，它到檔案...