爲什麼郵寄請求比在rails中刪除更受青睞？

我已經在使用Ruby-on-Rails編寫的很多代碼中看到了這一點。爲什麼郵寄請求比在rails中刪除更受青睞？

看來，POST請求通常優於那些刪除

def destroy 
    relation = IssueRelation.find(params[:id]) 
    if request.post? && @issue.relations.include?(relation) 
    relation.destroy 
    @issue.reload 
    end 
end

我覺得這有點奇怪，因爲它似乎並沒有遵循REST約定使用Rails的這麼多。

這是否與安全有關，還是與一些不支持刪除請求的舊瀏覽器兼容？

來源

2011-08-05 user852689

除了別人提供的信息之外，它還確保請求不是獲取請求，可以由抓取工具觸發，也不希望丟失站點上的所有數據，因爲有人試圖不小心抓取它。 – rubish

你基本上回答了你自己的問題，瀏覽器並不是很擅長支持所有的HTTP動詞。有一個不錯的網站，在那裏你可以測試你當前的瀏覽器支持什麼，看看有什麼事情失敗了，我相信你會與有關delete注意到一些，例如，當重定向涉及：

http://www.mnot.net/javascript/xmlhttprequest/

來源

2011-08-05 12:50:39

刪除請求不是完整的真正的刪除請求。它實際上是僞造的，就像你在保存的對象上使用form_for時的放置請求一樣。據我所知，沒有理由不使用所提供的REST約定。

另一個說明，是你自己的代碼片段，或一個例子？有點好奇你爲什麼要檢查你正在刪除的記錄是否與父母關聯。我想總有這樣的可能性，就是在你點擊刪除的時間點之間，並且它已經接到請求，有人在其他地方改變了它的父母。

編輯，這裏是當我點擊刪除鏈接在軌道3支架應用的標題信息：

Request URL:http://phone_qa.dev/sites/2 
Request Method:POST 
Status Code:302 Moved Temporarily 
Request Headersview source 
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3 
Accept-Encoding:gzip,deflate,sdch 
Accept-Language:en-US,en;q=0.8 
Cache-Control:max-age=0 
Connection:keep-alive 
Content-Length:86 
Content-Type:application/x-www-form-urlencoded 
Cookie: _phone_qa_session=BAh7B0kiD3Nlc3Npb25faWQGOgZFRkkiJTg4Y2Q4ZTgyOGYwM2IyMWI1N2Y4MjYyMTcwMzJiMzMwBjsAVEkiEF9jc3JmX3Rva2VuBjsARkkiMVY0QkFIOXdzRFZXZi9yYnlkODJCUEdLTisvT2V6dVpkVDYyckkyR3JQSzg9BjsARg%3D%3D--e8244fd59e5fc34b37a93c2e768ace7a3bfffe44 
Host:phone_qa.dev 
Origin:http://phone_qa.dev 
Referer:http://phone_qa.dev/sites 
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_0) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.107 Safari/535.1 
Form Dataview URL encoded 
_method:delete 
authenticity_token:V4BAH9wsDVWf/rbyd82BPGKN /OezuZdT62rI2GrPK8=

你可以看到它實際上是如何的一個POST請求，但根據表單數據，有一個變量所謂的_method與值刪除。

來源

2011-08-05 12:47:54 agmcleod

該代碼是我從Redmine控制器類獲取的示例代碼片段。 – user852689

該代碼段是從管理平臺，並在2007年5月承諾：https://github.com/edavis10/redmine/blob/92b02014d21f0e60230fc7a5c3c5ad71dac6e472/app/controllers/issue_relations_controller.rb

那是很久以前的事了，如果我的記憶沒有逃避我，REST並沒有那麼好，也不知道在Rails中那麼好實現那時候。上述模式是當時做事的明智方式。

爲了比較，同樣的動作現在看起來像這樣在管理平臺：

verify :method => :delete, :only => :destroy, :render => {:nothing => true, :status => :method_not_allowed } 
def destroy 
    raise Unauthorized unless @relation.deletable? 
    @relation.destroy 

    respond_to do |format| 
    format.html { redirect_to :controller => 'issues', :action => 'show', :id => @issue } 
    format.js { render(:update) {|page| page.remove "relation-#{@relation.id}"} } 
    format.api { head :ok } 
    end 
rescue ActiveRecord::RecordNotFound 
    render_404 
end

它不僅驗證HTTP動詞DELETE（儘管是僞造的，由於缺乏支持的瀏覽器），但它也有能夠響應不同MIME類型的請求 - 現在更加RESTful。

來源

2011-08-05 14:00:20

100％正確。 Redmine中的很多代碼是在REST流行之前使用POST和POST-back操作的。我重構了一堆，但還剩下很多。 –

爲什麼郵寄請求比在rails中刪除更受青睞？

回答

相關問題