참고자료
여기에는 꽤 오해가 있는 것 같습니다. PUT 대 POST는 실제로 교체 대 생성에 관한 것이 아니라 멱등성과 리소스 명명에 관한 것입니다.
PUT은 멱등성 작업입니다. 이를 통해 리소스의 이름과 해당 리소스의 콘텐츠로 배치할 엔터티를 제공합니다(서버에서 생성된 추가 사항 포함). 결정적으로, 작업을 연속으로 두 번 수행하면 "동일한 것"에 대한 상당히 느슨한 정의에 대해 한 번만 수행되거나 20번 수행된 것과 동일한 결과가 나와야 합니다(바이트 단위일 필요는 없음). 바이트는 동일하지만 사용자가 제공한 정보는 그대로 유지되어야 합니다). PUT으로 인해 금융 거래가 실행되는 것을 원하지 않을 것입니다.
POST는 비멱등성 작업입니다. 생성하려는 리소스의 이름을 제공할 필요가 없습니다(POST도 생성할 필요 가 없습니다 . 원하는 경우 리소스 중복을 제거할 수 있습니다). POST는 종종 "새로 만든 이름으로 리소스를 생성하고 이름이 무엇인지 알려주기"를 구현하는 데 사용됩니다. "새로 만든 이름"이 암시하는 멱등성 부족이 이에 적합합니다. 새 리소스가 생성되는 경우 Location 헤더에 리소스에 대한 로케이터를 다시 보내는 것이 전적으로 옳은 일입니다.
이제 클라이언트가 리소스 이름을 생성해서는 안 된다는 정책 입장을 취하고 있다면 POST가 생성에 완벽하게 적합하고(이론적으로는 제공된 엔터티를 기반으로 모든 작업을 수행할 수 있음) PUT이 업데이트를 수행하는 방법을 얻게 됩니다. 많은 RESTful 애플리케이션의 경우 많은 의미가 있지만 전부는 아닙니다. 사용자에게 제공되는 모델이 파일 시스템인 경우 사용자가 리소스 이름을 제공하도록 하는 것이 큰 의미가 있으며 PUT가 주요 생성 작업이 됩니다(그리고 POST는 빈 디렉토리 만들기와 같은 덜 일반적인 작업에 위임됩니다. on; WebDAV는 POST의 필요성을 더욱 줄여줍니다.
요약: 생성/업데이트 측면에서 생각하지 말고 누가 리소스 이름을 만들고 어떤 작업이 멱등적인지 생각하세요. PUT은 실제로 생성 또는 업데이트하고 POST는 실제로 반복해서는 안 되는 모든 작업을 수행합니다.