PUT

PUT 메서드는 대상 리소스의 상태를 요청 메시지 페이로드에 포함된 표현에 정의된 상태로 만들거나 바꾸도록 요청합니다. 주어진 표현에 대한 PUT이 성공하면 동일한 대상 리소스에 대한 후속 GET이 200(OK) 응답으로 동일한 표현을 전송할 것임을 시사합니다. 그러나 후속 GET이 수신되기 전에 대상 리소스가 다른 사용자 에이전트에 의해 병렬로 처리되거나 원본 서버에 의해 동적으로 처리될 수 있으므로 이러한 상태 변경을 관찰할 수 있다는 보장은 없습니다. 성공적인 응답은 원본 서버에서 처리할 당시 사용자 에이전트의 의도가 달성되었음을 의미합니다.

대상 리소스에 현재 표현이 없는데 PUT이 성공적으로 표현을 생성하는 경우 원본 서버는 201(Created) 응답을 전송하여 사용자 에이전트에게 알려야 합니다. 대상 리소스에 현재 표현이 있고 해당 표현이 동봉된 표현의 상태에 따라 성공적으로 수정된 경우 원본 서버는 요청이 성공적으로 완료되었음을 나타내는 200(OK) 또는 204(No Content) 응답을 보내야 합니다.

원본 서버는 PUT 요청에서 수신된 인식되지 않은 헤더 필드를 무시해야 합니다(즉, 일부로 저장하지 마십시오, 리소스 상태의 일부로 저장하지 않아야 합니다)

오리진 서버는 PUT 표현이 서버가 대상 리소스에 대해 가지고 있는 제약 조건과 일치하는지 확인해야 하며, 이 제약 조건은 PUT에 의해 변경될 수 없거나 변경되지 않을 것입니다. 이는 원본 서버가 GET 응답에서 표현 메타데이터의 값을 설정하기 위해 URI와 관련된 내부 구성 정보를 사용하는 경우 특히 중요합니다. PUT 표현이 대상 리소스와 일치하지 않는 경우 원본 서버는 표현을 변환하거나 리소스 구성을 변경하여 일관성을 유지하거나 표현이 부적절한 이유를 설명하는 충분한 정보가 포함된 적절한 오류 메시지로 응답해야 합니다. 409(충돌) 또는 415(지원되지 않는 미디어 유형) 상태 코드가 권장되며, 후자는 콘텐츠 유형 값에 대한 제약 조건과 관련이 있습니다.

예를 들어 대상 리소스의 콘텐츠 유형이 항상 "text/html"이고 PUT되는 표현의 콘텐츠 유형이 "image/jpeg"인 경우, 원본 서버는 다음 중 하나를 수행해야 합니다.

• a. 새 미디어 유형을 반영하도록 대상 리소스를 재구성하거나,
• b. 새 리소스 상태로 저장하기 전에 리소스의 형식과 일치하는 형식으로 PUT 표현을 변환하거나,
• c. 대상 리소스가 "텍스트/html"로 제한되어 있음을 나타내는 415(지원되지 않는 미디어 유형) 응답으로 요청을 거부하고 새 표현에 적합한 다른 리소스에 대한 링크를 포함합니다.

HTTP는 사용자 에이전트 요청의 의도와 원본 서버 응답의 의미로 표현할 수 있는 것 이상으로 PUT 메서드가 원본 서버의 상태에 영향을 미치는 방식을 정확하게 정의하지 않습니다. HTTP를 통해 제공되는 인터페이스를 넘어서는 리소스가 어떤 의미에서 어떤 것인지 정의하지 않습니다. 리소스 상태가 어떻게 "저장"되는지, 리소스 상태의 변경으로 인해 그러한 저장소가 어떻게 변경될 수 있는지, 원본 서버가 리소스 상태를 어떻게 표현으로 변환하는지도 정의하지 않습니다. 일반적으로 리소스 인터페이스 뒤에 있는 모든 구현 세부 사항은 서버에 의해 의도적으로 숨겨집니다.

오리진 서버는 요청의 표현 데이터가 본문에 적용된 변환 없이 저장되고(즉, 리소스의 새 표현 데이터가 PUT 요청에서 받은 표현 데이터와 동일하고) 유효성 검사기 필드 값이 새 표현을 반영하는 경우를 제외하고는 PUT에 대한 성공적인 응답으로 ETag 또는 Last-Modified 필드 같은 유효성 검사기 헤더 필드(섹션 7.2)를 전송하지 않아야 합니다. 이 요건을 통해 사용자 에이전트는 메모리에 있는 표현 본문이 PUT의 결과로 최신 상태로 유지되므로 원본 서버에서 다시 검색할 필요가 없으며, 실수로 덮어쓰기를 방지하기 위해 응답에서 받은 새 유효성 검사기를 향후 조건부 요청에 사용할 수 있습니다(섹션 5.2).

POST와 PUT 방법의 근본적인 차이점은 동봉된 표현의 다른 의도에 의해 강조됩니다. POST 요청의 대상 리소스는 리소스의 자체 의미론에 따라 동봉된 표현을 처리하도록 되어 있는 반면, PUT 요청의 동봉된 표현은 대상 리소스의 상태를 대체하는 것으로 정의됩니다. 따라서 정확한 효과는 원본 서버만 알 수 있지만 PUT의 의도는 무력화되고 중개자가 볼 수 있습니다.

PUT 요청을 올바르게 해석하려면 사용자 에이전트가 어떤 대상 리소스를 원하는지 알고 있다고 가정합니다. 상태 변경 요청을 받은 후 클라이언트를 대신하여 적절한 URI를 선택하는 서비스는 PUT이 아닌 POST 메서드를 사용하여 구현해야 합니다. 원본 서버가 요청된 PUT 상태 변경 요청을 대상 리소스에 적용하지 않고 다른 리소스에 적용하려는 경우(예: 리소스가 다른 URI로 이동한 경우) 원본 서버는 적절한 3xx(리디렉션) 응답을 보내야 하며, 사용자 에이전트는 요청을 리디렉션할지 여부를 자체적으로 결정할 수 있습니다.

대상 리소스에 적용된 PUT 요청은 다른 리소스에 부작용을 초래할 수 있습니다. 예를 들어 문서에 "현재 버전"(리소스)을 식별하는 URI가 각 특정 버전(한때 현재 버전 리소스와 동일한 상태를 공유했던 다른 리소스)을 식별하는 URI와 분리되어 있을 수 있습니다. 따라서 "현재 버전" URI에 대한 PUT 요청이 성공하면 대상 리소스의 상태를 변경하는 것 외에도 새 버전 리소스가 생성될 수 있으며 관련 리소스 간에 링크가 추가될 수도 있습니다.

특정 대상 리소스에 대한 PUT을 허용하는 원본 서버는 페이로드가 전체 콘텐츠로 잘못 PUT된 부분 콘텐츠일 가능성이 있으므로 Content-Range 헤더 필드([RFC7233] 섹션 4.2)가 포함된 PUT 요청에 400(Bad Request) 응답을 전송해야 합니다. 부분 콘텐츠 업데이트는 더 큰 리소스의 일부와 겹치는 상태를 가진 별도로 식별된 리소스를 대상으로 하거나 부분 업데이트를 위해 특별히 정의된 다른 방법(예: [RFC5789]에 정의된 PATCH 방법)을 사용하여 가능합니다.

PUT 메서드에 대한 응답은 캐시할 수 없습니다. 성공적인 PUT 요청이 유효한 요청 URI에 대해 하나 이상의 저장된 응답이 있는 캐시를 통과하면 저장된 응답은 무효화됩니다([RFC7234] 섹션 4.4 참조).