TA貢獻(xiàn)1775條經(jīng)驗(yàn) 獲得超8個(gè)贊
您可能從研究中POST了解到，-redirect- GET看起來(lái)像這樣：
客戶端獲取帶有表單的頁(yè)面。
表單POST到服務(wù)器。
服務(wù)器執(zhí)行操作，然后重定向到另一個(gè)頁(yè)面。
客戶端遵循重定向。
例如，假設(shè)我們有這個(gè)網(wǎng)站的結(jié)構(gòu)：
/posts （顯示帖子列表和“添加帖子”的鏈接）
/<id> （查看特定帖子）
/create（如果使用該GET方法請(qǐng)求，則將表單發(fā)布返回給自己;如果是POST請(qǐng)求，則創(chuàng)建帖子并重定向到/<id>端點(diǎn)）
/posts 本身與這種特殊模式并不真正相關(guān)，所以我會(huì)把它留下來(lái)。
/posts/<id> 可能會(huì)像這樣實(shí)現(xiàn)：
在數(shù)據(jù)庫(kù)中查找具有該ID的帖子。
使用該帖子的內(nèi)容呈現(xiàn)模板。
/posts/create 可能會(huì)像這樣實(shí)現(xiàn)：
如果請(qǐng)求是GET請(qǐng)求：
顯示一個(gè)空表單，目標(biāo)設(shè)置為自身，方法設(shè)置為POST。
如果請(qǐng)求是POST請(qǐng)求：
將帖子添加到數(shù)據(jù)庫(kù)。
重定向到/posts/<id>（<id>從調(diào)用數(shù)據(jù)庫(kù)返回的位置）
驗(yàn)證字段。
如果存在無(wú)效字段，請(qǐng)?jiān)俅物@示表單并指出錯(cuò)誤。
否則，如果所有字段都有效：
TA貢獻(xiàn)1815條經(jīng)驗(yàn) 獲得超6個(gè)贊
我會(huì)試著解釋一下。也許不同的視角可以幫到你。
使用PRG，瀏覽器最終會(huì)發(fā)出兩個(gè)請(qǐng)求。第一個(gè)請(qǐng)求是POST請(qǐng)求，通常用于修改數(shù)據(jù)。服務(wù)器響應(yīng)響應(yīng)中的Location標(biāo)頭，并且正文中沒(méi)有HTML。這會(huì)導(dǎo)致瀏覽器重定向到新URL。然后，瀏覽器向新URL發(fā)出GET請(qǐng)求，該URL響應(yīng)瀏覽器呈現(xiàn)的HTML內(nèi)容。
我將嘗試解釋為什么應(yīng)該使用PRG。GET方法永遠(yuǎn)不應(yīng)該修改數(shù)據(jù)。當(dāng)用戶單擊鏈接時(shí)，瀏覽器或代理服務(wù)器可能會(huì)返回緩存的響應(yīng)，而不會(huì)將請(qǐng)求發(fā)送到服務(wù)器; 這意味著當(dāng)您想要修改數(shù)據(jù)時(shí)，不會(huì)修改數(shù)據(jù)。此外，POST請(qǐng)求不應(yīng)該用于返回?cái)?shù)據(jù)，因?yàn)槿绻脩粝胍@取數(shù)據(jù)的新副本，則他們被迫重新執(zhí)行請(qǐng)求，這將使服務(wù)器再次修改數(shù)據(jù)。這就是為什么瀏覽器會(huì)給你一個(gè)模糊的對(duì)話框，詢問(wèn)你是否確定要重新發(fā)送請(qǐng)求，并可能再次修改數(shù)據(jù)或再次發(fā)送電子郵件。
PRG是POST和GET的組合，它們使用每個(gè)用于它們的用途。
舉報(bào)