HTML 양식에 PUT 및 DELETE 메소드가없는 이유는 무엇입니까?

HTML4 / XHTML1은 양식에서 GET과 POST 만 허용합니다. 이제 HTML5도 같은 방식으로 작동합니다. 이 추가 제안 이 두하지만 견인차 역할을 할 것 같지 않습니다. HTML5 사양 초안에 PUT 및 DELETE를 포함시키지 않은 기술적 또는 정치적 이유는 무엇입니까?

이것은 흥미로운 질문입니다. 여기에있는 다른 답변은 모두 투기 적이며 일부 경우 플랫 아웃입니다. 여기에 내 의견을 쓰지 않고 실제로 조사를하고 delete 및 put 이 HTML5 양식 표준의 일부가 아닌 이유를 논의하는 원본 출처를 찾았 습니다 .

알고 보니, 이러한 방법이 되었다 에 포함 된 여러 가지 초기 HTML5 초안 (!)하지만 나중에 제거 된 이후 초안 . 모질라는 실제로 Firefox 베타 에서도 이것을 구현했습니다 .

초안에서 이러한 방법을 제거한 이유는 무엇입니까? W3C는 버그 보고서 10671 에서이 주제를 논의했습니다 . Mike Amundsen은이 지원을지지한다고 주장했습니다.

XmlHttpRequest 객체를 사용하는 최신 웹 브라우저에서는 PUT 및 DELETE를 실행하여 오리진 서버에서 리소스를 수정하는 것이 간단합니다. 스크립트되지 않은 브라우저 상호 작용의 경우에는 그렇게 간단하지 않습니다. [...]

이 패턴은 자주 사용되는 여러 웹 프레임 워크 / 라이브러리에서 "내장"해결 방법을 만들 때 너무 자주 필요합니다. [...]

다른 고려 사항 :

• PUT / DELETE를 사용하는 대신 POST를 터널로 사용하면 일치 하지 않는 캐싱이 발생할 수 있습니다 (예 : POST 응답은 캐시 가능 , PUT 응답은 불가능 (6), DELETE 응답은 (7)이 아닙니다)
• 비등 전성 방법 (POST)을 사용하여 dem 등원 작업 (PUT / DELETE)을 수행하면 네트워크 장애로 인한 복구가 복잡해집니다 (예 : "이 작업을 반복해도 안전합니까?").
• [...]

그의 전체 게시물을 읽을 가치가 있습니다.

Tom Wardrop도 흥미로운 지적을합니다.

HTML은 HTTP와 불가분의 관계에 있습니다. HTML은 HTTP의 휴먼 인터페이스입니다. 따라서 HTML이 HTTP 사양의 모든 관련 메소드를 지원하지 않는 이유는 자동으로 의심됩니다. 기계가 PUT 및 DELETE 리소스를 사용할 수있는 이유는 무엇입니까? [...]

의미 론적 마크 업 (semantic markup)을 보장하기 위해 HTML이 많은 시간을 소비하고 있지만 현재까지 의미 론적 HTTP 요청을 보장하기위한 노력은 없었다.

버그는 결국 Ian Hickson이 수정하지 않음 으로써 다음과 같은 근거 로 닫혔습니다 .

폼 메소드로서의 PUT은 의미가 없습니다. 폼 페이로드를 PUT하고 싶지 않을 것입니다. DELETE는 페이로드가없는 경우에만 의미가 있으므로 양식에도 큰 의미가 없습니다.

그러나 그것은 이야기의 끝이 아닙니다! 이 문제는 W3C 버그 추적기에서 닫히고 HTML Working Group 이슈 추적기로 에스컬레이션 되었습니다.

https://www.w3.org/html/wg/tracker/issues/195

이 시점에서 이러한 방법을 지원하지 않는 주된 이유는 아무도 포괄적 인 사양을 작성하는 데 시간을 들이지 않았기 때문입니다.

GET과 POST는 명확한 내용 중립적 근거를 가지고 있습니다. GET은 반복하고 캐시 할 수있는 안전한 방식으로 URL의 컨텐츠를 검색하는 것입니다. POST는 반복, 추론 적 실행 또는 캐시에 안전하지 않은 방식으로 작업을 수행하는 것입니다.

PUT 또는 DELETE에 대한 유사한 근거는 없습니다. 둘 다 POST로 완전히 커버됩니다. 리소스 생성 또는 파괴는 반복하기에 안전하지 않으며, 추측 적으로 실행하기에 안전하지 않으며, 캐시되지 않아야하는 작업입니다. 그들에게는 특별한 의미론이 필요하지 않습니다.

따라서 기본적으로 아무런 이점이 없습니다.

이것은 버그 10671이 폼 메소드로 PUT 및 DELETE에 대한 지원을 추가하는 것을 고려함 에 따라 2010 년에 제기되었습니다 .

이 "기능"에 대해 약간의 푸시 백이 있었으며 약간의 강압이 있었지만 결국 실무 그룹 버그 추적기에서 두 가지 문제로 확대되었습니다.

• 문제 -195 : 양식에서 http 요청 생성 향상
• 문제 -196 : 사용자 에이전트 http 응답 처리 동작 정의

문제 ISSUE-196 은 HTML 규격은 현재 요청을 처리하는 POST하는 방법 응답 제한하지 않는 한 사양에 변화를 수행하지하는 concensus 결정 결과. 나는이 특정 문제가 일반적으로 사용되는 POST 리디렉션 패턴을 조정하려고 시도하고 ReSTful 서버가 브라우저에서 렌더링하는 데 유용한 것이 아니라 짧은 메시지로 2xx 응답을 제공하는 방법에서 제기되었다고 생각합니다.

문제 ISSUE-195은 의자에 발표되었다. Cameron Jones는 2012 년 1 월 18 일에 변경 제안을 작성하여 자원 봉사를했고 2014 년 5 월 29 일에 첫 번째 작업 초안 이되기 위해 제출했습니다 .이 초안은 W3C 권장 프로세스를 거칩니다 .

운 좋게도 이는 곧 W3C 권장 사항이되고 브라우저 공급 업체가 구현하게되며 차단기를 제거하여 통일되고 의미가 있으며 브라우저에 친화적 인 ReSTful 서비스를 생성하는 데 큰 발전이 될 것입니다. 이것이 서비스 패턴에 흥미로운 발전을 가져올 것이라고 생각합니다. 존 무어 (Jon Moore) 의 좋은 이야기가 있습니다. 하이퍼 미디어 API는 볼 가치가 있습니다. 이것은 관심을 얻었지만 첫 번째 장애물 (이것)에서 떨어졌습니다.

내 이해는 브라우저가 PUT 또는 DELETE를 보낸 후에는 무엇을 해야할지 모른다는 것입니다. POST는 일반적으로 적절한 페이지로 리디렉션되지만 PUT 및 DELETE는 일반적으로 그렇지 않습니다. 따라서 웹 브라우저 형식이 아닌 ajax 또는 기본 프로그램을 통해 호출하는 데 적합합니다.

나는 지금 그것을 뒷받침 할 수 없지만, 그들이 이것을 논의 할 때 html5 메일 링리스트 중 하나를 읽는 것을 기억합니다.

역사

RFC1866 (8.1 단원) 에서 html 양식의 첫 등장을 언급 할 가치가 있다고 생각합니다 . 여기서 method 속성은 다음과 같이 정의됩니다.

METHOD
        selects a method of accessing the action URI. The set of
        applicable methods is a function of the scheme of the
        action URI of the form. See 8.2.2, "Query Forms:
        METHOD=GET" and 8.2.3, "Forms with Side-Effects:
        METHOD=POST".

자세한 설명은 섹션 8.2.2-GET 및 섹션 8.2.3-POST에 있습니다.

HTML 2.0 (1995 년 11 월)은 HTTP 1.0 (1996 년 5 월) 이전 에 지정되었습니다 . 따라서 모두는 GET (HTTP 0.9 기준) 또는 확장 POST와 함께 HTTP 만 사용했습니다. 그러나 HTTP 1.0 부록에 언급 된 것처럼 일부 웹 서버 만 PUT 및 DELETE를 지원했습니다 .

생각

Berners-Lee의 시맨틱 웹 개발이 어떻게 발전했을지에 대해 생각한다면 실제 문제에서 일반적인 개념으로 넘어간 것이 분명해 보입니다. 먼저 그는 문서를 공유하고 싶었습니다. 따라서 그는 마크 업이 필요했습니다. 그런 다음 데이터베이스에서 내용을 쿼리하려고하므로 양식이 필요했습니다. 그런 다음 새 데이터를 데이터베이스에 넣기를 원했습니다. 그래서 그는 GET과 POST와 함께 양식을 사용했습니다. 그 후 그는 원격의 데이터에 대해 모든 CRUD 작업을 수행 할 수 있다는 것을 알았을 수 있으므로 HTTP는 확장되었지만 너무 늦어서 HTML은 아닙니다 (몇몇 서버만이 새로운 CRUD 작업을 지원했습니다).

단지 추측 만하는 것은 아니지만, 아마도 HTTP는 액세스 제어에있어 끔찍한 것이 아니기 때문에 아마도 모든 사람이 필요로하는 것은 악의적 인 URL이 보안이 취약한 웹 사이트 및 / 또는 응용 프로그램을 손상시킬 수있는 더 많은 방법 일 것 입니다.

HTTP는 실제로 서버에서 클라이언트로 다운로드하는 것 이외의 파일 전송에 적합한 프로토콜은 아닙니다. FTP 또는 SFTP를 사용하십시오.

Get 및 Post는 요청 데이터를 전송하는 형식입니다.

RESTFUL 서비스에 양식 제출을 요청하는 것으로 가정합니다. 그러나 http 요청의 목적을 가정으로 만들기 위해 http 요청 표준을 변경하는 것은 의미가 없습니다. 요청이 채워지는 목적에 대한 정보는 입력 필드에서 가장 잘 처리됩니다.

주소와 가져 오기 및 게시가 있으면 서버가 요청과 입력 값을 올바르게 해석 할 수 있습니다. 여기에서 입력 값을 사용하여 서버에 개방형 요청을하고 원하는 작업을 수행 할 수 있습니다. 예를 들어, 값이 "put"및 "delete"인 필드를 가질 수 있습니다.