REST – PUT vs POST

많은 사람들 이 시스템을 설계 할 때 HTTP PUT과 POST 방법 중 하나를 선택하는 데 어려움을 겪고 있습니다 . 그러나 RFC 2616 은 두 가지를 구별하는 데있어 매우 분명하지만 복잡한 표현은 많은 사람들에게 혼란을 줍니당 

 

PUT	POST
RFC-2616 PUT은 동봉 된 엔터티에 대한 메서드 요청이 제공된 Request-URI 아래에 저장되어 있음을 분명히 언급합니다 . Request-URI가 이미 존재하는 리소스를 참조하는 경우 – 업데이트 작업이 수행되고, 그렇지 않으면 Request-URI가 유효한 리소스 URI 인 경우 작성 작업이 수행됩니다 (클라이언트가 리소스 식별자를 결정할 수 있다고 가정).	이 POST방법은 origin 서버가 요청에 포함 된 엔티티를 요청 라인의 Request-URI에 의해 식별 된 자원의 새로운 하위 항목으로 수락하도록 요청하는 데 사용됩니다. 이는 본질적으로 POSTrequest-URI가 콜렉션 URI 여야 함을 의미합니다 .
PUT/test/test{test-id}	POST/test
PUT메소드는 idempotent 입니다. 따라서 재시도 요청을 여러 번 보내는 경우 단일 요청 수정과 동일해야합니다.	POST는 idempotent 아닙니다. 따라서 요청을 N 번 재 시도하면 서버에서 N 개의 서로 다른 URI로 N 개의 자원을 갖게됩니다.
PUT이미 자원 콜렉션의 일부인 단일 자원을 수정하려는 경우에 사용하십시오 . PUT은 리소스를 완전히 대체합니다. 요청이 자원의 일부를 업데이트하는 경우 PATCH를 사용하십시오.	POST자원 콜렉션에서 하위 자원을 추가하려는 경우에 사용 하세요 .
PUT idempotent  이지만 응답을 캐시하지 않습니다.	응답에 적절한 Cache-Control 또는 Expires 헤더 필드가 포함되어 있지 않으면 이 메소드에 대한 응답을 캐시 할 수 없습니다 . 그러나 303 (기타 참조) 응답을 사용하여 사용자 에이전트가 캐시 가능한 자원을 검색하도록 지시 할 수 있습니다.
일반적으로 실제로는 항상 PUTUPDATE 조작에 권장	항상 POST CREATE 조작에 사용 권장

idempotent : 멱등(冪等)은 수학이나 전산학에서 연산의 한 성질을 나타내는 것으로, 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미함.

PUT vs POST : 예제

네트워크 애플리케이션을 설계한다고 가정 해 봅시다. 사용시기 POST및 사용시 기를보다 잘 이해하기 위해 URI와 그 목적을 나열 해 보겠습니다 PUT.

GET / device-management / devices : 모든 장치 가져 오기 POST / device-management / devices : 새 장치 만들기 GET / device-management / devices / {id} : "id" PUT / device-management /로 식별 된 장치 정보 가져 오기 devices / {id} : "id"로 식별 된 장치 정보 업데이트 DELETE / device-management / devices / {id} : "id"로 장치 삭제

 

참고 URL : https://restfulapi.net/rest-put-vs-post/