PUT 및 DELETE HTTP 요청 방법의 유용성은 무엇입니까?

나는 이것에 대해 많은 것을 읽었지만이 주제에 대한 결론을 얻지 못했습니다.

하지만 PUT 또는 DELETE HTTP 요청 메서드를 사용한 적이 없습니다. 내 경향은 시스템 (내 애플리케이션 또는 웹 사이트)의 상태가 영향을받지 않을 때 (제품 목록과 같이) GET을 사용하고 영향을받을 때 (주문이 접수 됨) POST를 사용하는 것입니다. 충분하지 않나요? 아니면 뭔가 빠졌나요?

DELETE는 요청 리소스를 삭제하기위한 것입니다.

DELETE 메소드는 Request-URI로 식별 된 자원을 원 서버가 삭제하도록 요청합니다. 이 방법은 원 서버에서 사람의 개입 (또는 다른 수단)에 의해 무시 될 수 있습니다. 클라이언트는 원본 서버에서 반환 된 상태 코드가 작업이 성공적으로 완료되었음을 나타내더라도 작업이 수행되었음을 보장 할 수 없습니다.

PUT는 서버에 리소스를 추가하거나 업데이트하기위한 것입니다.

PUT 메소드는 동봉 된 엔티티가 제공된 Request-URI 아래에 저장되도록 요청합니다. Request-URI가 이미 존재하는 자원을 참조하는 경우, 동봉 된 엔티티는 원본 서버에있는 자원의 수정 된 버전으로 간주되어야합니다 (SHOULD). Request-URI가 기존 리소스를 가리 키지 않고 해당 URI가 요청하는 사용자 에이전트에 의해 새 리소스로 정의 될 수있는 경우 원본 서버는 해당 URI로 리소스를 생성 할 수 있습니다.

전체 사양을 보려면 다음을 방문하십시오.

• http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

안타깝게도 현재 브라우저는 HTML 형식에서 POST 및 GET 이외의 다른 동사를 지원하지 않기 때문에 일반적으로 HTTP를 최대한 활용할 수 없습니다 (하지만 JavaScript를 통해 제출물을 가로 챌 수 있음). HTML 형식에서 이러한 메서드에 대한 지원이 없기 때문에 예를 들어 동사를 포함하는 URI가 발생했습니다.

POST http://example.com/order/1/delete

또는 더 나쁜

POST http://example.com/deleteOrder/id/1

HTTP를 통해 CRUD 의미 체계를 효과적으로 터널링합니다. 그러나 동사는 URI의 일부가 될 수 없습니다. 대신 HTTP는 이미 HTTP 메소드를 통해 리소스 (예 : 주문)를 CRUD하는 메커니즘과 의미를 제공합니다. HTTP는 단순한 데이터 터널링 서비스가 아닌 프로토콜입니다.

따라서 웹 서버에서 리소스를 삭제하려면 다음을 호출합니다.

DELETE http://example.com/order/1

업데이트하려면

PUT http://example.com/order/1

그리고 웹 서버가 적용 할 수 있도록 PUT 본문에 업데이트 된 리소스 표현을 제공합니다.

따라서 REST API에 대한 일종의 클라이언트를 구축하는 경우 PUT 및 DELETE 요청을 보낼 수 있습니다. 이것은 브라우저 내부에 구축 된 클라이언트 일 수 있습니다. 예를 들어 JavaScript를 통해 요청을 전송하거나 서버에서 실행되는 도구 등이 될 수 있습니다.

자세한 내용은 다음을 방문하십시오.

• http://martinfowler.com/articles/richardsonMaturityModel.html
• 대부분의 웹 브라우저에서 PUT, DELETE, HEAD 등의 메소드를 사용할 수 있습니까?
• HTML 양식에 PUT 및 DELETE 메소드가없는 이유
• 양식에서 PUT 및 DELETE를 사용해야합니까?
• http://amundsen.com/examples/put-delete-forms/
• http://www.quora.com/HTTP/Why-are-PUT-and-DELETE-no-longer-supported-in-HTML5-forms

GET, POST, DELETE, PUT 등과 같은 HTTP 요청 동사를 사용하면 RESTful 웹 애플리케이션을 빌드 할 수 있습니다. 여기에서 읽어보세요 : http://en.wikipedia.org/wiki/Representational_state_transfer

이점을 확인하는 가장 쉬운 방법은이 예를 보는 것입니다. 모든 MVC 프레임 워크에는 Router/DispatcherURL을 actionController에 매핑 하는 것이 있습니다. 따라서 URL은 다음과 같습니다. /blog/article/1호출됩니다. blogController::articleAction($id); 이제이 라우터는 URL 또는/blog/article/1/

하지만 라우터가 URL 대신 전체 HTTP 요청 객체를 인식한다면 HTTP 요청 동사 (GET, POST, PUT, DELETE ...) 및 현재 HTTP 요청에 대한 기타 유용한 정보에 액세스 할 수 있습니다.

그러면 동일한 URL을 수락하고 HTTP 요청 동사에 따라 다른 actionController에 매핑 할 수 있도록 응용 프로그램을 구성 할 수 있습니다.

예를 들면 :

기사 1을 검색하려면 다음을 수행하십시오.

GET /blog/article/1 HTTP/1.1

그러나 기사 1을 삭제하려면 다음을 수행하십시오.

DELETE /blog/article/1 HTTP/1.1

두 HTTP 요청에 동일한 URI, / blog / article / 1이 있으며 유일한 차이점은 HTTP 요청 동사입니다. 그리고 그 동사를 기반으로 라우터는 다른 actionController를 호출 할 수 있습니다. 이를 통해 깔끔한 URL을 만들 수 있습니다.

이 두 기사를 읽으면 도움이 될 것입니다.

Symfony 2-HTTP 기초

Symfony 2-라우팅

이 기사는 Symfony 2 프레임 워크에 관한 것이지만 HTTP 요청 및 응답이 어떻게 작동하는지 파악하는 데 도움이 될 수 있습니다.

도움이 되었기를 바랍니다!

나는 인기가 없을 위험을 감수하지만 요즘에는 유용하지 않다고 말합니다 .

예를 들어 DELETE가 제공된 URL에서 찾은 리소스를 삭제하도록 서버에 지시하고 PUT (동위 PATCH 포함)가 멱 등성 방식으로 업데이트를 수행하도록 서버에 지시했을 때 이전에는 잘 의도되고 유용했다고 생각합니다.

상황이 발전하고 URL이 가상이되면서 ( 예를 들어 URL 재 작성 참조 ) 리소스가 실제 폴더 / 서브 포더 / 파일의 초기 의미를 잃어 버리고 HTTP 프로토콜 메서드 (GET, POST, PUT / PATCH, DELETE)에서 다루는 CRUD 동작 동사가 추적을 잃게됩니다. .

예를 들어 보겠습니다.

• / api / entity / list / {id} 대 GET / api / entity / {id}
• / api / entity / add / {id} 대 POST / api / entity
• / api / entity / edit / {id} 대 PUT / api / entity / {id}
• / api / entity / delete / {id} 대 DELETE / api / entity / {id}

왼쪽에는 HTTP 메소드가 작성되어 있지 않으며 본질적으로 중요하지 않으며 (POST 및 GET이면 충분 함) 오른쪽에는 적절한 HTTP 메소드가 사용됩니다.

오른쪽은 우아하고 깨끗하며 전문적으로 보입니다. 이제 우아한 API를 사용하고있는 코드를 유지하고 삭제 호출이 수행 된 위치를 검색해야한다고 상상해보십시오. "api / entity"를 검색 하고 결과 중 어느 것이 DELETE를 수행하는지 확인해야합니다. 또는 더 나쁜 것은 실수로 DELETE로 PUT을 전환하고 URL이 같은 일이 발생한 주니어 프로그래머가 있다는 것입니다.

제 생각에는 URL에 동작 동사를 넣는 것은 그다지 우아하지 않더라도 해당 동작에 적절한 HTTP 메서드를 사용하는 것보다 이점이 있습니다. 삭제 호출이 발생한 위치를 확인하려면 "api / entity / delete" 를 검색하면 바로 찾을 수 있습니다.

메서드의 전체 HTTP 배열없이 API를 빌드하면 나중에 사용하고 유지 관리하기가 더 쉽습니다.

안전한 방법 : 리소스 가져
오기 / 리소스 수정 없음 멱 등성 : 여러 번 요청하면 리소스 상태 변경 없음
안전하지 않은 방법 : 리소스 생성 또는 업데이트 / 리소스
비멱 등성 : 여러 번 요청하면 리소스 상태 변경

귀하의 요구 사항에 따라 :

1) 안전하고 멱등적인 작업 (Fetch Resource)을 사용하려면 --------- GET METHOD를 사용하십시오.
2) 안전하지 않고 멱 등성 작업 (Insert Resource)을 사용하려면 --------- POST METHOD
3)을 사용하십시오. 안전하지 않은 멱등 작업 (리소스 업데이트)을 사용하려면 --------- PUT METHOD
3) 안전하지 않고 멱등 작업을하려면 (리소스 삭제) 사용 --------- DELETE METHOD