POST

POST 메서드는 대상 리소스가 리소스의 고유한 의미에 따라 요청에 포함된 표현을 처리하도록 요청합니다. 예를 들어, POST는 다음과 같은 기능에 사용됩니다.

• HTML 양식에 입력된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공하기,
• 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사한 글 그룹에 메시지 게시하기,
• 원본 서버에서 아직 식별하지 않은 새 리소스 생성하기,
• 리소스의 기존 표현에 데이터 추가하기 등이 그 예입니다.

발원 서버는 POST 요청을 처리한 결과에 따라 적절한 상태 코드를 선택하여 응답 의미를 나타내며, 이 규격에 정의된 거의 모든 상태 코드가 POST에 대한 응답으로 수신될 수 있습니다(예외는 206(일부 내용), 304(수정되지 않음), 416(범위 미만족)).

POST 요청을 성공적으로 처리한 결과 원본 서버에서 하나 이상의 리소스가 생성된 경우 원본 서버는 생성된 기본 리소스의 식별자를 제공하는 Location 헤더 필드(섹션 7.1.2)와 새 리소스를 참조하면서 요청의 상태를 설명하는 표현을 포함하는 201(생성됨) 응답을 보내야 합니다.

POST 요청에 대한 응답은 명시적인 최신성 정보를 포함하는 경우에만 캐싱할 수 있습니다([RFC7234] 4.2.1 절 참조). 그러나 POST 캐싱은 널리 구현되어 있지 않습니다. 원본 서버가 클라이언트가 나중에 GET에서 재사용할 수 있는 방식으로 POST의 결과를 캐시할 수 있기를 원하는 경우 원본 서버는 결과와 POST의 유효 요청 URI와 동일한 값을 갖는 Content-Location 헤더 필드를 포함하는 200(OK) 응답을 전송할 수 있습니다(섹션 3.1.4.2)

POST 처리 결과가 기존 리소스의 표현과 동일할 경우 원본 서버는 위치 필드에 기존 리소스의 식별자가 포함된 303(기타 참조) 응답을 전송하여 사용자 에이전트를 해당 리소스로 리디렉션할 수 있습니다. 이렇게 하면 사용자 에이전트에게 리소스 식별자를 제공하고 공유 캐싱에 더 적합한 방법을 통해 표현을 전송할 수 있다는 이점이 있지만, 사용자 에이전트에 아직 캐싱된 표현이 없는 경우 추가 요청이 발생한다는 단점이 있습니다.