1

Ruby-on-Rails를 사용하여 작성된 많은 코드에서이를 보았습니다.게시 요청이 레일에서 삭제보다 우선되는 이유는 무엇입니까?

는 나머지 대회는 레일에 너무 많이 사용에 따라하지 않는 것 때문에 해당 게시물의 요청이 자주 나는이 조금 이상한 찾을 것

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

을보다 선호 삭제하는 것 같다.

보안과 관련이 있거나 삭제 요청을 지원하지 않는 일부 구형 브라우저와의 호환성을 위해 존재합니까?

+0

다른 사람이 제공 한 정보 외에도 요청이 크롤러에 의해 트리거 될 수있는 요청이며 요청이 사이트에서 모든 데이터를 잃어 버리는 것을 원하지 않는다는 것을 보증합니다. 누군가가 부주의하게 크롤링하려했기 때문입니다. . – rubish

답변

3

당신은 기본적으로 당신 자신의 질문에 답했습니다. 브라우저는 모든 HTTP 동사를 지원할 때 엄청나게 위대한 것은 아닙니다. 리디렉션이 관여 할 때 현재 브라우저가 지원하는 테스트 할 수있는 좋은 사이트는, 일이 실패 무엇을 살펴 예를 들어, 내가, 당신이 delete에 관한 몇 가지를 알 수 있습니다 확신이있다이다 :

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

2

삭제 요청은 실제 삭제 요청에 대해 전체가 아닙니다. put 요청과 마찬가지로 실제로 저장된 객체에 대해 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를 삭제 값과 함께 호출합니다.

+0

이 코드는 Redmine 컨트롤러 클래스에서 가져온 예제 조각입니다. – user852689

2

그 코드는 레드 마인에서이며, 2007 년 5 월에 투입되었다 : https://github.com/edavis10/redmine/blob/92b02014d21f0e60230fc7a5c3c5ad71dac6e472/app/controllers/issue_relations_controller.rb 오래 전에, 그리고 내 기억이 나를 탈출하지 않는 경우, REST는 모두 잘 알려진도 모두 잘 레일에서 구현되지 않은

그때는. 위의 패턴은 그 당시의 일을하는 현명한 방법이었습니다. 비교를 위해

이 같은 조치는 지금 레드 마인에 다음과 같습니다

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 동사를 삭제하지만, 그것은 또한이 있는지 확인 않습니다 다른 MIME 유형에 대한 요청에 응답하는 기능 - 훨씬 더 RESTful입니다.

+0

100 % 정확함. Redmine의 많은 코드는 REST가 인기가 있기 전에 POST 및 POST-BACK 액션이 사용되었습니다. 나는 그들 중 다수를 리팩터링했으나 아직 많이 남아있다. –

관련 문제